Wikipedia:Village pump (idea lab)

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

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:

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, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84

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:

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)
May I interest you in mw:Readers/Information Retrieval? Chaotic Enby (in solidarity · talk · contribs) 21:41, 5 October 2026 (UTC)
An estimated 78% of reading sessions originate from external search engines. with 90% of those coming from Google Search.
...
When readers consistently find it easier to access Wikipedia’s content through third-party platforms than on Wikipedia itself, the site risks becoming a background data source rather than a destination for learning.
As in, the same way readers have found their way to Wikipedia ever since it was created? This sounds like more of the slimy corporate "capture all the traffic and never ever let them leave" crap from the discussion about the app and does absolutely nothing to improve my opinion of WMF. Apparently when you reach a certain size slimy corporate behavior becomes mandatory. Very keeping up with the Joneses. ChompyTheGogoat [ Bleat | Munched ] 21:50, 5 October 2026 (UTC)
I actually wanted to post about a "Google AI Overviews"-like AI assisted search concept feature in here too, with the same goal of getting people to continue using Wikipedia instead of external AI tools! Looks like you've beaten me to it :)
I do agree that the AI (model) used for the AI search should be open sourced, and not (necessarily) be built in-house by the WMF. Also, this feature should also be opt-in rather than opt-out. Since we're targeting readers rather than editors, if and when we conduct these tests, the AI functions would be shown to them first, rather than being shown to editors first. And of course, there must be guardrails, the information should be cited to an article so readers can learn more from there.
There are some differences between your idea and my idea though. Most notably is the placement of the "AI search" button. Personally I'd rather put the AI search button at the bottom right (or bottom left) corner of the page, similar to the help panel shown to new editors, in contrast to being shown to the right of the search bar as you conceived. Also, not sure if we want cross-wiki search, but we'll see.
I do have more comments, including use class and mockups (using the Codex template on Figma), which I will leave below this main comment. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 04:55, 6 October 2026 (UTC)
Readers and editors aren't mutually exclusive. ChompyTheGogoat [ Bleat | Munched ] 05:22, 6 October 2026 (UTC)
@Hason-LEK-SIN, thanks for your comment. Yes, I agree that the current search must always be kept, and that AI should be used only as an interface for the search of information, never for writing text for the articles. The exact placing of the button would be a minor issue, several places can be considered and debated, for sure :) MGeog2022 (talk) 11:42, 11 October 2026 (UTC)
Oppose. I feel that the people who would come to Wikipedia if this change were made would be outnumbered by the people who would leave. So many people, especially the type of people who use Wikipedia, have a strong dislike for generative AI. Those who especially enjoy AI will often not see a use for visiting many other sites, since AI can already tell them everything they'll want to hear. Siteseers (Talk/Contributions) 16:27, 6 October 2026 (UTC)
I don't argue with this, but I find it ironic, given the early days of Wikipedia itself when many people "repelled the idea of an encyclopedia that anyone could edit because it would never be as reliable as traditional sources." Sira Aspera (talk) 20:41, 6 October 2026 (UTC)
(This is the idea lab, by the way) Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 23:25, 6 October 2026 (UTC)
Sorry, I'm new to Wikipedia, can you not oppose ideas in the Idea Lab? Siteseers (Talk/Contributions) 13:03, 7 October 2026 (UTC)
First off, welcome! Secondly, do read the top of the Village Pump, which says:

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.

Happy editing! Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 13:08, 7 October 2026 (UTC)
My sincerest apologies, thank you! Siteseers (Talk/Contributions) 13:15, 7 October 2026 (UTC)
Those who especially enjoy AI will often not see a use for visiting many other sites, since AI can already tell them everything they'll want to hear. And this is a big problem, and one that Wikipedia could help to solve, by using AI in helping people to find knowledge, in place of believing hallucinated trash.
So many people, especially the type of people who use Wikipedia, have a strong dislike for generative AI. Wikipedia is not written for Wikipedians, but for the public as a whole. Out there, such dislike does exist, but is not so prevalent. And we must differentiate using generative AI as a source of knowledge (which is wrong, unless looking for very basic facts) from other uses of generative AI. Making Wikipedia to look as a project for anti-AI people only would make it a fringe project. I don't want that, and I hope most of the community also doesn't want it. Wikipedia has gained a place where it is mainstream. One of the few cases where the main existing product is both a freely licensed one and one well-known to the masses (for example, Linux, while absolute leader in some types of computing, is not so well-known for many people as Wikipedia is). We believe in freely licensed content, and we should enjoy the fact that we are the leading encyclopedia. We shouldn't renounce that, much less tolerate being replaced in society by something that is not even an encyclopedia nor a proper written work (the latter point is important, because even freely licensed AI models shouldn't replace Wikipedia, since they are not true written works). And, at this moment, we need to fight for that, whether you are a pro-AI, anti-AI, or neutral Wikipedian. Maybe AI-assisted search is not the only or the best thing to do for that, but I think that Wikipedia/WMF should highlight why Wikipedia is needed by humans in the AI era, and make campaigns around it (and, no, an "all AI is evil" campaign would not be the solution: it would make the problem worse, since many people use generative AI for work, and they are happy with it: the campaign should focus on the points where Wikipedia is far better than AI: each thing has its own purpose).
I feel that the people who would come to Wikipedia if this change were made would be outnumbered by the people who would leave: really? If Wikipedia adds an AI-assisted search (I'm not talking about AI-assisted article writing, that would be another thing), many people would leave? What would they do, then? Since they are anti-AI, I suppose they would go to Encyclopaedia Britannica, and, when the information is not there, I suppose they would just accept ignorance. Fortunately, there are more things than fanaticism (pro-AI, anti-AI, or pro or anti whatever you want) in life. MGeog2022 (talk) 11:22, 11 October 2026 (UTC)
Being anti-AI isn't fringe, and keeping AI out of specific spaces that have always been written by humans, for humans certainly isn't. You can acknowledge that it has valid uses and still not want it encroaching in certain areas - and it's already causing issues where it's been inserted here without consensus, so I have precisely zero faith that giving them license for additional uses would turn out any better. Wikipedia should be upholding quality standards, not trying to win a popularity contest. People who already believe hallucinated slop aren't looking for alternatives anyway because they don't know any better. If they did, they'd use us without needing AI features as some weird form of bribery. ChompyTheGogoat [ Bleat | Munched ] 13:00, 11 October 2026 (UTC)
keeping AI out of specific spaces that have always been written by humans: I fully agree on keeping AI 100% out of writing any Wikipedia content: my proposal is only about a tool for querying information, but that information must be written by humans.
Wikipedia should be upholding quality standards, not trying to win a popularity contest: both things are needed: Wikipedia's quality itself would be in trouble if only a tiny minority of the people use it. It's not about getting as many visits as possible, but about continuing to be the leading source of knowledge. Visits to Wikipedia are going down, and the solution to this is not just saying that we are better and wiser: Wikipedia must not allow being silently replaced by non-free products that are not even an encyclopedia.
According to this source, in the United Kingdom, 42% of individuals deliberately limit the amount of AI they use. Only a part of them would be purely anti-AI people. I believe Wikipedia should be for everybody, not only focused on that <42% of the people: believing that Wikipedia should be specifically directed to the, let's suppose, 25% of people who oppose using AI at all, is what would make it a fringe project. A fully optional AI-powered search has nothing to do with basing Wikipedia on AI: it's just an optional tool that you use if you want, and, if you don't want, you don't use it. We can't allow AI damaging Wikipedia's quality, but we also can't allow AI making Wikipedia irrelevant for the wider public. Wikipedia should be for everybody: for people who don't like AI, for people who like AI, and for people who are indifferent about AI. And I would like to add that, as long as AI (particularly, non-free AI) threatens the usage of Wikipedia, free content and open source software, I'd belong to the anti-AI camp. We can't stop AI (no new technology has ever been suppressed), but we can stop the damage it causes to free knowledge. MGeog2022 (talk) 16:42, 11 October 2026 (UTC)
I've written this essay about the relationship between Wikipedia and generative AI (improvements are welcome): Wikipedia and generative AI, different things with different purposes MGeog2022 (talk) 18:36, 11 October 2026 (UTC)
42% is hardly a "tiny minority", and you seem to be assuming that the remaining 68% who don't actively avoid it would also refuse to utilize any products that don't include AI, which is a massive leap. So is the notion that anything without AI features will become irrelevant. This is feeling more and more like obsessive POV pushing without any care for consensus. You said weeks ago What seems clear is that most of the community fully rejects any use of AI in Wikipedia, and yet you're still here arguing for it, in what should probably be a WP:SNOW close since you've seen how similar discussions turn out. ChompyTheGogoat [ Bleat | Munched ] 18:58, 11 October 2026 (UTC)
I hope you are right, but I don't like the "AI replaces Wikipedia" thought that I see out there, and I believe that something should be done about that. As I said, I'm not a pro-AI fanatic at all, but I don't see that a majority, or even a big minority, of people are anti-AI (42% of people "deliberately limit the amount of AI they use" is not the same as them trying not to use AI at all). And I'm not doing "obsessive POV pushing" at all: I only commented here again in response to other, new comments from other users (by the way, one of them was in support of my proposal). I took advantage of this to express my worries about the seemingly endless fall in the number of visits to Wikipedia, and to warn about the dangers of a "Wikipedia vs AI battle". We must be aware about how prevalent the use of AI is (even if we don't like it at all), and make Wikipedia the leading source of knowledge in this era, just as it was in the previous one. In fact, the problem is not how prevalent AI is, but how much it is being trusted as a source of knowledge (which it isn't), even by people with university education. The solution to this is not to "destroy AI", but to convince people to use Wikipedia for what Wikipedia is, and to use AI for what AI is. Maybe a WMF campaign could help with this, or maybe time will do it (but there is a risk in the latter case: given the current panorama, I fear that hallucinated ignorance could eventually win). MGeog2022 (talk) 19:24, 11 October 2026 (UTC)
Brittanica also has an AI. CoolDino1 (talk) 16:12, 15 October 2026 (UTC)
I'm not convinced that a Google AI Mode alternative with a more limited domain of knowledge and open-weight models would get a lot of usage, and plus, every dollar spent on energy costs for this model would come straight out of donations that could have gone somewhere more important instead.
I suppose a trial run with a low-cost model hosted somewhere else could work, but even then, I think that it would probably stain the Wikipedia's reputation amongst the folks who thought that AI Overviews were full of poppycock when they first came out. GrinningIodize (you just lost the game) (talk) 12:33, 12 October 2026 (UTC)
Google AI Mode alternative with a more limited domain of knowledge: Wikipedia's search also has a "more limited domain of knowledge". The difference is that Wikipedia's search results (AI-assisted or not) are trusted as knowledge, while many Google results (AI-assisted or not) are not proper knowledge and/or are not trustable. We shouldn't compare Google's AI mode with the proposed "Wikipedia's AI mode": they would have very different scopes. An AI-assisted search that could locate all information about a topic that is distributed among many Wikipedia articles, would do a far better job than Google's mix of information from any kind of source (Grokipedia and social network sites included). MGeog2022 (talk) 18:15, 12 October 2026 (UTC)
Still though, the folks who search on the Wikipedia are usually people who don't want to read an LLM summary, and for those who do, they can always just ask their favorite LLM service to read Wikipedia articles. GrinningIodize (you just lost the game) (talk) 19:42, 12 October 2026 (UTC)
Additionally, Wikipedia is already one of the most cited websites by LLMs. LLMs are already pulling from WP whether it's a WMF-sponsored project or not. Shocksingularity (talk) 06:00, 14 October 2026 (UTC)
trusted as knowledge
There you go again. AI results cannot be trusted to avoid hallucinations regardless of the size of the knowledge base. It's a fundamental flaw in how they operate, and people who don't understand that will fall for misinformation regardless of the source. Extrapolating Wikipedia's current reputation built on human editing to imply that local AI would be more reliable than external ones would only tarnish that reputation. ChompyTheGogoat [ Bleat | Munched ] 21:07, 12 October 2026 (UTC)
An AI whose literal only source was Wikipedia would not make the same errors as Google's AI (or any other general AI), but that doesn't mean it would not make errors. It would not regurgitate random misinformation (unless said misinformation was present in one of our articles, but that's a GIGO problem that affects all search engines regardless of technology), however it could still produce misinformation by e.g. incorrect synthesis or removal/misunderstanding of nuance. Thryduulf (talk) 21:16, 12 October 2026 (UTC)
You're somewhat right in the sense that hallucinations aren't regurgitation - they're hallucinations. Invented completely out of the blue regardless of sourcing, which I have personally experienced from micro models built on a single source. It doesn't have to be the result of of incorrect analyses either; the information just flat out does not exist anywhere. ChompyTheGogoat [ Bleat | Munched ] 21:22, 12 October 2026 (UTC)
I'm not sure there's a good way to split the distinction between the accuracy of text completion predictions made by an LLM trained on Wikipedia versus one trained on the broader Internet. An LLM isn't trying to reproduce information from its training base; it's generating text that its internal black box thinks is a suitable consequence from the prompt. So the response could still be out-of-the-blue wrong from a Wikipedia-trained LLM. isaacl (talk) 22:02, 12 October 2026 (UTC)
At least the old Google snippets were accurate reproductions from the source - just not necessarily relevant to the actual query. ChompyTheGogoat [ Bleat | Munched ] 22:06, 12 October 2026 (UTC)
I wasn't talking about a LLM trained on Wikipedia. I was talking about using a freely licensed LLM developed by a third party (already trained by the third party), with the appropriate setup for it to search information on Wikipedia (and maybe also its sister projects) only (related concepts: AI agent, Agent harness). LLM training is only for the LLM to have a very basic general culture, but this makes it able of giving basic information only. As I said in the Wikipedia essay I recently wrote, one could say that AI doesn't know: it knows how to do. While hallucinations are always possible, AI works far better with source texts as "raw material": its internal knowledge base is useful only for very basic concepts. To avoid problems with hallucinations or misinterpretations by the AI, I'd like to emphasize its role should be that of a search assistant, inviting the user to actually read the content in the Wikipedia articles (or other wikis or Commons media files), or, when appropriate, including a paragraph, taken verbatim from the article, with citations included, and a link to the article's section where the paragraph was taken from. My idea was to undo the "AI replaces Wikipedia" change that some people underwent, by providing the needed tools for it, while also adding new advanced search capabilities to Wikipedia and its sister projects. MGeog2022 (talk) 12:57, 13 October 2026 (UTC)
I was commenting on Thryduulf's statement An AI whose literal only source was Wikipedia ... would not regurgitate random misinformation. isaacl (talk) 18:39, 13 October 2026 (UTC)

Optional Content Warnings and Collapsible Text for Exceptionally Graphic Material

Hi everyone!

I'd like to suggest introducing content warnings and optional collapsible text for exceptionally graphic descriptions in Wikipedia articles, similar to how spoiler tags work on Discord.

Recently, I was researching the Colombian serial killer Luis Alfredo Garavito and came across the descriptions in the Modus operandi section of his Wikipedia article.

I'm an adult and generally have a fairly high tolerance for graphic material. I regularly research criminal cases and understand that articles covering these subjects will inevitably contain disturbing information. However, the level of graphic detail in this particular section was something I was completely unprepared for. It genuinely shocked me, and I found myself quite distressed afterward.

This experience also made me think about younger readers. Wikipedia is accessible to everyone, including children who might stumble upon an article out of curiosity. While someone researching a serial killer should reasonably anticipate disturbing subject matter, I don't think they would necessarily anticipate descriptions of that level of severity. I'm absolutely not suggesting that Wikipedia remove, censor or omit factual information. I understand the importance of documenting these cases accurately, and I believe readers should continue to have access to complete information.

However, I wish I'd been given the opportunity to decide whether I wanted to read those particular descriptions. Had I received a warning beforehand, I likely would have chosen not to reveal them.

My Proposal:

I'd like to suggest introducing an optional feature for particularly graphic passages that includes:

This could function similarly to Discord's spoiler tags, allowing readers to make an informed decision about whether they wish to view additional details. I believe this would be particularly beneficial for younger readers, people who have experienced trauma and anyone who wishes to research difficult subjects without unexpectedly encountering extremely graphic descriptions. Content warnings wouldn't prevent people from accessing information, they would simply give readers a choice about how they encounter it.

Previous Proposals & Potential Concerns:

I've since discovered that content warnings have previously been proposed and rejected, and that Wikipedia has an existing policy concerning disclaimers. However, I believe my proposed approach is sufficiently different to warrant further discussion.

One reason cited for rejecting previous proposals was that disclaimers may appear too late, after readers have already encountered the material. My suggestion would address this concern by allowing particularly explicit passages to remain hidden until readers actively choose to reveal them. Rather than placing a general disclaimer at the beginning of an article, this approach would provide warnings immediately before specific passages containing exceptionally graphic descriptions.

I recognize that establishing criteria for which passages qualify would require careful consideration. However, I believe this approach is worth exploring separately from general article-wide disclaimers.

Ultimately, I'm not asking Wikipedia to decide what readers should or shouldn't be allowed to read. I'm suggesting that readers be given the opportunity to make that decision for themselves.

I'd be interested to hear whether this approach would be technically feasible and what the community thinks about the idea. Thank you for taking the time to read and consider my suggestion! chrissy <3 (talk) 05:44, 4 October 2026 (UTC)

While a warning template is technically feasible in theory (but see also MOS:COLLAPSE regarding accessibility issues), your suggestion does not address any of the reasons why previous proposals for similar have been unsuccessful, particularly:
  • Who defines what "particularly graphic" and/or "exceptionally graphic" actually means?
  • Who decides whether a given bit of content meets that definition?
  • How, in practical terms, do we assess 7,256,518 articles to apply the template so that someone browsing Wikipedia on the basis that this warning will protect them/their child from seeing "exceptionally graphic" content doesn't come across such material on an article that hasn't been looked at yet? What about if the article content has been changed since it was last assessed (vandalism, article expanded, etc)?
So, no, in practice it is not feasible. Thryduulf (talk) 11:39, 4 October 2026 (UTC)
For linking purposes: See also Wikipedia:Perennial proposals § Content warnings the article in question, Luis Garavito, and relevant talk page sections, Talk:Luis Garavito § Disturbing details in modus operandi and Talk:Luis Garavito § Excessive and disturbing 'Modus Operandi' section. Graham87 (talk) 13:20, 4 October 2026 (UTC)
Is there a minimal implementation that is still fits, like a template that produces a hidden comment and a User JS script that visibly warns? Interesting to consider but would likely still create disputes and suck a lot of editor time. Dw31415 (talk) 16:48, 4 October 2026 (UTC)
I'd like to clarify that I'm not suggesting Wikipedia review every existing article or guarantee that readers will never encounter disturbing material without a warning.
My suggestion is that warnings could be introduced gradually, where particularly explicit passages are identified and discussed. An imperfect system wouldn't necessarily be without value simply because it couldn't cover every article immediately. I also recognize that collapsible text presents accessibility concerns, and any implementation would need to address those.
Regarding who determines what qualifies as exceptionally graphic, I agree that this would require clearer criteria. Perhaps the feature could be limited to unusually explicit descriptions of sexual violence, torture or severe bodily injuries rather than general references to violence or death. chrissy <3 (talk) 16:55, 4 October 2026 (UTC)
Are you familiar with our RfC process? I’m guessing not based on your proposal. You might take a quick look at some of them at Wikipedia:Requests for comment/All. Experienced volunteers get triggered reading you proposal and imagining the time that will be spent debating whether this or that content qualifies. Dw31415 (talk) 09:40, 5 October 2026 (UTC)
Thanks for pointing me toward the RfC process. You're correct that I'm not particularly familiar with it — I'm relatively new to Wikipedia's internal processes, which is part of why I brought this to the Idea Lab rather than presenting it as a finished policy proposal. I'll take a look through some previous RfCs.
I do understand your concern about editors having to debate what qualifies as exceptionally graphic content. I don't have a perfect solution for where that threshold should be drawn, and I think that's something that would need community input if the idea were ever developed further. My intention here was mainly to suggest the concept and see whether there might be a workable way to implement it, because if it' a firm no on here, there's no point to take it a step further :) ~2026-53456-88 (talk) 17:24, 5 October 2026 (UTC)
I think it’s unlikely to proceed based on all the previous discussions, so I’m hesitant to encourage you to invest more time in it. Let me take the opportunity to compliment your detailed post here. That’s so much better than many of the posts which are super vague Dw31415 (talk) 17:36, 5 October 2026 (UTC)
Parents should be supervising children on Wikipedia. Adults should be aware of what they are getting into. Readers already have the opportunity to decide what they read; they are not compelled to access any particular article. Adults/parents can use methods on their end to block text. If you feel that article content is too graphic or too detailed for the average reader, that should be discussed on the talk page.
This method could be used inappropriately to censor content by deeming it "graphic". Creating a process to challenge its inappropriate use just creates more bureaucracy that we don't have volunteers to be involved in. Thank you for your suggestion, but this is not feasible. 331dot (talk) 14:48, 4 October 2026 (UTC)
My intention isn't to censor information or suggest that parents have no responsibility for supervising their children. Rather, I believe there's a meaningful distinction between knowingly choosing to research a disturbing subject and unexpectedly encountering an exceptionally explicit description within that research. chrissy <3 (talk) 16:57, 4 October 2026 (UTC)
How often do you find explicit or inappropriate descriptions unexpectedly, unpredictably from the article you're reading? If I open a sexually themed article, I can predict there will be descriptions or photos. If I search for a serial killer, there might be descriptions of his crimes. The same goes for other controversial, disturbing, or disgusting topics. However, I've never searched for Winnie the Pooh and randomly stumbled upon explicit descriptions. So, since you actually have to search for your articles on Wikipedia—there's no feed—I think it's worth the hassle.

People can have triggers from the most innocuous things: they might read a Star Wars related page and get triggered by seeing a photo of Palpatine because they have traumas related to elderly figures with dictatorial attitudes. You really don't know what can trigger a person. Furthermore, a reader reads the summary, decides based on it that they can bear to read further, becomes traumatized, and accuses Wikipedia of not adequately protecting them because the summary didn't adequately prepare them to make the decision to delve deeper. Sira Aspera (talk) 20:59, 6 October 2026 (UTC)

good idea, I support! CHIMERA2212 (talk) 15:46, 5 October 2026 (UTC)
Thank you!! :D chrissy <3 (talk) 17:25, 5 October 2026 (UTC)
As you noted, this is a perennial proposal (for anyone who hasn't seen it, see Wikipedia:Perennial proposals § Content warnings). For some recent discussion, see Wikipedia:Village pump (idea lab)/Archive 83 § SFW Wikipedia?. As I discussed previously, I think that content filtering is better done by a for-profit organization, to ensure ongoing funding and to allow it to tailor the filtering for its specific audience. The operational challenge for volunteers to support this is daunting. isaacl (talk) 17:44, 5 October 2026 (UTC)
+1 Also to add it’s probably our commitment to Wikipedia:Consensus that makes this near impossible. A different hypothetical nonprofit project might be able to handle this with an editorial hierarchy. Dw31415 (talk) 17:48, 5 October 2026 (UTC)
I'm sorry, but while I sometimes come across photos here that I would have gladly avoided, I can never support proposals that push Wikipedia toward a version of AO3 or Tumblr's trigger-tag paranoia. Face life, people, and learn to use the X in the top right if a photo or paragraph is really too much for you. Sira Aspera (talk) 20:55, 6 October 2026 (UTC)
Please read the section of the article I mentioned when I created this post and let me know if “pressing X” makes sense here. There is no lead up to this passage — the article is normal until the specific section I mentioned, which is a sudden jump to extreme and graphic descriptions. ~2026-54253-54 (talk) 00:14, 9 October 2026 (UTC)
Yes, I've read it, and yes, it makes sense to me that when it gets too much, you just close the page. You didn't have to read beyond the first line. Also, you can't really call it a surprise: the first few lines make it clear we're talking about a prolific pedophile serial killer known as the Beast. The section is titled "Modus Operandi": what did you expect to find there other than descriptions of how he tortured, raped, and killed? Also, how can you write a summary that gives the reader a good enough warning without mentioning anything? Most people would just click read and then blame Wikipedia because the warning wasn't worded well. Children have no sense of proportion; they would be the first to click "read". The growing expectation among people that they will never encounter anything that makes them uncomfortable and that it is the world's responsibility to ensure this is unhealthy, it is not a right, it is the "the world is shaped to my needs" egocentrism that is so trendy on social media. Sira Aspera (talk) 12:47, 9 October 2026 (UTC)
Again, the content in that section of the article is extremely descriptive and graphic. I'm not saying the information should not be included, but it does not need to be written in the way it is. It seems to almost sensationalize his actions.
If we're going to add such extreme detail, there's no loss to have a warning before the passage. I'm not sure how your feelings are so hurt by this ~2026-55818-08 (talk) 07:02, 17 October 2026 (UTC)
"I'm not saying the information should not be included, but it does not need to be written in the way it is."
The article is written the way it is for a reason: the volunteers who put in time and effort to write about this guy decided that (1) the content was worth informing people about and (2) the current phrasing is the best way to do it.
If you don't like the way it's written, the traditional answer is to WP:Be bold and propose a better phrasing yourself. I recognize that this course of action isn't exactly possible when you want to avoid thinking about the subject matter. But IMHO people with a "does it really need to be included" complaint typically underestimate the extent to which the answer is yes, some readers want to know those things.
The general Wikipedia approach is that is better to have "too much" uncomfortable information here than too little. Readers can always skip the excess information, but they can never read omitted stuff. Bernanke's Crossbow (talk) 05:12, 19 October 2026 (UTC)
And that's purely your opinion. Mine is that people need to grow thicker skin instead of expecting the world to cooperate with their desire to live under a glass bell, avoiding any discomfort. Especially those who voluntarily choose to read the section labeled "Modus Operandi" of a serial killer whose opening sentences make it clear he was extremely violent and brutal. I'd say that's a warning in itself. If this topic were covered in a paperback, would you ask for warning sections before each chapter? Sira Aspera (talk) 17:21, 20 October 2026 (UTC)
sone of these issues can be met by making sure articles are written to the principle of least astonishment WP:PLA. A reader should not be surprised by a graphic image or section of text, which means if these are necessary, they shouldnt be in ledes but in body sections that are clearly marked. But thats the best we can do, because as others have said, we dont censor outside of material illegal under US law, and for anything else, who's moral compass do we use to decide if it should be hidden? Masem (t) 21:22, 6 October 2026 (UTC)
Thank you for your reply! (this is the original poster but I am not logged in on my phone lol)
I am seriously fine with this compromise as well and think it’s a great substitute if my idea is not feasible! ~2026-54253-54 (talk) 00:11, 9 October 2026 (UTC)
Which is exactly how the page that bothered you is written. The information is contained in the section clearly labeled "Modus Operanti," after clarifying that the subject is a brutal serial child sex killer. You read it because you thought you could handle it. Would a "Warning: Sensitive Material" warning really have deterred you? Sira Aspera (talk) 17:25, 20 October 2026 (UTC)
Wikipedia is not censored. Axolitl (talk | contribs) 00:03, 9 October 2026 (UTC)
Thankfully my idea wasn’t to censor Wikipedia as a whole! ~2026-54253-54 (talk) 00:15, 9 October 2026 (UTC)
Also, WP:DISCLAIMERS. Axolitl (talk | contribs) 00:15, 9 October 2026 (UTC)
In addition to what Masem said about the Wikipedia:Principle of least astonishment, I wonder if we could have a collapse button? It wouldn't stop you from seeing it initially, but it would give you a way to collapse it if you didn't want to keep looking at it. I think this would be particularly popular for animated gifs and for large elements (especially if the layout doesn't flow nicely on your device, and you just need to get that wide table out of your way). WhatamIdoing (talk) 23:41, 16 October 2026 (UTC)
Yes yes yes yes, this works as well! ~2026-55818-08 (talk) 07:00, 17 October 2026 (UTC)

"Articles for Replacement" or something like it

Standard disclaimer, I searched for existing threads on this and didn't find anything but I'm pretty new. If this has already been discussed to death just lmk and I'll be on my way.

I have been looking at COI edit requests a bunch recently. The queue is quite long at the moment. There's a particular kind of request that seems doomed to fail, which is when someone comes in and says they have a draft prepared in userspace or draft space or pasted right into the talk page and they want to replace the article that exists with it. What generally happens is that it sits in the queue until it's gotten thoroughly stale and then someone comes by and closes it citing WP:CHANGEXY. I think this is pretty reasonable, and is what I end up doing myself.

However, some of the articles that the edit requests are proposing to replace are, frankly, pretty bad. In some cases it seems like they would have a better chance of improvement if goblins were to sneak into the WMF datacenter and irretrievably delete the original article, allowing the user to take their draft to AfC (where still many of them are probably doomed but you've at least got people who want to look at whole articles). Have we ever considered allowing a separate review process for requests to wholesale replace a current article? It would obviously require that the existing article has major problems. But if nothing else it'd be a more satisfying thing to tell someone than "sorry, there's probably never gonna be a volunteer that wants to dissect the diff between your version and the existing version of this article. maybe see if you can get a WP:TNT deletion." Packrat3860 (talk) 02:50, 12 October 2026 (UTC)

We don't need such a process, since a contributor already can, as WP:TNT notes, rewrite an existing article from scratch. I'm not sure that having an AfD-style discussion about it would achieve much, since !voting to support something in principle won't get it done - it needs someone motivated to do it, and if they are, they don't need a vote. AndyTheGrump (talk) 03:01, 12 October 2026 (UTC)
Well, in the case of COI edits the contributor with a COI is strongly discouraged from making a significant edit. While the option is technically permitted, I think in practice that's not going to be looked at favorably. You're probably just going to get swiftly reverted and told not to do that (and again, no judgement as I have done exactly that).
I guess what I really want is a canned response to suggest that path as an alternative to a "normal" COI request that's specific. Perhaps if someone writes an essay or something it'd be easier to invoke as an official looking suggestion. It gives me some Nel Noddings shaped pause to realize that what I want is a general form to spare me the work of considering the particular scenario.
I think I will try to be bold and consider this option next time someone proposes a complete replacement for an existing article with major quality issues. And maybe also I should sit in on some AfC discussions to get a feel for accepting imperfect improvement to the encyclopedia. If that effort bears fruit I'll report back. Packrat3860 (talk) 04:44, 12 October 2026 (UTC)
Well, in the case of COI edits the contributor with a COI is strongly discouraged from making a significant edit. While the option is technically permitted, I think in practice that's not going to be looked at favorably. You're probably just going to get swiftly reverted. Sorry if I misunderstood something, but, if the article was basically trash, I don't see why the edit should be reverted. If, for whatever reason, there are objections to rewriting the full article from scratch, there should be even more objections to deleting it, so this would not be a solution. MGeog2022 (talk) 19:42, 14 October 2026 (UTC)
In re what I want is a general form to spare me the work of considering the particular scenario: Welcome to Wikipedia, @Packrat3860. Please pick up your experienced editor badge, because you clearly are one, no matter how long you've been editing. The eternal tension when patrolling or working through a backlog is between doing one complex task or ten simple ones, and the temptation is to look for a way to turn the complex tasks into simple ones, or at least to make the complex part be someone else's problem. It's not just us (see, e.g., https://xkcd.com/1319/ on automation), but this is definitely us. WhatamIdoing (talk) 00:57, 17 October 2026 (UTC)
Is there a list of articles that do need to be TNTed? Also, tgat essay always bothered me in that it’s not entirely clear how to TNT except to stubify. User:Bluethricecreamman (Talk·Contribs) 04:49, 12 October 2026 (UTC)
Stubify is pretty much it, I usually only see the TNT essay referenced when it's either that or just delete it (and optionally start again from the redlink). Alpha3031 (t • c) 14:44, 14 October 2026 (UTC)
@Bluethricecreamman, I updated WP:TNT with a more obvious step-by-step process a little while ago. Take a look? WhatamIdoing (talk) 00:59, 17 October 2026 (UTC)
When you encounter this phenomenon, what's stopping you from WP:PRODing the bad article and telling the COI editor to resubmit to AfC? Bernanke's Crossbow (talk) 04:58, 19 October 2026 (UTC)
I am not terribly familiar with WP:PROD. However one of it's criteria listed is that PROD must only be used if no opposition to the deletion is expected.. That seems like it'd be nearly impossible. In my limited experience with AfD it seems the one of the most common objections is that an article's current state is bad but it could be improved. If my intention in deleting an article is just to make space for an AfC submission then it would be hard to argue that I don't think the article could be improved.
That kinda begs the question from Andy above that if I think that stubbifying the article is truly an improvement over its existing state, perhaps I should just do that. Packrat3860 (talk) 05:27, 19 October 2026 (UTC)

Restyle draft decline notices

Moved to Wikipedia talk:WikiProject Articles for creation § Restyle draft decline notices
 – qcne (talk) 18:49, 19 October 2026 (UTC)

Brainstorming ways to resolve the gap with TWAFI on the Main Page

The first thing that came to my mind was to convert TFL to a half-width module. But then I realized it only runs MWF. We could do POTD, but that would sacrifice the size of the picture, which we probably don't want. We could convert one of the half-width modules to full width, but ITN, OTD, and DYK's bullet list formats are all non-conducive to that. This would leave us with TFA or AFI, which would mean removing one of them from the top of the page. Any ideas? Snowmanonahoe (talk · contribs · typos) 00:30, 19 October 2026 (UTC)

I've been informally asking for a better, dedicated spot for Recent Deaths on the main page for a while (most recently here). There are other language Wikipedias that give that section is own spot on the main page separate from ITN. It would mean that blurb and ticker discussions for RD would be separate from ITN as well. Perhaps Recent Deaths could be the project takes up that blank space? Doc Strange (talk) 00:35, 19 October 2026 (UTC)
I strongly support this idea. At ITN we’ve wanted for a while more room for RD and Ongoing. I don’t know if separating RD from ITN would be a good idea but I can certainly see it. I note also that there is an ongoing RFC workshop for ITN reform that this could be rolled in to. Chorchapu (talk | edits) 00:44, 19 October 2026 (UTC)
One of the biggest issues with giving that space to RD that I can think of is that there's no dedicated project discussion space for RD right now, beyond ITN and the talk page of the current year's Recent Deaths page (currently Talk:Deaths in 2026). But if RD is chosen for this blank spot on the main page, and a separation from ITN occurs, I'm sure something like that could be made. Doc Strange (talk) 01:08, 19 October 2026 (UTC)
I’m sure we could figure it out. Alternatively, it could just stay in the same forum as ITN. Chorchapu (talk | edits) 01:10, 19 October 2026 (UTC)
I really like this idea, RD sometimes feels out of place being such a small bar with no info about who the people were OrdinariusFingius (talk) 01:46, 19 October 2026 (UTC)
One can look at the German Wikipedia’s Main Page for an example of what this expanded RD might look like. Of course, anything is open to change and it doesn’t need to be copied exactly from dewiki. Chorchapu (talk | edits) 01:53, 19 October 2026 (UTC)
An explanation about who the people were would be useful... just think about Napoleon Bonaparte (police officer)... OrdinariusFingius (talk) 02:18, 19 October 2026 (UTC)
Given that he appears as simply Napoleon Bonaparte on the Main Page, I support this idea. Adding some information about who these people were would be quite helpful and is arguably, even necessary in some cases. ScienceD90 (she/her) (talk) 03:28, 19 October 2026 (UTC)
On ITNC we discussed this a bit, and seemingly eventually decided to not disambiguate it for two reasons: 1, that it would end up being too long and 2, so it would leave a funny surprise for readers. Chorchapu (talk | edits) 03:31, 19 October 2026 (UTC)
In response to #1, the idea here is to take up space. ScienceD90 (she/her) (talk) 03:47, 19 October 2026 (UTC)
Simply giving everyone some kind of blurb would also majorly help with arguments if a person is famous enough to get a get a blurb or not like with RJ Mitte or Martina Arroyo. Maybe for big cases like RJ Mitte or Martina Arroyo we can add their picture to it or even multiple pictures if a Dolly Parton - Tim Curry death happens perhaps? OrdinariusFingius (talk) 03:34, 19 October 2026 (UTC)
I would oppose this idea, as I have in the past. Having a look at the obit sections at places like dewiki, frwiki, etc. I'm under the impression that the quality and vetting process of articles featured there is of much lower priority than on here, which is a showstopper. There needs to be some sort of vetting process an I don't see the purpose of splitting it wholesale off of ITN, especially given the propensity of an RDBLURB nomination. Additionally, the RD sections on other wikis are rarely that separated from one another. The dewiki calls more or less relate to blurb noms and a brief period in summer when Ongoing was very long. — Knightoftheswords(talk) 05:13, 19 October 2026 (UTC)
I also support the idea of an RD/obituary section with a picture. This is done on the other languages such as French, German and Spanish and seems to work well.
Another option would be a Top Read section to list trending articles like the app.
Whatever is done will require an extensive RfC and planning as was done for the TWAFI change. In the meantime, white space in the desktop view is not a big deal as there is plenty of white space elsewhere on the main page and its exact appearance depends on one's browser, preferences and screen size. And most of our readers use the mobile view which has a single column in which this is a non-issue.
Andrew🐉(talk) 07:03, 19 October 2026 (UTC)
It's super ugly, thanks for bringing it up. Personally I think that the AFI should be horizontal so that it fills two columns, like TFP and TFL. At this discussion someone suggested using more DYK hooks at a time and making the TFA text longer but I think that's just going to put too much work onto the people at DYK. ―Panamitsu (talk) 00:36, 19 October 2026 (UTC)
Make the TFA full-width and move the improve thing (if we must have it) to below the DYK. -- Veggies (talk) 00:36, 19 October 2026 (UTC)
I think making TFA full-width would be a good thing. Can possible give the TFA people the scope to accept longer blurbs (if they were up for it). Neutral on placement of anything else, but TFA should definitely remain at the top. TarnishedPathtalk 04:28, 19 October 2026 (UTC)
I like this idea. Moving AfI to below DYK keeps the ordering the same as it is now for mobile readers, but looks much better on desktop. InfernoHues (talk) 04:33, 19 October 2026 (UTC)
We could have a "Today's Featured Vital Article" or a "Today's Featured WikiProject" section. Additionally, courtesy of User:Eman7blue42 on Discord, "Today's featured Good Article" might also be a good idea. Prost, A.Classical-Futurist (talk) 00:44, 19 October 2026 (UTC)
Ambivalent, leaning “that’s a fine idea” on the first two, but I Oppose the TGA proposal. It would decrease the value of an FA and TFA by showing GAs as well. Chorchapu (talk | edits) 00:46, 19 October 2026 (UTC)
What Wikiproject would we want to feature? I don't think we even have a week's worth. 1brianm7 (talk) 00:49, 19 October 2026 (UTC)
As the person who suggested it, I would oppose TGA. Also, there are simply not enough Wikiprojects (nor enough that would pass scrutiny to be on the main page) to make featuring them a realistic option. Eman7blue42 (talk page | recent edits) 00:55, 19 October 2026 (UTC)
Years ago, when something of that sort was suggested as a possible improvement to GA processes, one objection was that a process that only involved two people would be very vulnerable abuse and that once checks were put into place on top of the GA process it would be effectively duplicating the existing checks for GAs that appear on the main page as DYK facts. Rjjiii (talk) 01:14, 19 October 2026 (UTC)
We already have TGAs; its called DYK, so I oppose that, and I frankly don't get too much value from the first (also echo the concerns above about TGFWP). — Knightoftheswords(talk) 05:14, 19 October 2026 (UTC)
Some ideas I have
1. Widen TFA to be like TFL and TFP (I would personally keep it at the top due to its importance and value).
2. Widen OTD or HUITA and place it at the bottom, but above TFL and TFP Jon698 (talk) 00:45, 19 October 2026 (UTC)
That is the first use of HUITA on-wiki, after it was coined on the Discord! 1brianm7 (talk) 00:49, 19 October 2026 (UTC)
Pardon, but what is that? Chorchapu (talk | edits) 00:50, 19 October 2026 (UTC)
Help us improve this article (HUITA) Jon698 (talk) 00:51, 19 October 2026 (UTC)
Ah, thanks. Chorchapu (talk | edits) 00:52, 19 October 2026 (UTC)
Please don't use that. The correct acronym is TWAFI, or AFI for the wikiproject that manages it. "Help us improve this article" is just the name of the section, which is subject to change. FaviFake (talk) 13:04, 19 October 2026 (UTC)
I'm going to continue using HUITA Jon698 (talk) 01:34, 23 October 2026 (UTC)
@FaviFake: given that everyone calls Wikipedia:Selected anniversaries "OTD" and that hasn't materially impacted its mission, I don't think nomenclature policing is something TWAFI will need. (for the record, though, I pronounce TWAFI like "twahfee" with a heavy East Coast accent, and I do encourage this.) theleekycauldron (talk • she/her) 01:55, 23 October 2026 (UTC)
+1 Finally, I'm not the only one that says it that way! 7amiþ = reform(solidarity).__init__(t, c) # Leave a talkback, TWAfI's wild rn 02:46, 23 October 2026 (UTC)
Although I do think that, likely playing a part in the usage of "OTD", is the fact that having a section of the Main Page called "SA" would be... unideal and awkward at best. Chorchapu (talk | edits) 02:23, 23 October 2026 (UTC)
Yeah. Wikipedians need WP:3LA. FaviFake (talk) 11:37, 23 October 2026 (UTC)
Expand DYK to remove the rotating sets we sometimes have? Enoryt nwased lamaj (talk) 00:52, 19 October 2026 (UTC)
We've had discussions about expanding DTK at WT:DYK and there is firm opposition to the idea. TarnishedPathtalk 04:31, 19 October 2026 (UTC)
We could change the width so it could be equal, it would get rid of some of the space. There's an example here: Special:PermanentLink/1380348776.
I did suggest a "Today's Good Article" in the discord halfheartedly, but DYK essentially covers GAs on the main page.
Another idea I had is we can just move the "Welcome to Wikipedia" banner into just above TFA, having it contain a few sections describing the project. Other Wikipedias do this (e.g. French Wikipedia, which inspired this) Eman7blue42 (talk page | recent edits) 00:49, 19 October 2026 (UTC)
The width change is meant to happen, but we need an admin to perform the edit. Axolitl (talk | contribs) 00:56, 19 October 2026 (UTC)
My TLDR proposal would be to add a new column to the Main Page (which doesn't seem to be a bad idea since Classical-Futurist brought this up), and that is "Today's most viewed articles", helping to keep in sync with the mobile apps' home page (which has an autogenerated "most views articles" section). But if you know me, I like to flesh out on the details, so I'm just going to leave this for now, I will give details later (cause I need to go off-wiki now). Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 00:52, 19 October 2026 (UTC)
I could see "yesterday's most viewed article" being a thing! Sohom (talk) 00:57, 19 October 2026 (UTC)
Yeah, I like that! I'd be like ITN on steroids. If the most viewed article had already been featured, pick the secondmost viewed, etc. FaviFake (talk) 13:06, 19 October 2026 (UTC)
I support this idea tentatively, but it would need its own RfC. And likely filters to avoid bot traffic. Bremps... 05:15, 20 October 2026 (UTC)
There's also a chance that it could be, say, the TFA, or (if a big real-world event happened) covered in ITN. Axolitl (talk | contribs) 05:17, 20 October 2026 (UTC)
Then pick the second one on the list. FaviFake (talk) 10:52, 20 October 2026 (UTC)
Okay, another idea: rotate between TFL and AFI at the bottom of the page, such that TFL remains Monday, Wednesday, and Friday, while AFI is Tuesday, Thursday, and Saturday. Sunday could either be blank or be replaced with a few entries from the Top 25 Report (the most viewed pages from the previous week, my original proposal above). This would make less people see the AFI box, though. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 03:24, 19 October 2026 (UTC)
main page sections are meant to feature the quality (or goals to improve quality) of WP, and the problem with any Top 10 read list is that there is zero quality assessments there. Its interesting but main page is not the place for that. Masem (t) 12:44, 19 October 2026 (UTC)
I was/am perhaps irrationally dissaponted that the AFI main page implementation was never presesnted (such as in the form of a banner) to casual users who liked the main page as it was, nor were said users warned about it once it was finilized. My idea, therefore, would be to move AFI to a full-width module above TFL/TFP, and put ITN and OTD back where they were. Disnewuisux (talk) 00:58, 19 October 2026 (UTC)
I could see that, but I’m concerned that that would really decrease its effectiveness. Most casual readers won’t scroll down that far. I know I didn’t before I started editing. Chorchapu (talk | edits) 01:00, 19 October 2026 (UTC)
I'm mainly concerned with the fact that ITN is no longer the other module that's visible with zero scrolling. Had I known where AFI was going to go (I had literally no idea about this until an hour ago), I would've argued against that placement in those discussions. Perhaps another way would be to list some AFIs right under the contributor and article numbers. Disnewuisux (talk) 01:11, 19 October 2026 (UTC)
As an ITN editor I’m certainly not unbiased on this matter :) but I do agree that TWAFI should not have gone here. I also don’t know if readers will see it in the grey box at top - it doesn’t stand out at all. Chorchapu (talk | edits) 01:14, 19 October 2026 (UTC)
I agree it still wouldn't be very visible, but it doesn't have to be grey like the rest of that box, and it could be a larger font size as well to stand out. I'd make a mockup of it, but I have to wake up in about 7 hours, and I'm not experienced enough to do it quickly.
P.S. Thank you for your service in ITN, it's literally my main source of world news. Disnewuisux (talk) 01:23, 19 October 2026 (UTC)
Interesting ideas… we’ll have to think on all the different plans. And thanks very much for the compliments. Chorchapu (talk | edits) 01:24, 19 October 2026 (UTC)
Having thought about it for a bit, I would support this. Axolitl (talk | contribs) 02:56, 19 October 2026 (UTC)
I support the panel because it leaves a cautionary tale for front page readers on taking Wikipedia seriously as a acceptable source of information. It informs more than a rational argument ever could ~2026-47221-77 (talk) 01:35, 21 October 2026 (UTC)
This is precisely the opposite of what we want! But it wasn't an entirely unforeseeable outcome... Chorchapu (talk | edits) 02:01, 21 October 2026 (UTC)
WP:DENY 7amiþ = reform(solidarity).__init__(t, c) # Leave a talkback, TWAfI's wild rn 02:06, 21 October 2026 (UTC)
Note: The width of the columns were adjusted as they apparently were supposed to be (see ERRORS) and it doesn't look quite as bad anymore. It would probably need to be changed back for the addition of a half-width section to look good. Snowmanonahoe (talk · contribs · typos) 01:04, 19 October 2026 (UTC)
And with this change, I have a new idea: do we have the throughput to expand the size of the DYK set to 15 or so? Snowmanonahoe (talk · contribs · typos) 01:07, 19 October 2026 (UTC)
I don’t know if there are enough hooks or capacity for that. Chorchapu (talk | edits) 01:08, 19 October 2026 (UTC)
DYK does not have the desire or manpower to expand to 10 (from 9), let alone to 15. 1brianm7 (talk) 02:02, 19 October 2026 (UTC)
The current layout, with TWAFI causing a massive blank space under DYK, is untenable. I also feel that TWAFI should go under the other boxes which change daily; having TWAFI which by its nature only changes once a week be at the top makes the main page look more static than it is. My preference is for TFA, ITN, DYK, OTD to retain their original places, and TWAFI to be full-width (or half-width next to some other new box) between those and TFL. Davey2116 (talk) 01:08, 19 October 2026 (UTC)
I said this above, but I don’t think our readers will scroll down so far. You can read my earlier reply for more. Chorchapu (talk | edits) 01:10, 19 October 2026 (UTC)
Template:Article for improvement/sandbox ← this is how much has to be cut to remove the gap completely. Rjjiii (talk) 01:11, 19 October 2026 (UTC)
Wow, that’s really terse and feels somewhat forced. I don’t want to cut that much, but maybe it’s necessary . Chorchapu (talk | edits) 01:13, 19 October 2026 (UTC)
OTOH if it's staying a whole week I think it would be better to not have the same thing right at the top of the mainpage for a week straight, also my (completely unfounded) assumption is that an article needing a scroll down but staying for a week would get at least the same amount of attention as TFA, if not more. With love from Maryland, charlotte 👸♥ 01:16, 19 October 2026 (UTC)
Interesting. I didn’t take into account that, over the course of the week, it will garner more attention. That could work then, putting it lower. I don’t mind that. Chorchapu (talk | edits) 01:19, 19 October 2026 (UTC)
Indeed. Moreover, I do not think it was a good idea to put a section that was not on the Main Page previously right to the top. I understand that we want to garner more editors and teach everyone that Wikipedia needs their help, but still, there are ways to achieve that more slowly and succinctly without such a rapid change. At the very least, the news ought to stay at the top, as they are subject to more change.
Personally, I would append the weekly article for improvement horizontally and only under all the sections that are subject to daily (or even more frequent) change, that is, also below the featured list and featured image of the day (the two sections which could easily be subject to a further swap). BasicWriting (talk) 17:30, 19 October 2026 (UTC)
I like this reasoning as well; i.e. daily stuff on the top, weekly stuff on the bottom. Disnewuisux (talk) 01:14, 19 October 2026 (UTC)
Terrible idea, but maybe we could do a Wadde-Scheier (word barn (I assume)) like on the Pennsylvania Dutch Wikipedia. Prost, A.Classical-Futurist (talk) 02:04, 19 October 2026 (UTC)
Sorry, but what does that mean? Is it a sort of Wiktionary WOTD-esque thing? Chorchapu (talk | edits) 02:22, 19 October 2026 (UTC)
Comment (as a reader, not an editor for over a decade) - It was quite jolting to find ITN moved from its longstanding post. It has been one of my favorite sources of world-wide goings on for so long that I cannot remember when it became so. Seeing a new entry or image there is something I quite look forward to. Now a relatively random new article will appear in one of the two foremost spots on the page (what, once per week)? TFA features one of our best pieces of works and changes daily, which makes sense. Did you know features hot-off-the-press (or greatly improved) new content, which makes sense. On this day is interesting and fun. This new pseudo-recruitment junk, which is not relevant to the vast majority of readers, should be relegated to below TFP or besides TFL & TFP. There was consensus to add this to the main page in some way, sure. Doing so in the current manner is beyond the pale. Please ping me if I need to express this again elsewhere to potentially effectuate change. — Godsy (TALKCONT) 02:52, 19 October 2026 (UTC)
I think you said this a lot better than I could. This new box replaces a useful thing (ITN) in the prime real estate of the page, and shows off what is by its nature a bad article. I'm also not super thrilled that whatever consensus mechanism used for this was kept well away from readers/casual users. Joseph Zadeh (talk) 05:06, 19 October 2026 (UTC)
I agree with both of these points. TWAFI is a good thing to have on the Main Page, but I think it should be near the bottom, where it will be seen by people who have elected to keep scrolling and can be assumed to still be in search of something to do. Moonreach (talk) 20:33, 19 October 2026 (UTC)
Ooh, that’s a great angle. Consider me convinced, on moving it below the blue and green and above the TFL/TFP. Chorchapu (talk | edits) 20:36, 19 October 2026 (UTC)
I just wish I knew where I should be talking about this. I didn't see any discussion about changing the front page beforehand, so I don't know where to properly submit my complaint. Moonreach (talk) 20:38, 19 October 2026 (UTC)
I assume there’ll be a second RFC on what the hell went wrong and what we should change. It’ll most likely be posted on WP:CENT so I recommend keeping on eye on that. Chorchapu (talk | edits) 20:40, 19 October 2026 (UTC)
It's gone relatively well in my opinion. Vandalism hasn't stayed up long, new editors are actually taking an interest, and the article has improved. I think main page balance is not something casual/new readers care about to be honest, it's mainly annoying for "power users" like us. InfernoHues (talk) 20:44, 19 October 2026 (UTC)
+100 Most people won't scroll. If we move it below everything else, I believe we might risk not catching the attention of the fly-by viewers we're trying to convert into editors. FaviFake (talk) 20:46, 19 October 2026 (UTC)
I feel like inconveniencing regular users to draw in occasional users isn't a good strategy. Moonreach (talk) 20:55, 19 October 2026 (UTC)
the regular users aren't gonna be here forever, we need new ones. theleekycauldron (talk • she/her) 20:59, 19 October 2026 (UTC)
And they're not gonna leave just because they need to scroll a little to see the news. FaviFake (talk) 21:00, 19 October 2026 (UTC)
Maybe a section for the Wikipedia:Wikipedia Signpost? It’ll be interesting to see what the casual readers think of the Wiki drama. If that Signpost section makes the left column larger than the right one, then just add more blurbs/RD to ITN. Some1 (talk) 02:53, 19 October 2026 (UTC)
Not a bad idea too :) Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 03:20, 19 October 2026 (UTC)
An interesting idea, but I don’t know if it would be good. Right now the Signpost is kind of a small thing, and readers I think will be entirely uninterested. But who knows, maybe it will improve its importance. Chorchapu (talk | edits) 03:22, 19 October 2026 (UTC)
I think this would be a very interesting idea, the Signpost probably should have some presence on the mainpage OrdinariusFingius (talk) 04:14, 19 October 2026 (UTC)
I don't see this being too interesting to our readers, and it comes off as being a lil WP:NAVELy. I'm also not a fan of potentially airing out Wiki controversies like that out at the open. — Knightoftheswords(talk) 05:17, 19 October 2026 (UTC)
@Knightoftheswords281: The signpost is arguably more useful to readers than AFI. The Signpost contains polished, well-written articles that are complete (at least I assume; I do not partake in it much, so I suppose it could be a partisan, yellow rag etc.). Articles for improvement features lackluster, poorly-written articles that are incomplete. I know which I would rather read to gain some sort of understanding or knowledge. Moreover, the Signpost is not asking readers to literally become a contributor like AFI is; what is more navel-gazing (in a roundabout way) than blatant overtures to join our editing corps? — Godsy (TALKCONT) 07:42, 19 October 2026 (UTC)
At least AFI is actually attempting to link the reader into the processes that make Wikipedia. I don't see how any random reader would benefit from the WP:SIGNPOST, which features a bunch of jargon, people, and institutions that they're statistically likely not not really know and frankly care too much about. Also, as part of that, I'd say that the main page should focus on highlighting encyclopedic work, which The Signpost isn't. — Knightoftheswords(talk) 07:56, 19 October 2026 (UTC)
The main page should focus on highlighting encyclopedic work; fully agreed. It seems, with the intro of AFI, that is not the standard anymore; not saying that the Signpost is a good idea but just that it is a better one than AFI. — Godsy (TALKCONT) 08:14, 19 October 2026 (UTC)
+1 I'm an admin who spends a lot of time around here and I find the Signpost inscrutable much of the time. Dclemens1971 (talk) 20:47, 19 October 2026 (UTC)
This should have been all sorted out prior to TWAFI going live. TarnishedPathtalk 04:24, 19 October 2026 (UTC)
As far as I can see, the blank space has only switched sides. I also think this section title fails the requirement to have a neutral opening statement to a discussion. I will say one thing - it's a bit strange to see the main article still locked while the collaboration article is open to editing. Some may not remember, but it used to be the case that editing the main article was actively encouraged, and the rule was that the main article should not be locked unless the vandalism could not be dealt with by reverts/rollback/undo, and even then preferably for a few minutes or hours max. Don't take this as me disagreeing with putting the collaboration of the week at the top and leaving it open (I think it's great), it's just that the split reality strikes me as odd. ~2026-55913-20 (talk) 04:30, 19 October 2026 (UTC)
This is not an RfC, so it doesn't need a neutral opening statement. Axolitl (talk | contribs) 04:32, 19 October 2026 (UTC)
Please review WP:TALKHEADPOV. Thank you. ~2026-55913-20 (talk) 04:36, 19 October 2026 (UTC)
I see what you mean. I was confused by you saying fails the requirement to have a neutral opening statement to a discussion, which is the language used for RfCs. Axolitl (talk | contribs) 04:39, 19 October 2026 (UTC)
I was so frightened by this OrdinariusFingius (talk) 04:33, 19 October 2026 (UTC)
IMHO the simplest option is to make HUITA full-width like tFL and tFP, but leave it at top so it's the first thing newbies read.
Digression: do newbies ever visit WP:MAIN? It strikes me as something only an insider would find.
A nice ancillary benefit is that experienced users can then slot the ITN section into where their eyeballs habitually expect it by just scrolling down. Bernanke's Crossbow (talk) 04:55, 19 October 2026 (UTC)
I like this too! Axolitl (talk | contribs) 05:19, 19 October 2026 (UTC)
You mean Special:GoToComment/c-Aaron Liu-20260702174700-Aaron Liu-20260702173800? In solidarity, Aaron Liu (talk) 08:36, 20 October 2026 (UTC)
Yes. Bernanke's Crossbow (talk) 23:42, 20 October 2026 (UTC)
This was such a dumb idea, even if it gets a handful of people editing Wikipedia. The visual balance is completely thrown off one of the most famous front pages on the internet. It obviously should go below the featured image to fix the space issue. All the other material featured on the front page is the product of a significant amount of time of thousands of people. I find it insulting personally that such a poor quality article shares such a space and I am even more skeptical as the chosen article is so insignificant and so juvenile. The image used is basically an advertisement for IT'SUGAR, a shit overpriced American mall store. Disappointed that this is the best this community can come up with to draw more people into the club, which has pretty obvious solutions, some of which are being followed already. Thriley (talk) 05:21, 19 October 2026 (UTC)
As somebody who doesn't understand it, I don't think it's fair (or necessary) to say "a dumb idea". You have some good points about the image though (and I personally think it's a bit cluttered); I think if you'd like, you can raise them at WP:ERRORS? GreenLipstickLesbian💌🧸 05:25, 19 October 2026 (UTC)
I think it was a bad idea. In my culture we often call those dumb ideas. I wanted to use a stronger form of bad. Thriley (talk) 05:27, 19 October 2026 (UTC)
An image being featured doesn't mean its an advertisement, but I do agree that it is kind of iffy having TFA, DYK, OTD, and ITN dominating the front page and then having an article explicitly of poor quality take up so much space. I understand that's sort of the point, but man... especially with the points I raised below relating to its week long duration. — Knightoftheswords(talk) 05:30, 19 October 2026 (UTC)
Next week will be Online encyclopedia. Is that as insignificant and so juvenile? Axolitl (talk | contribs) 05:36, 19 October 2026 (UTC)
Dinner comes first. You stuff yourself with poor quality candy in private. Thriley (talk) 05:38, 19 October 2026 (UTC)
... What? FaviFake (talk) 00:02, 21 October 2026 (UTC)
I think AFI should be placed in between DYK and TFA OrdinariusFingius (talk) 05:39, 19 October 2026 (UTC)
I feel like notifying the relevant WikiProject(s) was enough already (example). Most people read Wikipedia, not edit it. Yes, it may attract new editors, but shoving this in the faces of readers is too much in my opinion. Either move it below On this day or entirely remove it from the Main Page. Fortek67 (talk) 19:44, 19 October 2026 (UTC)
Given that HUITA is going to appear for a full week, rather than a day, I frankly don't buy the argument that pushing it say, above TFL/TFP will mean that it will be less effective. That's an argument that only really compares to the other sections of the MP, which (even ITN) changes on a daily basis. I don't think that's a bad idea. Alternatively, maybe putting it up in the welcome box as some have stated, though I have no idea how that would work aesthetically or what not. Perhaps I'm biased as a regular ITN contributor, but as indicated above, there's clearly a lot of people that see harm being done in pushing it and OTD down the page.
In any case, especially if this isn't a trial run, but irrespective of that, the implementation of this was very poor UI wise and should have been better though through via the preceding two months of transition. Seems like there was very little attempt to communicate with ITN, DYK, OTD, etc., and with DYK announcing that they won't increase hook counts, this is especially bad and not a good look for one of the world's premier websites. — Knightoftheswords(talk) 05:27, 19 October 2026 (UTC)
I can easily see the article being changed more than weekly. The weekly time was mainly chosen because that's how AfI already worked, but it was brought up in the RfC that a faster pace should probably be done if all went well. InfernoHues (talk) 05:33, 19 October 2026 (UTC)
ITN has had plenty of notice of this. For example, see New-look main page opportunity for ITN. The reaction in that discussion was to wait upon the TWAFI implementation and so here we are. In the meantime, ITN has been preparing its own RfC for an extensive internal reform which starts with a proposal to abolish ITN altogether. That would be a quick fix for the white space! Andrew🐉(talk) 07:21, 19 October 2026 (UTC)
The AFI section contains a lot of unnecessary text. Firstly, there's absolutely no need to explain what the article is about when it's linked. Secondly, pointing out to what sections should be improved is a bit weird because it requires live updates as those parts of the article may have already been dealt with. Thirdly, WPAFI, which is also linked, is clear enough so that the last sentence seems redundant. While the idea to highlight content for improvement on the main page is good, its implementation looks poor and misaligned with the brevity and conciseness of all other sections on the main page. --Kiril Simeonovski (talk) 07:14, 19 October 2026 (UTC)
While it was clear that there was consensus to put TWAFI on the main page, the closer acknowledged the consensus about its placement on the page was “weak”. A weak consensus should have never been the basis for the biggest change to the main page in ages. The addition of TWAFI should be temporarily suspended and a new RFC should take place specifically to decide on TWAFI’s main page placement, widely advertised to ensure participation from all interested parties. Dclemens1971 (talk) 10:22, 19 October 2026 (UTC)
I feel like repeating this sentence because it sums up this whole discussion quite nicely:
A weak consensus should have never been the basis for the biggest change to the main page in ages.
There should have been more time, and much more awareness by the casual reader about this process. Disnewuisux (talk) 10:40, 19 October 2026 (UTC)
+1 Given that this is not open to normal challenges through the editing cycle (i.e. one must be an interface administrator to alter the main page), a strong consensus is [warranted] before implementation especially on our most prominent page. The decision to implement was poor; thus, [I]t should be pulled. It may have been implemented because [T]here is no easy way to overturn it and [this serves to] to diminish the [immediate] outrage discontenment through a false faux-status quo and to deprive us of a proper discussion; this is so wrong! Such possibilities would not need to be speculated upon if this had been handled properly. Clear proponents of AFI are even gatekeeping at WP:ERRORS to diminish the chance this is remedied through a quick removal. — Godsy (TALKCONT) 21:59, 19 October 2026 (UTC)
Wtf? I'm not "gatekeeping" anything. The rules of WP:ERRORS are as clear as day. "Removing a section" is not an ongoing error. Did you expect your complaint to remain there indefinitely?
Only three editors out of at least a hundred think TWAFI should be pulled outright. Good luck getting consensus for that, on a page which has no archives. FaviFake (talk) 22:09, 19 October 2026 (UTC)
You are not a regular participant at WP:ERRORS. You are obviously a strong proponent of main-page AFI (evident here in this thread). You could have left that for anyone to remove if it was appropriate to do so (you also technically 'declined' something you do not even have the ability to carry out). Instead you remove it with a drawn-out edit summary, a seeming ostensible attempt to insulate the action. If it truly was not gatekeeping, it certainly easily lends itself to appearing that way. — Godsy (TALKCONT) 22:30, 19 October 2026 (UTC)
So I can't perform basic maintenance by removing blatantly off-topic discussions because I supported the RfC? Where is that written? FaviFake (talk) 22:37, 19 October 2026 (UTC)
Inability is different from advisability. — Godsy (TALKCONT) 22:48, 19 October 2026 (UTC)
Godsy participated in the RfC and so had their say. I participated too and voted B like them too. But, given the outcome of the RfC, its result should be given a fair trial. The rush of editors to the article is much greater than I expected and we should continue to observe how this works out. Making hasty changes would confuse the issue and there's no pressing need as the side effects such as a bit of white space seem to be entirely cosmetic. And a technical option has been provided for those who can't bear to look at a bit of white space. Andrew🐉(talk) 22:17, 19 October 2026 (UTC)
Noting that administrators, not exclusively interface administrators, can edit the main page. Regarding the decision to implement, it came from this closure of a month-long discussion, which found that:
There is a consensus in favor of adding This Week's Article For Improvement to the Main page. However, a consensus to change the main page layout in this significant of a way reached with under 100 participants is, under policy, a relatively modest one. Given this, and given a consensus that ranges from ambiguous to "no consensus" for one of the necessary subquestions, the decisions reached in this RfC may be ripe for revisiting in a few months.
I wouldn't have made the change on the Main Page if there wasn't community backing behind it, i.e. pushing a fait accompli. Yes, the consensus is of a relatively low level compared to the magnitude of the change, and consensus can change, but absent an implementation of TWAFI, there wouldn't be any reason to except more participation in another discussion on the exact same points. However, we should absolutely be conscious of the fact that putting it into a much broader light, and allowing people to see the impact of the change, will lead to many editors reconsidering their position (in one way or the other), and new editors/readers being drawn into participating in a future discussion over whether to keep TWAFI on the Main Page.
This future discussion is necessary, as stated in the closure itself, if we want a broader discussion with more concrete evidence to establish a stronger consensus for or against this section, but it can't proceed if we stall the initial implementation that followed up from the existing discussion. Chaotic Enby (in solidarity · talk · contribs) 22:58, 19 October 2026 (UTC)
Feline Image Lengthening Lines Enough Retroactively (of the day). CMD (talk) 11:01, 19 October 2026 (UTC)
I strongly oppose having AFI at the top of the main page; I don't think we should be messing with the top of the main page without largescale community consensus. I support having it stretching across the whole screen like TFL or TFP, below TFA/ITN/DYK/OTD; being on the main page for a full week should get it enough exposure, even if it's further down. Skarmory (talk • contribs) 11:06, 19 October 2026 (UTC)
Perhaps we could have a space advertising wikievents such as editathons. I do think that the AFI needs some moving around so the main page is recognizable, but I definitely think that its inclusion is an amazing idea (just look at how many edits have been made to the article, it's bound to get some people into editing). Gaismagorm (talk) 11:32, 19 October 2026 (UTC)
a space advertising wikievents such as editathons
We have that at community portal on the sidebar, which feels the right place for it.
I definitely think that its inclusion is an amazing idea (just look at how many edits have been made to the article, it's bound to get some people into editing).
Yes, absolutely! And so many of them are not registered! TWAFI is working exactly as intended, and moving below anything else will totally defeat its purpose. FaviFake (talk) 13:17, 19 October 2026 (UTC)
No evidence is provided for the claim that a lower position would not result in attention for TWAFI. Dclemens1971 (talk) 13:40, 19 October 2026 (UTC)
If I remembered the RFC correctly, there was a group of editors that said that putting AFI below the four other sections would reduce the success of AFI. I'll be glad if someone were to correct me if I'm wrong, though. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 13:44, 19 October 2026 (UTC)
You don't need "evidence" to reach the conclusion that if something is in the middle of a page rather than at the very top, fewer people will see it. This is precisely why P2 was chosen in the RfC. FaviFake (talk) 13:48, 19 October 2026 (UTC)
If TWAFI were somewhere else on the page, it would still be getting vastly more clicks than it was before it was on the main page. It doesn't need to be in P2 to get clicks. Dclemens1971 (talk) 20:29, 19 October 2026 (UTC)
Yeah, I guess that's true. But it's clear we'll need an RfC to decide where to place it, so i don't see the point in continuing this discussion. FaviFake (talk) 20:31, 19 October 2026 (UTC)
Yes, the point (that I made above, hours ago) is that we will need a separate RFC on where to place TWAFI on the Main Page. Your claim that moving below anything else will totally defeat its purpose is unsupported. Dclemens1971 (talk) 20:50, 19 October 2026 (UTC)
Sure. I think I'm just tired. FaviFake (talk) 20:51, 19 October 2026 (UTC)
Frankly I'm now of the opinion we should trash our Main Page and rebuilt it from scratch![Joke] Okay that's maybe a bit much, but I do think we should continue tinkering with the Main Page. I don't think that it should be something that is set in stone for all time; Wikipedia is an evolving project, and our Main Page should be evolving alongside it. I looked at other language Wikipedias for some inspiration and I recommend other editors do as well. Here are a few I found interesting: French Wikipedia (which has an explanation of what Wikipedia is and how users can contribute), Tagalog Wikipedia (not a fan of the color scheme, but it has an explanation of what Wikipedia is and how users can contribute), Vietnamese Wikipedia (has boxes of what needs to be improved), Italian Wikipedia (they have a section for the Nobel Prize winners and feature the image/quote/source/desination of the day/month from a few of our sister projects), and Farsi Wikipedia (looks essentially the same to our Main Page, but they have a box describing Wikipedia below their FA and DYK equivalents). There are few that are radically different from ours too, like Basque Wikipedia (they have a lot educational videos!). I found it kind of funny that a few of these have uneven columns leading to whitespace.
I really think that some sort of box describing Wikipedia would be good, like something along the lines of French Wikipedia and Tagalong Wikipedia. All we have is the banner reading "Welcome to Wikipedia, the free encyclopedia that anyone can edit". We should actually explain what that means to readers. Maybe it goes above FA, or below DYK, or somewhere else, but we should really have something like this on the Main Page.
Regarding readers not liking AFI being there, this was decided in an RFC months ago. If readers are looking for ITN, its still there, and I imagine its not going away anytime soon (unless the crazy proposal being workshopped at this RFC happens...). Eman7blue42 (talk page | recent edits) 15:04, 19 October 2026 (UTC)
Community Feed choices for the home screen of the Wikipedia iOS app
You should try the Wikipedia app which provides a variety of novel sections on its home page besides the usual ones. It also lets users decide which of these will or won't be displayed and in which languages. So you can build your own custom home page. Andrew🐉(talk) 20:14, 19 October 2026 (UTC)
That’s very cool. Unfortunately, other than that the app is crap, so I’ll never use it. Chorchapu (talk | edits) 20:22, 19 October 2026 (UTC)
I think the app is pretty good for reading. For editing, it's awful. InfernoHues (talk) 20:24, 19 October 2026 (UTC)
Im inclined to agree, but I never use it; I tried editing on it once or twice many months back (maybe over a year ago by now) and was so disgusted I’ve not touched it since. Chorchapu (talk | edits) 20:27, 19 October 2026 (UTC)
Can confirm. FaviFake (talk) 20:30, 19 October 2026 (UTC)
I am familiar with the Wikipedia app, it is what I use to read Wikipedia on mobile. I would not like the Main Page on web to be customizable for users. Eman7blue42 (talk page | recent edits) 23:58, 19 October 2026 (UTC)
We could make OTD full-width and split it into 2+ columns of bullets? theleekycauldron (talk • she/her) 16:45, 19 October 2026 (UTC)
It would make more sense to divide DYK which has 9 bullets to OTD's 4. Nine hooks in a block are too much of a wall of text visually and so would benefit from more structure. For example, the GA's might be separated from the new articles with a sub-heading or two. And this might provide an opportunity to add another picture: one for each sub-section.
So, I suggest that DYK experiment with such expansion while the white space provides room for growth.
Andrew🐉(talk) 16:57, 19 October 2026 (UTC)
It might make sense aesthetically, but DYK seemed pretty strapped at the moment, and regulars would likely reject the extra formatting work. Rjjiii (talk) 17:00, 19 October 2026 (UTC)
Separating out the GAs from the new/expanded articles when building and queuing sets is an extra layer of tedium for it's not clear what gain. Dclemens1971 (talk) 20:30, 19 October 2026 (UTC)
Also, what about making TFA full-width? It's a big block of text and certainly deserves the prominence; it might be a bit shorter but it can still fill the space and restore balance to the Force Main Page. theleekycauldron (talk • she/her) 22:33, 19 October 2026 (UTC)
This is an equally good idea which I think should have just as much support behind it. FaviFake (talk) 22:35, 19 October 2026 (UTC)
Hello, i support withdrawing it completely, push it below in the news, it's very out of place, thank you MazurTutejszy (talk) 15:15, 20 October 2026 (UTC)
push it below in the news
withdrawing it completely
What? FaviFake (talk) 15:17, 20 October 2026 (UTC)

Not commenting on the placement on the main page, but it does appear that adding the feature to the main page is working. I just checked this week's article for improvement and there are hundreds of edits. So it appears to be working as intended. --Enos733 (talk) 15:11, 19 October 2026 (UTC)

Silly idea which might have some merits: put our centralized discussion (maybe with links described in a more beginner-friendly version) on the Main Page in that blank space. Helps with three main aspects in my opinion:

Filling the blank space, obviously
Keeping more casual editors/readers informed of major changes, and in turn allowing them to provide input
Showing readers a quick way to see "the other side" and understand how community discussions shape Wikipedia

And a bonus consequence of these latter two points is that we open another point of entry for readers to get involved with the community and maybe become editors themselves! Chaotic Enby (in solidarity · talk · contribs) 17:46, 19 October 2026 (UTC)

@Chaotic Enby: There is an instant fix (and you are uniquely positioned to carry it out). You could [now] revert your implementation of main-page AFI based on weak placement consensus which is causing an obvious aesthetic issue on our most prominent page. It seems obvious now (even just through the existence of this long thread) that a proper follow-up discussion regarding placement etc. [would be better pre-implementation] and that the implementation was inappropriately early. As it stands now, your suggestion above is just proposing a cure to a disease that you created. — Godsy (TALKCONT) 22:16, 19 October 2026 (UTC)
Please see note b in the RfC close. InfernoHues (talk) 22:27, 19 October 2026 (UTC)
A discussion not being mandatory does not mean it is not a good idea and consensus can change. — Godsy (TALKCONT) 22:46, 19 October 2026 (UTC)
The closer did not merely say a discussion is not mandatory. FaviFake (talk) 22:54, 19 October 2026 (UTC)
You are treating the note (which you solely quote from below) as mutually exclusive from the statement it amends, which has led you to poor conclusions. — Godsy (TALKCONT) 02:02, 20 October 2026 (UTC)
I think it's deeply unfair to blame Chaotic Enby for a consensus they neither created nor assessed. They couldn't reverse their implementation even if they wanted to, because that's what the community chose (as found by the closer). Attacking Chaotic Enby for others' choices is counterproductive and language like "disease" is, imo, needlessly inflammatory. theleekycauldron (talk • she/her) 22:31, 19 October 2026 (UTC)
@Theleekycauldron: Fair enough. I have striken parts of my statement above. I stand by the language itself as a metaphor, but admit that perhaps the direction it was sent was not entirely due. — Godsy (TALKCONT) 22:46, 19 October 2026 (UTC)
@Godsy See this part of the RfC closure:

There is a world where establishing firm consensus on this crucial matter would be required, and thus the implementation would be delayed. This was not the case here. Given the commentary for this proposal overall, even by those who expressed serious concerns about P2 and/or who wanted an alternative not originally listed, there seemed to be enthusiasm for moving forward, and thus no consensus to delay pending a firm decision on this issue.

If you disagree with @Barkeep49's closure, you are welcome to contest it at WP:AN. FaviFake (talk) 22:32, 19 October 2026 (UTC)
FWIW, I completely agree with the sentiment in this discussion that the main page now looks off-keel and that having AFI so prominently featured is jarring and not ideal. I hope this brainstorm thread results in a more formal RFC so that we can restore balance to the main page. FlipandFlopped ㋡ 22:02, 19 October 2026 (UTC)
That is the end goal, yes. FaviFake (talk) 22:10, 19 October 2026 (UTC)
Just wanted to let everyone know that they can help write the next AFI template at {{Article for improvement/data/2026/44}} before Sunday when it is protected. Feel free to add and improve the information there before it is protected, so that there aren't so many ERRORS reports about it. Axolitl (talk | contribs) 01:08, 20 October 2026 (UTC)
Meta meme to lighten the chaos :) Added 01:34
Looks shorter which might help with MP balance. Also doesnt need to be that long because, if you know what Wikipedia is, then you know what an online encyclopedia is.Meta moment 🤣 But could someone help me add next week's box into the Wikipedia:Main Page/sandbox to test how this shortened blurb would look like? Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 01:26, 20 October 2026 (UTC)
Haha. It isn't actually going to be that short, it's just missing the article suggestions. Axolitl (talk | contribs) 01:28, 20 October 2026 (UTC)
I kept the description short and added only two bullet points to try and minimise the space it takes up. Chorchapu (talk | edits) 01:38, 20 October 2026 (UTC)
Attempts to shorten the currently running TWAFI blurb at ERRORS have been opposed on the basis that the RfC locked in a set format. 1brianm7 (talk) 01:46, 20 October 2026 (UTC)
Nothing in the RfC stops us from removing a bullet point. The wording "starting template" was specifically chosen for this reason. We can't change the entire format, but shortening the description and removing a bullet point should be fine. InfernoHues (talk) 01:49, 20 October 2026 (UTC)
💯 Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 01:51, 20 October 2026 (UTC)
The RfC selected a layout, but minor tweaks should really be feasible. No plan survives first contact, to paraphrase Moltke. Chaotic Enby (in solidarity · talk · contribs) 01:51, 20 October 2026 (UTC)

Update and summary

The column widths have been adjusted again (see ERRORS again) to 46%/54%, removing the gap entirely. Personally, I don't think these width changes are ideal long-term (short-term this is for sure the right decision) as I beileve TFA should be the most prominent MP element. I've been following the discussion, and here is my attemptedly-neutral shortlist of ideas that seem to be gaining traction:

And noting that DYK regulars are firmly against expanding DYK. Snowmanonahoe (talk · contribs · typos) 23:41, 19 October 2026 (UTC)

@TFA coordinators: what are your thoughts on making TFA full-width? Snowmanonahoe (talk · contribs · typos) 23:43, 19 October 2026 (UTC)
We would accept and use whatever was given us at TFA. Trimming from a lede which is often twice the length we are allowed is one of the difficult parts of the job. Wehwalt (talk) 13:02, 20 October 2026 (UTC)
Lovely! Once a new discussion continuing this has been created at the Proposals village pump, I would support a full width TFA, with TWAFI taking its current place (top left). Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 13:17, 20 October 2026 (UTC)
I would much prefer TWAFI to be made full width and placed at the top of the page, with TFA retaining its longstanding place below. The prose content of TFA won't be well suited to a wide view where readers have to scan across the whole page (which is usually wider than a typical article page) to read it. TWAFI is much more of an information box without direct prose, and will be noticed most if it's top and full width. Cheers  — Amakuru (talk) 17:10, 22 October 2026 (UTC)
Note if any section were to be made full-width, it could still be laid out with multiple internal columns if desired to improve legibility. isaacl (talk) 02:29, 23 October 2026 (UTC)
Honestly this topic needs to be more organised, there's both people who are actually responding to the question (brainstorming), and there's people who are complaining about TWAFI as a whole (even though the aftermath of confectionery store being on the main page says otherwise). Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 23:53, 19 October 2026 (UTC)
The 46/54 change was explicitly made as a temporary measure until something more could be resolved. The status quo for a decade plus is 55/45. The change from that to 50/50 in the immediate wake of TWAFI was also explicitly made as a temporary measure; I was the only person who expressed an opinion on it in the RfC, which was opposition. Personally, unless TFA wants it (and we already know DYK doesn't), I'd say that ITN, TWAFI, and OTD should work out how they each reduce or move out of the top to fit in size (this position doesn't account for whatever the idea of splitting RD is). 1brianm7 (talk) 23:54, 19 October 2026 (UTC)
@Snowmanonahoe: As a group, I don't think we have discussed this yet. One of us will post here if we have a consensus opinion about this specific proposal. If anyone has questions about any idea's implementation (like how it could work logistically or technically) feel free to also ping us. Z1720 (talk) 00:39, 20 October 2026 (UTC)
I think a combination of changing the column widths and shortening the AfI template would work. That's not my preferred option, but it's the easiest one to implement. InfernoHues (talk) 01:34, 20 October 2026 (UTC)
And also keeps TWAFI visible without scrolling, which would otherwise reduce its effectiveness. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 01:45, 20 October 2026 (UTC)
Anything but the 46%/54% columns (it looks worse to me than having the gap below DYK). I'll also throw in my suggestion again for a new module that just explains what the English Wikipedia is.
For now, we can shorten AFI, but I don't think we should be moving AFI below the columns, as it is not in the spirit of the original proposal. Eman7blue42 (talk page | recent edits) 02:01, 20 October 2026 (UTC)
I don't think this was proposed yet, but what about slightly longer TFA summaries going forward?
Just add a sentence or two and I think we'd be good. Bremps... 05:20, 20 October 2026 (UTC)
I don't see it as particularly desirable to expand TFA to take up more space as a solution, considering TFL/TFP are already getting stuffed away underneath the rest of the main page, despite being featured content. Especially for FLs I think we are doing a disservice by sidelining it; it's some of our best content after all. If we're discussing an overhaul of the main page is in order, I would like us to do something about that, like putting TFL/TFP up alongside TFA, DYK underneath TFA and AFI under TFL/TFP. Prioritizing showing off good stuff and getting more people to edit, essentially. –Maltazarian ᚾparleyinvestigateᛅ 18:20, 20 October 2026 (UTC)
With this week’s new article for improvement (Mechanic) live on the main page, the gap is now in the right column. Some1 (talk) 04:20, 26 October 2026 (UTC)
It's also because ITN has reduced to three news reports, and OTD has been reduced from five days to four. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 04:22, 26 October 2026 (UTC)
I don’t think we need to fill the “gap” with anything then, and readers will just have to accept that these two main page columns can sometimes be uneven. Some1 (talk) 04:30, 26 October 2026 (UTC)

Criticism of the addition of AFI to the main page

I was going to post this at Talk:Main Page § Why is there a new panel on the main page?, but that discussion was closed while I was typing:

I think featuring an article for improvement at the top of the main page may cause that article to become a target of unintentionally disruptive editing by inexperienced users like the ones who would treat the newcomer tasks like a game they should try to win at. For example, an editor who wants to expand the article might ask an LLM to generate paragraphs to add to the article, and they might paste all that text into the article without checking for flaws. – MrPersonHumanGuy (talk) 11:19, 20 October 2026 (UTC)

That specific scenario has already happened a couple of times. People noticed it pretty quickly and reverted with an explanation. The edit notice shown to new users also mentions not using LLMs. InfernoHues (talk) 12:13, 20 October 2026 (UTC)

Targeted discussion on proper position placement of TWAFI

I think we need a more targeted brainstorm discussion on the actual position/placement within the main page itself. Contrary to some above, I don't think TWAFI is a "stupid idea" and I think there's a fairly good consensus that it should go somewhere. The question which lacks consensus is where it should float (at the top, mid-section, or bottom)?

I agree that having it be at the very top both (a) confuses people who have been used to, for decades, seeing ITN at the top and (b) is more likely to attract unhelpful or disruptive edits. Screening out users who just click the first thing they see when they open Wikipedia, and thinning down the pool of people editing the article to only those who take the time to actually 'scroll through' the entire main page, would likely significantly reduce the number of disruptive edits. Opening up to thoughts from the community on this. FlipandFlopped ㋡ 15:14, 20 October 2026 (UTC)

Given that TfA coordinators said they'd be willing to do a top bar, I think doing that and putting TWAFI below DYK would be nice. InfernoHues (talk) 15:18, 20 October 2026 (UTC)
I think putting TFA as a top bar would lead to the same criticisms from ITN folk (ITN would still be moved down, this time below TFA). I think there should be an option of simply extending the TFA space vertically to make the space needed. Eman7blue42 (talk page | recent edits) 16:35, 20 October 2026 (UTC)
Yes, making the TFA box deeper rather than wider makes sense. The main reason that the desktop view has columns is that long lines of text are not easy to read and so the TFA blurb wouldn't look good if stretched across the page horizontally. Andrew🐉(talk) 16:47, 20 October 2026 (UTC)
My preference is still to put TWAFI between the blue/green sections and TFP. Chorchapu (talk | edits) 16:50, 20 October 2026 (UTC)
I think that we should start thinking about how to format a proper RFC on that. I think there would probably be two questions: Where to put it, and how? Chorchapu (talk | edits) 15:50, 20 October 2026 (UTC)
If putting it at the top isn't an option, then our options are putting TWAFI between ITN and OTD, below OTD (still in the column), or below the columns entirely. If we choose to put it below the columns entirely, we'd then have to figure out where it goes among TFL and TFP. The AFI editors would be willing to work with any of these options I'd imagine, though a higher placement on the page would probably be preferred by them. Eman7blue42 (talk page | recent edits) 17:08, 20 October 2026 (UTC)
If we're going to do a placement RfC, all the options should be discussed. So to your list we can add below DYK, above DYK, filling the gap with a new RD section, etc. InfernoHues (talk) 17:11, 20 October 2026 (UTC)
All those are conditional on a consensus for a new RD section. I'm gonna make a list of each scenario:
  • New Recent Deaths section or TFA made wide and moved up - allows TWAFI to be placed under TFA or under DYK. I do not think a clear consensus would be found for moving TFA up though.
  • TFA expanded - allows TWAFI to be placed in the blue column either under ITN or under OTD. Since TFA is willing to work with whatever space is given I'd imagine they'd be okay with this.
  • TWAFI made wide and placed under columns - keeps TFA, DYK, ITN, and OTD the same as they were before. Further discussion would be had about its placement among TFP and TFL.
Eman7blue42 (talk page | recent edits) 17:27, 20 October 2026 (UTC)
Perhaps this would be better worked as a main page RfC. Many options are planned to significantly impact TFA. ITN is already workshopping a megaRfC, so options in that that are not internal to ITN could be added. 1brianm7 (talk) 18:12, 20 October 2026 (UTC)
From what I can tell, these are all the serious proposals that have been set out so far:
  1. TWAFI to the left side; expanded RD on the right side (we'd have to figure out where exactly)
  2. TFA expanded to full width and placed at the top; TWAFI to the left side
  3. TWAFI full-width below the blue/green columns, above TFL/TFP
  4. Remove TWAFI altogether (unlikely, since it has unambiguously worked)
  5. Another module on the left side (the Signpost, WP:CENT, or something else?)
  6. Status quo of 46/54 columns
  7. AFI above all, with white background
  8. All featured content together (TFL/TFP to the top); total reoganisation of the page
Chorchapu (talk | edits) 19:07, 20 October 2026 (UTC) added #7 and #8 Chorchapu (talk | edits) 21:24, 20 October 2026 (UTC)
There's also Special:GoToComment/c-Aaron Liu-20260702174700-Aaron Liu-20260702173800, AFI above TFA and with a white background. This had a handful but only a handful of supporters in the initial TFAFI RfC. (To Andrew's concern about desktop unlimited width, this would solve that as the AFI box's sentences are short anyways.)
We would likely need to remove some of the options for a coherent RfC. In solidarity, Aaron Liu (talk) 20:26, 20 October 2026 (UTC)
I really liked that one, because it solves the spacing problem, places TWAFI right below "anyone can edit", and works on both desktop and mobile. 7amiþ = reform(solidarity).__init__(t, c) 20:32, 20 October 2026 (UTC)
I like it too! FaviFake (talk) 20:39, 20 October 2026 (UTC)
Yes, I forgot about that one but that works too. And I agree that we should slim down the options before going to a formal RFC. Chorchapu (talk | edits) 20:34, 20 October 2026 (UTC)
I suggest a maximum of five (including the "no" option), based on preliminary consensus found here. 7amiþ = reform(solidarity).__init__(t, c) 21:09, 20 October 2026 (UTC)
I'm not sure putting TWAFI above everything that would get enough support, especially with the reaction against its current position we've seen here already. I think the RFC is going to see a lot of pushback against TWAFI at the top of the page due to any variation of it pushing either ITN or TFA down.
Regarding trimming options, given what I've said, I don't think we should consider Option 2 (wide TFA) or Option 5 (adding something new). Adding something new without defining what that thing is first is probably always going to fail. Not that I am against adding something else new to the Main Page, but it should be an entirely different RFC discussion.
Honestly any change to the Main Page should be minimal (we've already added TWAFI to it we shouldn't go too overboard). I'd also add just expanding the TFA blurb as an option. Eman7blue42 (talk page | recent edits) 21:05, 20 October 2026 (UTC)
I also suggested having TFA and TFL/TFP side-by-side now that we're messing with the main page anyways. TFL/TFP has been marginalized to keep the status quo, but now that we're messing with the main page anyways it's two birds with one stone; fix the layout of the main page by moving featured content to where it is visible. –Maltazarian ᚾparleyinvestigateᛅ 20:46, 20 October 2026 (UTC)
Another good idea! Looks like I'll need to make a new list :) Chorchapu (talk | edits) 20:50, 20 October 2026 (UTC)
TFL is only three days a week, so making it no longer a line would effectively require two different layouts. And making TFP a half-box would also shrink the picture. I do not think a proposal that simultaneously marginalizes TWAFI, ITN, OTD, and DYK has a snowball's chance in hell of succeeding. 1brianm7 (talk) 20:57, 20 October 2026 (UTC)
I like this! I've always wondered why those featured thinghies were all over the place. FaviFake (talk) 21:04, 20 October 2026 (UTC)
I agree with 1brianm7's reasoning here. Anyways, this RFC should be focused on how to better incorporate TWAFI onto the Main Page with minimal disruption. Moving TFL and TFP around are out of scope of this discussion should be left for another day. Eman7blue42 (talk page | recent edits) 21:09, 20 October 2026 (UTC)
We can just propose them as an option, if we can develop a layout that kills two birds with one RfC. FaviFake (talk) 21:11, 20 October 2026 (UTC)
I was just reminded by someone elsewhere (I see now 1brianm7 has also astutely pointed this out here) that TFL and TFP do not take turns, because TFP is every day. That was somewhat of an oversight, as it scuppers my whole idea. Whoops! –Maltazarian ᚾparleyinvestigateᛅ 21:58, 20 October 2026 (UTC)
My preference is ITN, then TWAFI, for one column. - Enos733 (talk) 01:24, 21 October 2026 (UTC)
Hello, relatively new to editing but long-time reader here. Exact placement aside, my thought on TWAFI is that its box should be a different colour (perhaps light grey) to visually differentiate it from the rest of the column it sits in, since TWAFI is thematically at odds with the rest of the column's content. I get the impression that the green column's theme is curated info extracted from articles (TFA, DYK), while the blue column is for date-specific info (ITN, OTD). TWAFI is very different from either of these themes, so it would make sense for it to be colour-coded accordingly. I therefore also think it'd be logical for TWAFI to be at the bottom or top of the column, not in the middle. 𝕬𝖎𝖉𝖔𝖜𝖑 (hoot!) 00:02, 21 October 2026 (UTC)
I completely agree with this, especially if TWAFI is moved up to its own row. I personally prefer the white background found at User:Aaron Liu/sandbox. With a white or light grey background, TWAFI will still be noticed by new editors, while regular MP viewers will be able to quickly scan down to the colored content that they may be more interested in. --Leviavery (talk) 22:18, 21 October 2026 (UTC)
Placing it higher increases the rate at which it attracts naïve users. You presume that it also increases the rate of disruptive edits, but has anyone from e.g. WP:CVU complained? If it's not requiring excessive (relative to the rate at which it converts readers to editors) counter-vandalism, then top seems best to me. Bernanke's Crossbow (talk) 00:13, 21 October 2026 (UTC)
 Courtesy link: Talk:Confectionery store § Protection where it was decided that the TWAFI should remain unprotected. FaviFake (talk) 00:30, 21 October 2026 (UTC)

CENT on the main page?

Making this a standalone section as it quickly got sidetracked due to more pressing issues: what about putting a beginner-friendly version of our centralized discussion on the Main Page in that blank space?

Besides filling the space, it would help keep casual editors/readers informed of major changes being discussed, and provide input from demographics that wouldn't really have contributed otherwise, but would be just as affected by many of these changes. And, by showing a glimpse into Wikipedia's very community-based decisionmaking to more casual readers, it could help dispel myths or misunderstandings about how Wikipedia as a whole functions, and put some of them on the road to becoming more trustful of Wikipedia, or even to start editing themselves! Chaotic Enby (in solidarity · talk · contribs) 14:47, 21 October 2026 (UTC)

What I'm afraid of is broadcasting our internal strife out to the world via the Main Page. For example, many of the previous few months' discusisons related to the WWU dispute, and while the media did latch on to that, it would have been a much bigger deal if that had been placed on the Main Page, and it would certainly have hurt our reputation. We could simply omit that from the reader-facing version of CENT, but I'd be uneasy about such blatant whitewashing of internal discussions. Chorchapu (talk | edits) 14:57, 21 October 2026 (UTC)
You could add a "Full list..." link though. Also, don't forget about the Dashboard. Hason-LEK-SIN ● 💬 ● 🧱 ● 🧪 00:14, 22 October 2026 (UTC)
There are a lot of things on TCENT that we don't really want or need input from new/non-editors on. Big RfCs restructuring backend processes, RfAs, and almost anything in the meta section ever come to mind. Like right now for example--it would take a solid 10-15 minutes to explain the context behind all three proposals up there, and they're not really ideas that would benefit from this kind of fresh perspective.
But I do really like one of your projected benefits—dispelling the myths about how our decision-making works. And there are decisions where reader opinions really do matter. I think WP:RBV22 is a good case study to look at here. It attracted a dozen or two readers that looked into our discussion processes just enough to stumble on it and complain about it. But that's a completely useless sample, right? What are we supposed to do with the information that twenty people did that? It doesn't tell us how many readers liked it or didn't notice and silently did nothing? Advertising these discussions on the main page could get us a better sample.
There are two problems with this, though. First, there are still sampling bias problems with this, and the WMF is probably better at conducting this kind of research. Second, how often do we have discussions like this? I literally can't think of any between V22 and TWAFI. Perhaps SiteNotices could be a better place for this idea. Snowmanonahoe (talk · contribs · typos) 15:02, 21 October 2026 (UTC)
I would strongly agree with any proposal that would dispel myths or misunderstandings about how Wikipedia as a whole functions, as I remember being utterly fascinated by the first RfCs and AfDs I saw. But CENT sounds like a terrible way to do that.
Maybe the section could rotate between common questions that non-Wikipedians often have, like "Who decides which articles are featured here?", "Does Wikipedia have an editorial team?", "If no one is in charge, how are controversial decisions made?". FaviFake (talk) 16:32, 21 October 2026 (UTC)
That could work too! To clarify, what I had in mind was a more reader-friendly version of CENT, not the whole template. It's unusually empty right now (with only one non-meta discussion), but we quite often have discussions that would stand to involve readers more, even if it's not an immediate, massive interface change.
Take some of this year's big debates. Would readers be comfortable with AI-generated Wikipedia articles? Do casual ITN readers want to see blurbs for recent deaths? Is Birthday Mode a distraction to the average reader, or a fun perk? Or, probably the one that would have benefited from reader participation the most: what to do with the Image Carousel?
A lot of these, as you can see, are about features or policy changes that would directly impact readers, and often are envisioned for them. And yet, that has historically been the hardest demographic to poll, simply because readers won't be likely to stumble their way into our internal processes. We don't need every single CENT discussion up there, but we do want to prominently display those which would matter to many of our readers. Chaotic Enby (in solidarity · talk · contribs) 16:40, 21 October 2026 (UTC)
In fact, I think we could have both: a section with common questions, which readers can learn about, and the end of the section inviting readers to participate in currently debated "questions", if there are any suitable ones.
P.S.: your proposal of rotating through common questions would also be a great motivation to make many of our help and explanatory essay pages more accessible, which is always a win! Chaotic Enby (in solidarity · talk · contribs) 16:43, 21 October 2026 (UTC)
My prediction is that FAQs make the target audience (skeptics) defensive, for lack of a better word. I'd rather not have an FAQ on the main page save for a single link. In solidarity, Aaron Liu (talk) 20:50, 21 October 2026 (UTC)
The flaw in this suggestion is "beginner-friendly version of our centralized discussion", which probably doesn't exist for the reasons Snowmanonahoe covers. The benefits FaviFake mentions are sort of what the "the free encyclopedia that anyone can edit" tagline and links are supposed to do, so the question I'd have for any proposal is what that proposal conveys additionally to that tagline, and whether it would stand out more than the tagline does. I think WMF does poll things like the birthday mode. CMD (talk) 01:16, 22 October 2026 (UTC)

Notes

  1. ↑ and yes, that's a possibility! Seriously, ask your non-Wikipedia friends if they noticed that Wikipedia drastically changed its appearance three years ago, and the vast majority of them will say "no". This was even the case when I asked people two weeks after the rollout.

Watchlist: Titles and button names

On the Watchlist page, it would be nice to improve the button names to better match the content they display once pressed. In addition, page titles can be modified for better consistency. The default watchlist shows the title as "Watchlist" and the button as "View watchlist", while the content shows recent changes in the watchlist, not the watchlist itself. Then, when the "Edit watchlist" button is pressed, the title switches to "Edit watchlist", while the content displays the actual watchlist with the option to edit. Therefore, the following changes are proposed to the titles and button names. With these changes, the position of the word "Watchlist" is kept at the beginning of the title when switching between buttons; it is followed by a colon; and the word "Watchlist" is removed from all buttons. This makes titles and buttons more consistent. Also, the word "raw", which is somewhat vague, is replaced by the phrase "text version" to better reflect the content.

Title "Watchlist" and button "View watchlist" to be changed to "Watchlist" and "Changes", respectively. (i.e., no change to the title for the default case)
Title "Edit watchlist" and button "Edit watchlist" to be changed to "Watchlist: Edit" and "Edit", respectively.
Title "Manage watchlist labels" and button "Manage labels" to be changed to "Watchlist: Labels" and "Labels", respectively.
Title "Edit raw watchlist" and button "Edit raw watchlist" to be changed to "Watchlist: Edit text version" and "Edit text version", respectively.
Title "Clear watchlist" and button "Clear watchlist" to be changed to "Watchlist: Clear" and "Clear", respectively.

The end result at the default case is changed from:
Watchlist
View watchlist; Edit watchlist; Manage labels; Edit raw watchlist; Clear watchlist
to:
Watchlist
Changes; Edit; Labels; Edit text version; Clear

Please share your feedback about this proposal.

Thanks, PrinceTehran (talk) 22:25, 19 October 2026 (UTC)

I don't find the Watchlist: Verb construction more informative. I actually find it more confusing. Schazjmd (talk) 22:39, 19 October 2026 (UTC)
I agree with Schazjmd, I find the current labels clearer than the proposed ones. Thryduulf (talk) 22:43, 19 October 2026 (UTC)
That's a great point by @Schazjmd about the titles. The idea is to fix the position of the page name Watchlist when switching between buttons. Right now it is floating when buttons are pressed. To address your point, we can do this: Watchlist ⇒ Short description. The updated result for five titles would be:
Watchlist
Watchlist ⇒ Edit watchlist (visual version)
Watchlist ⇒ Manage watchlist labels
Watchlist ⇒ Edit watchlist (text version)
Watchlist ⇒ Clear watchlist
The button labels remain the same as originally proposed (i.e., Changes; Edit; Labels; Edit text version; and Clear). Is it better now? PrinceTehran (talk) 03:50, 20 October 2026 (UTC)
I appreciate you taking on the feedback, @PrinceTehran. I had hoped other editors would offer their opinions after your changes before I replied again. To be honest, I don't really see a problem with the current version, and so I don't see any value in these changes. Schazjmd (talk) 20:22, 21 October 2026 (UTC)
I don't think they're 'buttons'. I think they're technically 'tabs'.
They already work the way I expect them to, and I already know what to expect from them. I have to agree with @Schazjmd: I don't really see a problem with the current version, and these changes would not be improvements for me. WhatamIdoing (talk) 03:31, 25 October 2026 (UTC)

First level documentation for "newish" editors

Is there a working group to reduce the learning curve for "newish" editors (say 100+ edits) to which I can contribute?

I've been editing daily for hours for almost a year. Once I went beyond simple tasks (upload an image, create a table, etc.), I faced a VERY steep learning curve to navigate the complex documentation for wiki syntax and policies. And I am still struggling even being a tech person.

The idea in a nutshell would be to extend the minuscule first layer of documentation so that "newish" editors can find what they need, via simpler instructions, better indexing to the more detailed content, etc.

I have checked the tabs and (lightly) checked the archives ("new editors") and found nothing on this topic, except for the mw:Edit check initiative which is focused on improving the Visual Editor.

Regards,
JP Jp1008 (talk) 00:14, 21 October 2026 (UTC)

I think a WikiProject for folks to collaborate on easing the introduction to Wikipedia editing would be fantastic. Pinging Femke, who has done lots of work on this issue :) HouseBlaster (talk • edits • he/they) 00:20, 21 October 2026 (UTC)
Wikipedia:Help Project is a longstanding project. Updating documentation has been challenging over the years: since it's usually easier to reach a compromise agreement that includes more suggestions, help pages tend to expand with many additions. Subsequently, different pages, sections, and paragraphs gain their adherents and it becomes hard to find a way to restructure documentation. But the only way for improvements to happen is for someone to draft a new proposed page for others to discuss, so more power to anyone writing something up. isaacl (talk) 02:04, 21 October 2026 (UTC)
I've watchlistedb the wikiproject, so let's work together there. I'm very keen on making help pages easier to digest and more importantly, make the interface easier to understand. One thing I'll be proposing soonish is to make the 2017 wikitext editor the default source editor, so that people have an easier time learning the source editor if they prefer it over VE. In solidarity, —Femke (talk) 🐦 07:06, 21 October 2026 (UTC)
Isn't that the one that doesn't even have syntax highlighting? FaviFake (talk) 15:59, 21 October 2026 (UTC)
WP:2017 wikitext editor: it's simply the source editor with access to the VE toolbar. That means you can add tables with a few clicks and have the automated citation creator. In solidarity, —Femke (talk) 🐦 17:06, 21 October 2026 (UTC)
I find that to be much less important than syntax highlighting, especially if we want to help editors understand what those curly braces, angle brackets, and weird pipes are. Even I would be lost without it. FaviFake (talk) 18:15, 21 October 2026 (UTC)
I use the 2017 editor and it has syntax highlighting of some form. E.g., equal signs are bigger, things inside ref tags are green, things inside brackets are pink, most text is purple. 1brianm7 (talk) 19:16, 21 October 2026 (UTC)
So the image at mw:2017 wikitext editor is utterly outdated? It sounds like you're using the modern source editor or you have a syntax highlighting gadget enabled. Needless to say, I don't think we should make users enable such gadgets CodeMirror's syntax highlighting is already on by default. FaviFake (talk) 20:15, 21 October 2026 (UTC)
Syntax highlighting is a different setting. On mediawiki for me, syntax highlighting is off for both the old source editor and the 2017 editor. On enwiki, it's on for both. In solidarity, —Femke (talk) 🐦 20:27, 21 October 2026 (UTC)
That image is probably outdated, it's from 2021. I don't think I have modified it extensively. The most recent update on it that I recall is Wikipedia:Village_pump_(technical)/Archive_232#CodeMirror and the 2017 Wikitext Editor. I've been using it for a few months and its pretty great. 1brianm7 (talk) 20:27, 21 October 2026 (UTC)
Then I'm out of the loop, thanks to you both! FaviFake (talk) 20:42, 21 October 2026 (UTC)
FaviFake, here's a screenshot showing both the syntax highlighting turned on in the 2017WTE and where you can find the menu item to enable it.
WhatamIdoing (talk) 03:35, 25 October 2026 (UTC)
Thanks! But wasn't syntax highlighting supposed to be turned on by default on enwiki? FaviFake (talk) 11:10, 25 October 2026 (UTC)
The syntax highlighting is off in the mobile source editor. I think that's what FaviFake is referring to. The 2017 wikitext editor is pure Desktop. In solidarity, —Femke (talk) 🐦 19:19, 21 October 2026 (UTC)
I love this idea! FaviFake (talk) 00:29, 21 October 2026 (UTC)

Draft RfC for ITN reform

See here BilledMammal (talk) 03:25, 21 October 2026 (UTC)

RFCBEFORE on WP:LLMTRANSLATE

Hi, please see WT:AIC#LLM exemption for translation, trying to workshop the options for an RfC on changing or repealing WP:LLMTRANSLATE, all input welcome Kowal2701 (talk, contribs) 18:24, 21 October 2026 (UTC)

WP:RFCBEFORE currently says things like "If an article content question is just between two editors, you can simply ask for a third opinion."
I think that Wikipedia:Requests for comment#Statement should be neutral and brief was the intended target. WhatamIdoing (talk) 03:38, 25 October 2026 (UTC)

Wikipedia:Editing as an ESL or EFL speaker

Hi, I've started sketching out this essay as I see we don't really have any advice pages for ESL/EFL editors, and a large amount of the cases AINB gets are editors using LLMs to compensate for a lack of fluency. Ofc it's a sensitive topic (as any issues to do with competency are), and having something carefully and considerately worded would be so useful. Would be interested in hearing people's thoughts, especially what people have found useful themselves. Thanks Kowal2701 (talk, contribs) 19:33, 23 October 2026 (UTC)

WP:NOLLM already allows for machine assisted translation… although Editors who use such assistance still need to review it to make sure the program is translating accurately. Blueboar (talk) 20:07, 23 October 2026 (UTC)
(WP:LLMT is only for translating from other language Wikipedias, not for translating normal edits) Kowal2701 (talk, contribs) 20:23, 23 October 2026 (UTC)
I was referring to point 1 in WP:NOLLM, which states: “Editors are permitted to use LLMs to suggest corrections to their own writing, and to incorporate them after human review. This is limited to spelling, punctuation, capitalisation, grammar, and other simple mistakes.” Blueboar (talk) 21:34, 23 October 2026 (UTC)
CIR can be a bit scary to mention, but something like "ask more fluent users if you're unsure"? One way or the other, false confidence in one's own competence is a dangerous friend, and I've had more than my fair share of improper Gallicisms when learning English. Chaotic Enby (in solidarity · talk · contribs) 21:06, 23 October 2026 (UTC)
Good idea. I responded at Talk. Mathglot (talk) 21:45, 24 October 2026 (UTC)
I hope my reply isn't so late that nobody will read it. I've seen a few users, after apologising for their English or saying they used AI to fix their grammar, be told that if their English isn't good enough they should try editing their own language's Wikipedia but in all of these cases that I've seen (though I haven't seen that many) their English was perfectly comprehensible. The essay might even be more useful as a reminder to maybe say something like "but your English seems good enough to me" when pointing people to their native Wikipediae.
I don't know what the minimum standard is for English competency is on the 'pedia but I think as long as it's comprehensible native speakers can fix non-native grammar far more quickly than they can plausible, seemingly-sourced hallucinations. As Chaotic Enby said, assessing one's own skill in a language one doesn't speak is unreliable, but I think the essay shouldn't be too discouraging to those who aren't sure if their English is good enough since we could get more constructive editors (and less AI users) and the few who are actually incomprehensible can be easily dealt with. Wicker Mode (talk | contribs) 16:05, 26 October 2026 (UTC)
Totally agree with your first sentence in ¶2. I don't know what the standard is either (and maybe that should be addressed in a guideline) but imho it should be something like, "Any native speaker can understand unambiguously what you meant, so that they can adjust it to a native English standard." A possible problem there, is the number of native English speakers who write ambiguously and might get caught up in the guideline. Otoh, maybe they should be. If worded carefully, a guideline might address English competence while avoiding any mention of native language or second-language speakers, and just apply to everyone equally.
Reminder to self: once the essay is mature, we should consider linking to it from {{Welcome-foreign}}. Mathglot (talk) 17:36, 26 October 2026 (UTC)
Agree with focusing on English competence more, with native/non-native status as a special case. Many non-native English speakers have a native-like fluency in the language, and we wouldn't want to stigmatize them with a blanket assumption that non-native speakers are necessarily less capable. Chaotic Enby (in solidarity · talk · contribs) 18:11, 27 October 2026 (UTC)
Agreed. A fluent English speaker engaging in a topic with unfamiliar jargon could run into the same sorts of LLM-fluency challenges. Not sure how to word that off the topic of my head though. CMD (talk) 22:48, 27 October 2026 (UTC)

The 2017 wikitext editor as default source editor?

When you look at recent changes, about half of newer Desktop editors still use source editor . If you look at a language that has had VE as a default for longer , the percentage is only slightly higher. I don't quite understand why this is (maybe someone in @PPelberg (WMF)'s team can shed light, maybe the tags don't fully capture everything).

One way to make life easier for editors using source editor, is to enable the WP:2017 wikitext editor as the default source editor, which shows the VE toolbar on top of the source editor. The biggest advantage is that adding sources and reusing sources is much much easier. In the 2010 editor, there is a small 'cite button', which requires editors to know to click 'templates' next, and then select the right templates, before being overwhelmed with options. In the VE toolbar, it's often as simple as copying the url in the toolbar. The biggest disadvantage is speed, even though I'm not experiencing any trouble editing big pages with it.

In reviewing G15s, I often come across editors that make a claim they're just using AI for formatting reasons only. Not sure what share of these claims is true. To prevent the need for formatting help, we should make editing easier (the carrot). On the 'stick' side of things, the editing team believes it's possible to implement paste check in the 2017 source editor (see related wish). That likely is only worth their time if we are willing to make the 2017 editor the source default in some way.

I'm considering opening an RfC with four options:

  1. Keep the 2010 wikitext editor (current default)
  2. Make the 2017 wikitext editor the default source editor for non-EC editors editors who are not extended confirmed at the moment of the switch
  3. Make the 2017 wikitext editor the default for all editors
  4. Make the 2017 wikitext editor the default for non-EC editors conditional on Paste Check being developed.

There's other options, like making it the default only for new editors, but since it's a smaller change in interface and I'd like to capture a bigger group with easier editor, my intuition is to make the RfC a bit bolder. Keen to hear opinions. In solidarity, —Femke (talk) 🐦 08:45, 24 October 2026 (UTC)

I used to use the Wikitext 2017 editor but I found it made it impossible to edit on any mobile device on the desktop view. It would do this weird thing where it would offset all text selection like 4 paragraphs after where the text actually was. PARAKANYAA (talk) 19:57, 24 October 2026 (UTC)
That is really annoying. Did you open a bug report on phab? Do you know if that bug is still there? In solidarity, —Femke (talk) 🐦 20:06, 24 October 2026 (UTC)
No, though maybe I should have. I think it was probably a byproduct of how slow it was overall. PARAKANYAA (talk) 15:46, 25 October 2026 (UTC)
On the question of stats:
WhatamIdoing (talk) 03:51, 25 October 2026 (UTC)
I wasn't sure whether I was using the 2017 editor already and had to review my preferences to figure it out (I wasn't). I've turned it on now and will see how it goes for a bit.
What I recommend is that the text editors identify themselves when you're using them so that users can understand the alternatives better. Currently, I'm aware of at least four different editors now.
1. The current default text editor which seems to be a 2010 version
2. The 2017 text editor, as proposed, which has some relation to the Visual Editor
3. The Visual Editor proper
4. The editor which is invoked when you use the reply function (which is what I'm currently using).
I wouldn't be surprised if there are other editors out there too. Ideally these alternatives should be rationalised and simplified but, in the meantime, we need help in understanding which one(s) we're using.
Andrew🐉(talk) 18:46, 25 October 2026 (UTC)
All the editors are listed with a brief description at mw:Editor, there are currently 16 current editors although some are very specialised (e.g ContentTranslatoin), some are mobile only (e.g. iOS app), and not all are available at en.wp (e.g. Wikivoyage Listing Editor). Thryduulf (talk) 19:03, 25 October 2026 (UTC)
Thanks. My count of that table is 17 plus 2 deprecated editors. See feature creep and the KISS principle... Andrew🐉(talk) 19:34, 25 October 2026 (UTC)
The basic distinction is that the 2017 editor is editing wikitext but using the VE toolbar. Sdkb talk 21:06, 26 October 2026 (UTC)
One problem with the 2017 editor is that it breaks with any edit window that prefills something. For some of those, such as requesting at WP:PERM, it only makes it impossible to add an edit summary, while in other places, such at at WP:AINB, it is not really possible to file a report. 1brianm7 (talk) 19:06, 26 October 2026 (UTC)

Uk politics as CTOP?

Iirc there is a community procedure to declare certain topic areas as CTOPs. In many cases, having a topic as CTOP can help with filing AE reports, and reminding folks to be wxtra careful, even without additional remedies applied to the topic area. Unfortunately, i feel its time to designate contemporary UK politics as CTOP; its not adequately covered by current restrictions, and is so contentious in many articles as to confuse many editors that it isnt already a CTOP.

Wrt this, i want to gauge community interest in pursuing this and how to specify contemporary Uk politics? User:Bluethricecreamman (Talk·Contribs) 03:22, 25 October 2026 (UTC)

Can you name several problematic articles that aren't already covered by existing CTOPs? WhatamIdoing (talk) 06:58, 25 October 2026 (UTC)
recently, off the top of my head, Reform UK, Restore Britain, Reform UK financial allegations, 2024 United Kingdom riots, Two-tier policing all have long-standing conflicts around either labeling these parties as far-right, or somehow painting many of these more nicely. Longer-term issues in the past have included Brexit articles, ofc.
A good example of need for CTOP could also be the discussion around Talk:2026 Clacton by-election/Archive 1#The Racial Demographics Are Not Relevant, where it seems to have devolved into allegations of race-baiting, etc. This was a Nigel Farage election.
In many cases, some of these have attracted off-wiki attention and canvassing , as the attempts to remove the word "far-right" in Reform UK bio have continued from many SPAs.
I think even the articles covered by some of the existing CTOPs are only done a bit haphazardly and inelegantly. The Grooming gangs scandal was only recently found to be covered by the Race and Intelligence Wikipedia:Arbitration/Requests/Clarification and Amendment/Archive 132#Clarification request: Race and intelligence, and I think it's not immediately clear to me that other scandals under this umbrella such as the Rochdale child sex abuse ring necessarily are obviously covered by R/I (though I think one user has placed the CTOP label on it here )
(as i've mentioned those articles, would it be worth alerting talk pages of such articles that im spitballing this idea with yall, btw?) User:Bluethricecreamman (Talk·Contribs) 15:43, 25 October 2026 (UTC)
I'd argue that the issue is less "British politics broadly construed" and more "far-right politics broadly construed" since that's also been a noticeable issue in the AP topic area since forever. —Jéské Couriano v^_^v Thriller Night! 16:17, 25 October 2026 (UTC)
Far-right is a nebulous definition enough that its the exact subject of these debates. Actually, more broadly, there are constant arguments about what is far-right, far-left, and if wikipedia can use such labels anyways. User:Bluethricecreamman (Talk·Contribs) 16:25, 25 October 2026 (UTC)
Obviously more precise wording would be required if far right politics were to be designated a contentious topic, one possibility would be "people, organisations (including political parties and campaign groups) and policies who/that have been described as "far right" in at least one reliable source, broadly interpreted" (although that could likely be improved). This would include people/organisations where consensus is that we should not describe them as "far right" in the article, but that is intentional so as to cover debates about whether they are or are not far right.
Note that I'm explicitly not supporting (or opposing) a CTOP with this comment, just pointing out that one would be possible. Thryduulf (talk) 17:05, 25 October 2026 (UTC)
The only Arbitrations I can think of that are focused on British politics are WP:Requests for arbitration/Robert I (centred around a COI editor working for Gregory Lauder-Frost) and WP:Arbitration/Requests/Case/BLP issues on British politics articles (which was more about User:Philip Cross importing off-wiki disputes with British political figures onto Wikipedia). There's been minimal Arbitration history in the topic area. —Jéské Couriano v^_^v Thriller Night! 07:47, 25 October 2026 (UTC)
There was also Wikipedia:Arbitration/Requests/Case/Sockpuppet investigation block but that was also mostly about the actions of a single editor than UK politics as a topic area.
@Bluethricecreamman can you provide some examples of articles that are contentious, are being disrupted and where the available processes are not stemming that disruption? Thryduulf (talk) 11:02, 25 October 2026 (UTC)
My original impetus for this, I filed an AE report covered by R/I, but thought the pattern of behavior could reflect more broadly UK politics. one admin suggests that if behavior doesn't stop there may be need for a hand crafted solution. Another here [2] points out that an originally proposed eventual restriction around AP2 probably is incorrect.
I think many of the articles i placed above Wikipedia:Village pump (idea lab)#c-Bluethricecreamman-20261025154300-WhatamIdoing-20261025065800 in this reply to WAID have a controversial article talk page banner but aren't necessarily linked any other way.
My understanding for the designation of a ctop is not necessarily that there needs to be additional remedies, only that being able to group this together makes it easier to file AE reports, or to direct users to be additionally careful in the topic area. User:Bluethricecreamman (Talk·Contribs) 15:53, 25 October 2026 (UTC)
Designating a topic as falling within the contentious topic framework allows admins to enact more types of restrictions on their own initiative, without requiring community consensus. These restrictions cannot be reversed by another individual admin for the first year. This slows down quick enact restriction/remove restriction cycles, since a consensus of admins or the community will have to be established to change the restriction. The use of the arbitration enforcement noticeboard to discuss these restrictions or request that a restriction be enacted is just a consequence of this. As for asking users to be careful, anyone can do that with any topic. Editors should be following the same community norms with any page; there's just a risk with contentious topics that an individual admin/consensus of admins may enact a restriction that would ordinarily take a community discussion to be enacted. isaacl (talk) 17:19, 25 October 2026 (UTC)
Its not immediately clear to me that quick enact/remove restrictions occur in this area anyways? And in many cases, posting on AN/I becomes a pile-on of various actors, compared to the well-structured aspect of AE. Agree there is that risk ofc of bureaucracy blocking admin actions. User:Bluethricecreamman (Talk·Contribs) 17:33, 25 October 2026 (UTC)
If restrictions are getting enacted without being reversed, then that is a factor against designating the topic as a contentious topic, since restrictions are holding. If the community is unable to agree upon enacting restrictions, then yes, it could delegate some responsibility to admins through a contentious topic designation. Just noting within the current framework, using the arbitration enforcement noticeboard isn't something that happens on its own; it's a direct consequence of delegating responsibility. isaacl (talk) 17:59, 25 October 2026 (UTC)
So I want to concur in part and disagree in part with what @Jéské Couriano said about how the issue is the far right topic in general.
I agree that is a more correct aproach as it captures a general core issue, but I would go further. While far right is contentious, so are political position questions in general. I don't think it will serve the interests of Wikipedia that political classification discussions towards one direction are allowed to have a lower participation treshold than the other. I think that risks cementing existing bias among editors by favouring experienced editors in politics topics in an uneven manner. So in what I disagree is leaving it just at far right. I don't think I would support doing just that. Finfixer (talk) 17:11, 25 October 2026 (UTC)

WP:BLPCRIME caution template?

I don't usually create templates, so I'm not sure if this is a good place to have this discussion, but I've been considering creating a caution template to use on the talk pages of users who appear to have introduced content to articles that may violate WP:BLPCRIME, ie. the full names names of low-profile living individuals suspected or accused of committing a crime but who have not been convicted. Articles covering recent events are frequently inundated by the addition of information provided in preliminary reports on crime suspects, but there is no warning template for use in this situation, and I think there ought to be. Based on Template:Uw-biog-not (which serves a similar but less specific purpose), I've come up with the following text:

I have reverted your edit at [article] as it appears to include material which suggests a living person has committed a crime, in violation of Wikipedia's policy on living persons. Caution must be exercised when considering the publication of the names of low profile individuals accused or suspected of crimes. Living persons accused of crimes are presumed innocent until convicted by a court of law, and the names of individuals identified as persons of interest in a crime should not be included in articles. Please note that accusations, investigations, arrests and charges do not amount to a conviction and care should be taken to avoid the publication of potentially libelous material.
Criminal allegations and the names of suspects, even if referenced, should be added only if noteworthy, relevant, and documented in multiple high quality reliable independent sources. Wikipedia is not a newspaper and material should not be added if it is only gossip, or if the only sourcing is tabloid journalism.
If challenged, the onus is on the editor who adds the content to justify its retention. Thank you.

I would appreciate honest feedback on both the wording and the idea of the template itself as this is not my usual area at all. Cheers, Ethmostigmus 🌿 (talk | contribs) 08:42, 25 October 2026 (UTC)

I like this idea. I would suggest making the explanation much simpler, because people will gloss over anything that's more than a few sentences. Thebiguglyalien (talk) 02:16, 26 October 2026 (UTC)
I like this idea too. I agree with User:Thebiguglyalien above, the explanation should be concise. I had a go making it slightly less wordy:
I have reverted your edit at [article] as it appears to violate Wikipedia's policy on living persons accused of crimes. People are presumed innocent until convicted by a court of law, and the names of low profile individuals identified as persons of interest in crimes should not be published. Accusations, investigations, arrests and charges do not amount to conviction. Criminal allegations (even if referenced) should only be added if they are noteworthy, relevant and documented in multiple reliable independent sources. Wikipedia is not a newspaper and care should be taken to avoid libel. If you disagree, the onus is on you to justify retaining this content. Thank you.
Could probably be simplified further, but let me know what you think. 𝕬𝖎𝖉𝖔𝖜𝖑 (hoot!) 03:20, 26 October 2026 (UTC)
Ha, yes, being overly wordy is a personal fault that I am well aware of - I think this shorter version looks great! Ethmostigmus 🌿 (talk | contribs) 06:48, 26 October 2026 (UTC)
I'd personally axe mentions of 'libel' for being more confusing than clarifying; the definition of libel or defamation has a real world meaning, but our Wiki-dialect's definition doesn't map neatly onto the real-world USA definition of libel. We welcome facts which would be considered libel in some countries and, conversely, I've seen us revdel comments under the BLP policy which would not be considered defamatory under US law. GreenLipstickLesbian💌🧸 08:15, 26 October 2026 (UTC)
This is better. I'd remove Wikipedia is not a newspaper and care should be taken to avoid libel. If you disagree, the onus is on you to justify retaining this content. and (even if referenced), the latter is redundant and reads awkwardly. Per GLL and because the last line is inviting a discussion in the wrong place. A discussion to include contested BLP content needs to occur on the relevant talk page, not a usertalk page. Or otherwise better worded as such. Also would be worth revisiting the wording of Template:BLPCRIME editnotice and Template:BLPCRIME talk notice while we're here, the focus appears a bit outdated. CNCin solidarity (talk) 08:53, 26 October 2026 (UTC)
Thanks all, these are all good points. What do we think of:
I have reverted your edit at [article] as it appears to violate Wikipedia's policy on living persons accused of crimes. People are presumed innocent until convicted by a court of law, and the names of low profile individuals identified as persons of interest in crimes should not be published. Accusations, investigations, arrests and charges do not amount to conviction. Criminal allegations should only be added if they are noteworthy, relevant and documented in multiple reliable independent sources. If you would like to discuss this matter further, you may open a discussion at the relevant article talk page. Thank you.
Ethmostigmus 🌿 (talk | contribs) 01:34, 28 October 2026 (UTC)

A “where am I?” map for readers: showing how an article fits into its subject

Notice: This proposal is believed to have been generated with the use/assistance of an LLM. The author is encouraged to rephrase it in their own words (after which point this notice can be removed), but it has been uncollapsed to allow discussion to continue unhindered. CSGinger14 (talk) 22:14, 26 October 2026 (UTC)

Hi all, I’m a long-time reader and new to posting, so apologies if this has been discussed before. Links to past discussions would be very welcome.

The problem. Most readers arrive at an article from a search engine, in the middle of a subject. The article is usually excellent, but nothing on the page tells them:

Wikipedia already holds most of the information needed to answer those questions. It just isn’t visible at the point of reading.

What already exists. I’m aware of several pieces that point this way:

As far as I can tell, none of these is connected to the article a reader is actually looking at.

The idea. An optional, collapsible panel on each article, showing:

  1. Broader: the parent topics, taken from the Outline pages and Vital Articles level
  2. Foundations: a few “read this first” articles
  3. Deeper: narrower or more specialised articles

Items 1 and 3 could mostly be generated from existing structure. Item 2 is the new part. It would need some kind of lightweight “prerequisite” link that editors can add, possibly stored in Wikidata.

Why it matters. It would turn Wikipedia from something you look things up in into something you can also learn a subject through, from the ground up, without changing a word of any article.

Questions for the community:

Thanks for reading. I’m happy to help build a prototype if there’s interest.

Grant from RepHleX

PS Primary affected users:

Readers, especially students and self-learners who arrive on an article from a search engine in the middle of a subject. Nothing on the page tells them how central the topic is, what they need to understand first, or where to go next for more depth, so many either bounce off articles that assume background knowledge or never find the foundational ones. Secondary: editors in WikiProjects, who would add and maintain the “read this first” links for their subject area, building on the Vital Articles levels and Outline pages they already curate.

~2026-57277-75 (talk) 08:20, 26 October 2026 (UTC)

Whether or not the idea was written with the assistance of a large language model (it doesn't come across that way to me, but I could be wrong), it seems reasonably concise, states a clear problem and proposal for addressing it, and to me feels like some consideration has gone into the words, in contrast to the vapidness that some generated text has. Thus I don't agree with collapsing the text (and, as at the moment it's just an idea raised for discussion, building consensus is not yet a consideration). isaacl (talk) 21:58, 26 October 2026 (UTC)
I agree. There are far worse things that LLMs are used for here, and I frankly think that, more than anything else, this just builds resentment among newbies who were otherwise making a good faith effort to communicate something that they may not have been able to easily put into words. If they can, I might encourage the original author to rephrase their original proposal, but I think that if the intention is to ultimately make a useful proposition to the community (that isn't immediately veiled in controversy) then there's little conceivable harm. Just don't use it for your next response.
No one cares about how eloquent you sound. Frankly my experience is that being overly articulate over the course of a long discussion can tire some community members out. I promise we're not grossly judgmental, and those that are usually aren't all that articulate anyway, so they've got little room to talk.
CSGinger14 (talk) 22:09, 26 October 2026 (UTC)
To me, it doesn't sound overly eloquent. And I don't think we should set expectations that we prefer to engage with editors that are less articulate. isaacl (talk) 22:28, 26 October 2026 (UTC)
That's exactly my point, but from what I can tell a lot of the time people use AI as a substitute or complement to their own personal prose because they lack confidence in their writing abilities, and fear the consequence for their ultimate goals. Eloquence is extremely subjective, and oftentimes what you consider to be a standard composition is high-flung and nigh unintelligible to someone else, particularly if they're coming in as a non-native speaker of the language of reference.
CSGinger14 (talk) 22:34, 26 October 2026 (UTC)
My point is that personally I don't feel that the initial post reaches a level of eloquence on any reasonable scale such that someone should use it as a reason to ask the original poster not to use an LLM "for your next response". isaacl (talk) 01:50, 28 October 2026 (UTC)
@Isaacl That response had much less to do with any personal problem I had with the quality of their writing than the fact our site doesn't allow for the use of AI to generate text.
Best,
CSGinger14 (talk) 07:27, 28 October 2026 (UTC)
I think it would be interesting to see a proof-of-concept/mock-up for an article (or small set of related articles). Schazjmd (talk) 22:30, 26 October 2026 (UTC)
I second this. This is actually something I've thought would be useful for a long time, glad that someone finally put forth the effort to flesh out a proposal.
CSGinger14 (talk) 22:35, 26 October 2026 (UTC)
Parent and child topics are usually shown as wikilinks within an article. These may be structured in templated panels such as infoboxes and navigation templates. See 2026 Iran War, for example, which has numerous links to related topics.
There are also categories which have a tree structure but they are buried at the bottom of an article page and not so easy to navigate.
Andrew🐉(talk) 22:37, 26 October 2026 (UTC)
@~2026-57277-75, Wikipedia has struggled with this for a long time. In the technical area we have Wikipedia:Make technical articles understandable which is quite similar to what you are saying. In its section on writing the article lead it says, among other things, the lead of the article should tell a general reader the field of study of the topic, the place the topic holds in its field of study, what (if anything) the topic is good for, and what needs to be learned first in order to understand the article.
However articles are written by volunteers, and implementing this has always been an issue. I think an approach such as you suggest might be helpful. However, while we have articles that might be considered "Foundations" we have few editors capable of writing ones which are really introductory, and the ones that exist often get don't remain that way as other things get added. Referring a reader of a hard to understand article to parent or foundation articles that are equally difficult may not help. StarryGrandma (talk) 22:41, 26 October 2026 (UTC)
Regardless of the question of LLM use to compose this post, this does sound like an interesting idea to explore. One reason why, at the beginning of Wikipedia, subpages weren't enabled in articles was specifically that one article can have several parents (for example, History of France could be a child topic of both History of Europe and France). Having a way to show all of them prominently for navigation could be helpful, especially if it can be managed without having to overload the top hatnotes. My only worry is for articles with many, many child topics – e.g. Donald Trump or Aedes (with nearly a thousand species!) – in these case, showing all child topics would be quite unwieldy for the average reader, and the current approach with wikilinks and navboxes would be preferable.
I'm less convinced about the "Vital Articles" level as a helpful tool for the average reader. This system has already been criticized as pretty arbitrary by the community, especially at levels 4 and 5. A "read this first" panel could be more helpful, and build upon the aforementioned technical article lead guideline in a more structured way. Chaotic Enby (in solidarity · talk · contribs) 04:21, 28 October 2026 (UTC)
NB: this has also been added to the community wishlist as meta:Community Wishlist/W604. —ClaudineChionh (she/her · talk · email) 23:51, 28 October 2026 (UTC)

Today's unusual article

I feel like it would be cool to add a today's unusual article to the main page. Timmy8426 (talk) 23:59, 27 October 2026 (UTC)

WP:DYK is supposed to be for interesting new content. Perhaps most are not unusual or interesting though! On April Fools Day you can expect unusual DYK content on the main page. Graeme Bartlett (talk) 00:22, 28 October 2026 (UTC)
Fair point, but it could still be a decent idea. Timmy8426 (talk) 00:39, 28 October 2026 (UTC)
Do you mean something like Depths of Wikipedia? I follow it on Bluesky, but I'm not so sure it should be on the main page. Donald Albury 15:28, 28 October 2026 (UTC)
Never heard of it. Timmy8426 (talk) 21:12, 28 October 2026 (UTC)

internet video infobox

Village pump
The full video
Release
PlatformYouTube
Uploaded
  • April 23, 2005 (2005-04-23)
8:31 p.m. PDT
Metadata
Duration0:19
Channeljawed
Linkhttps://www.youtube.com/watch?v=jNQXAC9IVRw
Quality240p
Production
FeaturingJawed Karim
Filmed atSan Diego Zoo
Filmed byYakov Lapitsky

Hey, I’m trying to develop an infobox and I would like some feedback. So, I’ve noticed that Wikipedia has a lack of Infoboxes for internet content. Most articles about internet videos either use the film infobox or one of the television infoboxes. Below, I have an outline for an internet video infobox. I even have a link so you can preview it in your sandbox and try it yourself.

image= Pretty obvious, works the same as every other infobox.
caption= Also self-explanatory, caption for the image.
alt-title= If the video goes by another name.
platform(1-3)= The site that the video was originally uploaded on. Multiplied in case the original uploader put it on other sites.
upload_date(1-3)= The date the video was uploaded. Multiplied alongside the platform. If it’s a live stream use stream_date= instead.
stream_date= The date the video was livestreamed. If it isn’t a live stream, use upload_date= instead.
time= The amount of time the video runs for.
chan= The name of the channel the video was uploaded to.
url= The URL to the video.
quality= The quality of the video (measured by p)
feat= People in the video.
place= The location the video was filmed at.
camman= The person recording the video.

Page for the code
An example of the infobox using me at the zoo.

Thanks for your time. If this infobox goes over well, I’d also like to make some for webseries and webseries episodes.
Iconoclasty (talk) 02:00, 28 October 2026 (UTC)

Looks great! Not sure if it's necessary to show the full URL by default. URLs can get very long. Nitpicks about parameter names: time= should be duration=. chan= is overvaluing concision, just use channel=. camman= is sexist, use cam_operator= or videographer= something else if you have a better idea. Joe vom Titan (talk) 01:06, 29 October 2026 (UTC)
updated
chan > channel
time > duration
camman > camera_op Iconoclasty (talk) 01:14, 29 October 2026 (UTC)
Actually, it would be even better to use the same parameter names as in the film infobox where that makes sense. Joe vom Titan (talk) 01:15, 29 October 2026 (UTC)

Spoiler filters

I have an idea. When reading an article about a piece of media that contains spoilers it blurs it, you then click on show spoiler. This might be nice as an optional feature that’s off by default Kerman64 (talk) 05:40, 28 October 2026 (UTC)

Since a WP-article about a piece of fiction is supposed to contain something about the plot, that would be pretty much all articles about works of fiction, fictional characters etc. WP:SPOILER may be of interest. Gråbergs Gråa Sång (talk) 08:57, 28 October 2026 (UTC)