Jump to content

Wikipedia:Village pump (idea lab)/Archive 67

Add links
From Wikipedia, the free encyclopedia
Village pump (idea lab) archive  

This page contains discussions that have been archived from Village pump (idea lab). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67

SERP-like article previews on category pages

Apologies if this has been suggested a zillion times before -- a preliminary search turned up no prior discussions.

Browsing through articles (or other pages) in categories currently can be challenging, as all you get is the title of each page. You can use the preview popup to get a quick look at each article, but the popup interferes with mousing over (and thus previewing) other titles in the listing and it takes several seconds to vanish when you mouse off -- which makes for extremely extremely slow, frustrating going.

In search results, by contrast, you get the full title and preview of each article right there on the page, by default. It's really easy to skim the results all at once to find what you are and are not interested in.

Other than "it hasn't been thought of" or "it hasn't been a priority to implement", is there any particular reason we don't display article/page listings in categories the same way we display them in search results? -- Avocado (talk) 19:46, 3 June 2025 (UTC)

I can't answer the questions, but I wanted to offer moral support for the idea. I find category pages unbearable for the reasons that you describe. Schazjmd (talk) 20:04, 3 June 2025 (UTC)
There are times I'm browsing categories where this would be extremely helpful, equally there are times this would absolutely get in the way, so ideally there should be some way to toggle the display on and off for the current page. I don't immediately have a preference for what the default should be or how sticky the toggle should be. Thryduulf (talk) 21:09, 3 June 2025 (UTC)
Pinging @Trizek (WMF), who may want to pass this idea/question to the Web team. WhatamIdoing (talk) 02:32, 4 June 2025 (UTC)
It looks like a good idea to submit as a community wish. Trizek_(WMF) (talk) 17:35, 4 June 2025 (UTC)
I'd imagine that serving up that information might be a bit of work, server-side. I also wouldn't categorically assume that people currently using categories have the same need for snippets as people currently using the search function. Jo-Jo Eumerus (talk) 08:41, 4 June 2025 (UTC)

Newspapers and Wartime

Initial post

Orignially from this RSN thread and moved here.

I raised that we have a bit of a problem with regard to the use of news sources from countries actively involved in ongoing military conflicts. Referencing William Randolph Hearst I noted that the use of newsmedia for wartime propaganda was a long-standing and pervasive problem that affects reliability both directly (through it being potentially unreliable) and indirectly (because it's hard to trust the reliability of media involved in a conflict because of the well-known and wide-spread use of it for wartime propaganda).

I suggested there are three approaches to handling this problem:

  1. We could decide that we are going to ignore this as being bias and only act when third party sources make it clear that bias has become outright disinformation. This is where we are right now and it's frankly not working. Our various CTOPS related to protracted inter-state conflict indicates that clearly.
  2. We could decide that we should only use news sources from states that are not a party to an armed conflict. While this would allow for the timely use of dispassionate sources it's going to descend into a morass of arguing over which states are party to a given conflict. We've already seen a bit of that with arguments that Al Jazeera is not reliable because of the differential relationship enjoyed between Qatar and Pakistan vs between Qatar and India. Returning to Ukraine we could then ask the question: Is the United States a party to that conflict? Is England? Is China?
  3. We could decide we shouldn't be using news sources at all for wars. I prefer this one because it will reduce the ability to use ambiguities to POV push. Is it a news source? Don't use it for war.

Clearly my suggestion is that we just not use newsmedia sources to discuss wars. It regularly inflames WP:CTOPS and is contrary to WP:NOTNEWS and WP:NODEADLINE. It would be better to wait for the historians even if they take their time. However what I would say is that how we currently handle the question of reliability of sources during active and protracted military conflicts is broken.

I want to note that I am talking about this at the level of active military conflict - not to single out any given active military conflict.

Pinging participants from the RS/N thread: @Orientls @Wareon @CapnJackSp @Kautilya3 @ActivelyDisinterested @Chatul @Abecedare @Black Kite @DataCrusade1999 @Gotitbro @Shankargb @SheriffIsInTown @Slatersteven @The_Bushranger @Phil Bridger Please accept my apologies if I missed anyone. I tried to get every editor who participated in the entire thread. Simonm223 (talk) 19:00, 29 May 2025 (UTC)

Section break 1

Section break 2

  • In my experience, an article based mainly on newspaper coverage is almost always going to be low-quality regurgitation as opposed to the summary of academic literature we should be working toward. The problem is common enough that I wrote an essay a while ago on this topic at User:Thebiguglyalien/Avoid contemporary sources. It's inevitable that these sources be used to verify facts that are both recent and critical, but beyond that they're a great way of including undue info. I don't believe these POV problems are deliberate in most cases (though it might be in wartime subjects, hence this discussion), but as I explain in that essay, it's pretty much guaranteed when you're using this type of sourcing. Thebiguglyalien (talk) 🛸 04:30, 30 May 2025 (UTC)
  • Asa I recall wp:primary does include newspapers too close to an event. Slatersteven (talk) 10:42, 30 May 2025 (UTC)
  • In my experience, when people start arguing over whether sources are "primary" or "secondary" and they're not talking about WP:GNG or certain parts of WP:BLP, they're usually actually arguing over WP:Primary does not mean bad, WP:Secondary does not mean good, WP:Secondary does not mean independent, WP:Recentism, and so on. What matters in these cases is whether the source is reliable (for the context) and not invalidated by new knowledge, that we're not adding interpretation or analysis not present in the sources, and that we're not giving some part of the topic undue weight, and so on. Whether the sources used are "primary" or "secondary" doesn't actually matter for any of that. But people argue about that anyway because it's easier to exclude content they don't like by labelling it "primary", to the point where they've gotten "primary vs secondary" shoved into various policies and guidelines where it doesn't really belong and created idiosyncratic definitions of "primary" and "secondary". Anomie⚔ 11:51, 30 May 2025 (UTC)
    @Anomie, Agree agreed, well said. Sm8900 (talk) 13:35, 30 May 2025 (UTC)
    I also agree with Anomie. On more than one occasion I've had to rigorously defend the use of a primary source for basic factual information when the organisation responsible was the only possible reliable source for that information. For example a transit system operator is the only source that can reliably know how many passengers used that transit system - secondary sources exist but they just quote the operators figures but with the possibility of things like transcription errors. For many of the topics we cover, there simply isn't extensive "academic" literature to summarise - sometimes the topic is too new (pretty much everything related to Donald Trumps second presidency for example), sometimes it hasn't been the subject of significant "academic" study (e.g. most TV programmes, lots of pseudoscientific theories), sometimes the research is done to academic standards but simply not published in formal journals (e.g. excavations by local archaeological societies, oral histories), etc. It is not possible to meaningfully apply the standards and conventions of topics like contemporary mainstream medicine and 20th century western literature to everything. Reliable sources should always be used, and secondary ones where appropriate, but "academic literature" is only a very small subset of reliable secondary sources, let alone of all reliable sources. 14:06, 30 May 2025 (UTC) Thryduulf (talk) 14:06, 30 May 2025 (UTC)
    The academy has actually been working overtime churning out articles about Donald Trump's second presidency. Wikipedia is not a breaking news source; I think we could probably cool down a lot of internal conflicts if we heavily pumped the breaks on articles about in-progress military conflicts. These almost always seem to end up with WP:CTOP designations and big messy fights that sprawl out to every noticeboard. It would be better for us to produce these articles slower. Simonm223 (talk) 14:14, 30 May 2025 (UTC)
    @Thryduulf,. Agree, yes well said. Sm8900 (talk) 15:40, 30 May 2025 (UTC)
    Secondary sources are the arbiters of inclusion and due weight. An editor who does not distinguish between primary and secondary sources when writing content will ultimately be incapable of complying with large portions of NPOV. Thebiguglyalien (talk) 🛸 17:41, 30 May 2025 (UTC)
    That's clearly how you'd like it to be, but I see no mention of "primary" or "secondary" in the section Wikipedia:Neutral point of view#Due and undue weight that defines "due weight". The NPOV page as a whole only mentions them twice in passing, once in a section about contradictory sources (recommending sources that describe the disagreement from a disinterested viewpoint and making the assumption that any exist) and once in discussing sources about religions. Anomie⚔ 22:19, 30 May 2025 (UTC)
    I've explained why it's an issue at User:Thebiguglyalien/Avoid contemporary sources so I don't have to write the same paragraphs-long explanation every time this comes up. Thebiguglyalien (talk) 🛸 22:37, 30 May 2025 (UTC)
    Which itself barely mentions "primary" and "secondary" either. Your claiming here that people need to distinguish between primary and secondary sources seems to prove my point that such arguments are usually cover for something else. Anomie⚔ 23:04, 30 May 2025 (UTC)
    Contemporary and primary are synonymous as I use them. You can't just do Control+F and expect to glean meaning. Thebiguglyalien (talk) 🛸 23:09, 30 May 2025 (UTC)
    "Contemporary" and "primary" are very much not synonymous in the way everybody else uses them - and for good reason, the temporaral distance between event and source, and degree of separation between event and source are completely independent factors. Thryduulf (talk) 01:21, 31 May 2025 (UTC)
    Contemporary sources, or real-time sources, include all sources about an event that are produced as new information comes out. They most commonly take the form of news reports, and they are contrasted with retrospective sources, which analyze an event from a historical perspective. Contemporary sources are rarely ideal, and they should be avoided when possible.
    Contemporary sources and real-time coverage of an event provide the facts of an event, but they do not place it in context or determine its broader significance. News coverage and other contemporary sources are often routine, and even exceptional coverage doesn't necessarily indicate that the event should be mentioned in an article. An event that seems significant at the time can end up being insignificant in the overall scope of the article. Since it is difficult to measure significance and due weight using contemporary sources, using them to write content causes editors to make their own conclusions about significance and give the content disproportionate weight.
    Instead, articles should use retrospective sources that were written later, such as books about the subject, journal articles that analyze it, or newspaper and magazine articles that provide a long-form retrospective analysis of the subject. Tertiary sources such as encyclopedias are also useful for determining how much weight to give individual events as part of a broader article. Real-time sources about an event are primary sources for the event itself. They can be primary sources or secondary sources for people and places mentioned in the source, depending on how the source is used. Use of primary sources should follow the Wikipedia guideline on using primary sources.
    The key is not to wait a certain number of months or years, but to compare contemporary and retrospective sources. Contemporary sources can still be written well after an event initially began or took place. If a crime is committed, real-time sources about the trial are still contemporary, even if the trial goes on for years. Likewise, if a disaster occurs, sources about the resulting investigation are still real-time sources because they entail publication of new information as it develops. Thebiguglyalien (talk) 🛸 01:30, 31 May 2025 (UTC)
  • Some data from a party to a conflict for 2024 for interest, from Israel's military censor in response to a joint request from +972 Magazine and the Movement for the Freedom of Information in Israel. 1,635 articles banned, 6265 partially redacted. From this report. Sean.hoyland (talk) 14:35, 30 May 2025 (UTC)
I don't understand why we have to litigate this everytime an article related to India gets popluar, wikipedia has enough safeguards already in place editors should use sources that are in WP:RSP for these topics and if they(editors) want to use a source that's not in WP:RSP then they could discuss first on the talk page and then use that source.

Referencing William Randolph Hearst I noted that the use of newsmedia for wartime propaganda was a long-standing and pervasive problem that affects reliability both directly (through it being potentially unreliable) and indirectly (because it's hard to trust the reliability of media involved in a conflict because of the well-known and wide-spread use of it for wartime propaganda).
— User:Simonm223

I agree with this wholeheartdly, But the only problem I have is that why this discussion didn't take place earlier. did we discuss this issue when Iraq war was happening? I can't help but feel that there's a different standard beign applied to other countries but still I'll support whatever consensus this discussion leads to as long as it's sitewide and doesn't put sources of some countries on a higher pedestal than that of other countries.
On Newspapers I would like to say that I use Newspapers for highly localized coverage that they offer. India for example has many newspaper and many digital first outlets have popped up in recent years there are more youtube channels who do journalism like this one https://en.wikipedia.org/wiki/Mukesh_Chandrakar. Ideally we all would like to use academic sources and peer reviewed research papers but those take a long time to come up. personally I think we should use all the sources that are available with discretion and avoid sources that are notorious for fake news like OpIndia.

These almost always seem to end up with WP:CTOP designations and big messy fights that sprawl out to every noticeboard. It would be better for us to produce these articles slower
— User:Simonm223

I would actually support this, those fights take alot of energy and alomost always lead to nowhere. DataCrusade1999 (talk) 07:27, 31 May 2025 (UTC)

Section break 3

  • This discussion is just more proof that the primary/secondary divide does more harm than good. We can't even agree on which things are primary and which are secondary, which is understandable since nobody else can either. Every time the primary/secondary divide comes up, the discussion diverges away from what we should be discussing, which is the value of the source to the encyclopedia. A source is good if it (1) is published, (2) is reliable, and (3) can be cited without OR. Zerotalk 11:43, 31 May 2025 (UTC)
    @Zero0000, Agree Sm8900 (talk) 16:00, 5 June 2025 (UTC)
Wikipedia should probably prefer non-news media sources, and if the events happened 10yrs or more ago there usually no good reason not to rely on more modern academic sources. However for current events there's little choice.
When it comes to news media from the countries involved I think it would set a bad precedent to limit them in the way suggested. If the entire news media of a country has been captured by it's government then that will be shown by other reliable sources, and discussions should focus on those sources on a per country basis. All sources should be read critically and editors should be wary of all war time news reporting regardless of the country, but those are general points. -- LCU ActivelyDisinterested «@» °∆t° 16:44, 31 May 2025 (UTC)

On use MDY dates

I don’t think the MDY dates template—and its DMY counterpart—are needed on Wikipedia. The usage section of the template says its to “promote consistent date formatting”, but I don’t see how a piece of markup advocates editors into following guidelines. Why does this specific guideline need widely-used templates? I’d understand its inclusion on articles that are ambiguous on nationality, such as if the subject is British-American or something, but the templates see use on many many articles I see as unnecessary for their inclusion, such as articles that don’t even have days or months included in their dates (e.g. Wenasco, Texas).

And if its used on nationally-ambiguous articles, I still don’t see need for it. Numbers are part of orthography, and thus would be covered with the article’s corresponding dialect template. Roast (talk) 23:03, 5 June 2025 (UTC)

  1. Some editors and potentially some bots check the oldest "use XXY dates" category and run a script to convert dates in other formats into the specified format.
  2. Some templates like the citation templates check that template to decide what format to automatically convert date parameters to. E.g. {{citation|date=2025-04-18}} automatically converts the date to April 18, 2025 if it finds the use mdy template and 18 April 2025 if it finds the use dmy template without needing human intervention.
Aaron Liu (talk) 23:10, 5 June 2025 (UTC)
There isn't a 1:1 correspondence between DMY or MDY dates and a national variety of English. For example, the other day I came across a continental European railway-related article (probably Polish or Austrian) that consistently used American spellings but DMY dates. I look for the presence of these templates to see what the article should be using if I find one that is inconsistent. Thryduulf (talk) 23:33, 5 June 2025 (UTC)
The template does not just advise editors - it also advises the bots. When a bot makes an edit to an article, it complies with the format in the template. Templates such as the citation templates also honour it. Hawkeye7 (discuss) 00:58, 6 June 2025 (UTC)

100% human simple summaries?

View simple summary
Last updated on 22 June 2025
Readable summary
What if the WMF's "Simple Summaries" were human-written and added to technical articles?

A lot of you have probably heard about the WMF's recent "Simple Summaries" project, which was strongly rejected by the community because of the use of LLMs.

However, I wonder if the idea, outside of the AI implementation, might have some promise. While leads usually do this job, some leads might be too long and technical to provide a short, readable summary, and we don't want to sacrifice precision in the lead for that purpose. Having a short, easy-to-read summary on these articles could be helpful for the more casual readers.

I've drafted an example at User:Chaotic Enby/Simple summary, but it is of course just a first draft! Chaotic Enby (talk · contribs) 16:13, 4 June 2025 (UTC)

ooh, this would be/looks cool! Sohom (talk) 16:19, 4 June 2025 (UTC)
As I said in that discussion, the idea of simple summaries is good the implementation is not. This looks like a good implementation of that good idea. Thryduulf (talk) 16:22, 4 June 2025 (UTC)
Looks good; but your summary could use some work - dopamine does quite clearly have an "e" at the end of it ;P CoconutOctopus talk 16:46, 4 June 2025 (UTC)
I mixed up does and doesn't, my bad! Was I an AI hallucinating that whole time? Chaotic Enby (talk · contribs) 16:59, 4 June 2025 (UTC)
We already have various article summaries, in the form of short descriptions, the WP:LEAD, and Simple English Wikipedia. Let's think carefully before adding the maintenance burden of yet another type of summary. –Novem Linguae (talk) 17:22, 4 June 2025 (UTC)
I don't think short descriptions or leads (as they are) really meet this need -- but I think you've very right about the Simple English Wikipedia. Shortdescs are much too short, and leads neither are nor should be as simple as a 5th grade reading level. (Justifying my "should be": our articles have to serve people who have never heard of a concept and experts who want to refresh their memory on key technical details. Balancing both aims necessarily produces more complex text than if we only addressed the simple case. I recently helped review the wonderful FA flower. My standard for "reasonably accessible to a non-botanist" was "jargon is glossed and wikilinked", and while I think the lead is impressively clear, it would be still challenge a 5th grader.)
I can understand the motivation to make information more accessible through simpler language. I also think the payoff for this kind of effort is very different based on article topics. (As much as I loved writing St. Alban's Abbey, A Metrical Tale, it's not going to be highly-trafficked by novices desperate for a quick overview.) I think there's an interesting idea in adding a simplified summary to some articles -- and I think it would be even better if this involved more closely integrating or surfacing the work people already do at Simple English. ~ L 🌸 (talk) 17:33, 4 June 2025 (UTC)
I don't see the jargon terms in Flower's lead that should be rewritten and included in the simple summary. I don't see what a simple summary would add that isn't already done by the lede. Aaron Liu (talk) 21:26, 4 June 2025 (UTC)
@Aaron Liu, you are a highly literate person. I assure you that lead is not simple for someone who is not one such. -- asilvering (talk) 21:47, 4 June 2025 (UTC)
Could you show an example of a part that would be kept in and would benefit from a simple summary? There are many parts that I won't understand without clicking on the links but I think these parts are all very likely to be omitted from the summary. Aaron Liu (talk) 23:15, 5 June 2025 (UTC)
We also used to have a whole bunch of articles like Introduction to genetics and Introduction to evolution, that are simplified in the way being envisioned here (which, nb, is completely different from the way simple: works - they simplify language only, not concepts). They've almost all been either deleted or redirected back to their main articles. —Cryptic 19:44, 4 June 2025 (UTC)
Exactly that, Novem Linguae. MOS:INTRO already says The lead section should briefly summarize the most important points covered in an article, in such a way that it can stand on its own as a concise version of the article. ... Make the lead section accessible to as broad an audience as possible. Where possible, avoid difficult-to-understand terminology, symbols, mathematical equations and formulas. Where uncommon terms are essential, they should be placed in context, linked, and briefly defined. Surely what is described above is exactly a "simple summary"? I struggle to see the merits of something else in addition to the lead, given that it would be, to my eyes, duplicative of a well-written lead not to mention the bother of having to keep it and the lead and the article body in sync. Cheers, SunloungerFrog (talk) 22:30, 4 June 2025 (UTC)
I think this is not a good direction for en-wiki - because we already have Simple English. What I'd like to see, and what I've wished we had for a long time now, was a more obvious link to Simple English Wikipedia. Right now it's buried in with the translations - and who would look there? Having "view this article in Simple English" or something as a clear, obvious link would be very helpful for readers who need this kind of thing, and also, I hope, prompt more en-wiki editors to think about simplifying their own language, or even writing the lead-level stuff on simple-wiki themselves. -- asilvering (talk) 17:31, 4 June 2025 (UTC)
Hah, jinx! I find myself wondering about a collapsible tooltip that automatically offers the simple-english lead. It would sure encourage en-wiki writers to look after the simple-wiki versions of articles...! ~ L 🌸 (talk) 17:35, 4 June 2025 (UTC)
Maybe that template could transclude from (part of) the Simple English lead? That way, it wouldn't be redundant, wouldn't require volunteer-hours for pages with an existing Simple English version, and would invite editors to improve Simple English instead! Chaotic Enby (talk · contribs) 17:51, 4 June 2025 (UTC)
The first paragraph and a "read more on Simple English Wikipedia" link, maybe? -- asilvering (talk) 18:01, 4 June 2025 (UTC)
That could be great! Chaotic Enby (talk · contribs) 18:09, 4 June 2025 (UTC)
This just foists the work investment off onto a different project with dramatically less manpower and different standards. You really think simple: is ready and willing to handle an influx of people writing non-simplified versions of (clicks on Special:Randompage a couple times) Voice of Punjab, Eric Kinoti, Ben Osborn, and Alpha Michigan Brewing Company created solely to add the special box to en:? —Cryptic 18:41, 4 June 2025 (UTC)
An influx of people could help with the "dramatically less manpower" part. I don't see why we should assume en-wiki editors cannot write simply. I had a lot of fun writing about The Parson's Tale for simple-en-wiki. ~ L 🌸 (talk) 18:51, 4 June 2025 (UTC)
I do take your point that simple-en-wiki shouldn't be the passive recipient of somebody else's decisions any more than en-wiki or any other wiki should! But I still see an idea worth exploring here. ~ L 🌸 (talk) 18:52, 4 June 2025 (UTC)
I don't think it will require that much work investment, as the only pages with these boxes will be technically-written pages that laypeople are still likely to look up – which, most likely, will already have a simple: article. I am not considering adding these to every single one of our 7 million articles.
Also, not sure what you mean by "non-simplified versions", as the simplification is exactly the point? Otherwise it would be redundant with the existing en: lead. Chaotic Enby (talk · contribs) 18:53, 4 June 2025 (UTC)
To the "every single one of our 7 million articles" point - the way I'm afraid this would work in practice is that Joe Random Businessman, after telling his employee, "Hey, minion, go make me and my company vanity articles on Wikipedia like everyone important has", follows up with "Hey minion, how come my articles don't have that summary box like everyone else's do?" Or, less nefariously, just that it would come to be a de-facto requirement for any "proper" article, just like an infobox, image, references and external link sections, geolinks (for subjects with fixed positions), etc. are. —Cryptic 19:44, 4 June 2025 (UTC)
That is indeed a good point, but it can be solved by making it clearly intended for only a subset of articles (those that will have an audience of both lay readers and technical readers, and where both can't be satisfied by rewording the lead to be more accessible). I don't think it will become a requirement for any "proper" article any more than image galleries or navboxes are – to pick examples of features that only make sense on some kinds of articles. Chaotic Enby (talk · contribs) 20:03, 4 June 2025 (UTC)
@Chaotic Enby, I assume what Cryptic means here is that people will go to simple-wiki and write a very un-simple article there. This is already a huge problem, and it's not always easy to tell the difference between "not good at this" and "not really trying". But I think an influx of attention from en-wiki editors would be helpful in this regard. I wish more of us spent more time there; I've been trying to do so myself. -- asilvering (talk) 19:09, 4 June 2025 (UTC)
Right. "Simplified" is jargon at simple:, much like how notability here doesn't mean what it says in definitions 1-3 at wikt:notability, and I was using it in that sense. —Cryptic 19:13, 4 June 2025 (UTC)
Thanks, I missed the nuance! Yeah, it could be good to remind en.wiki users coming to simple.wiki about that. I also think a (controlled) influx of editors could end up being a net positive for simple.wiki, but an "onboarding for newcomers" arriving that way should definitely be considered. This whole idea should probably also be discussed with the simple.wiki community before having a RfC here (if we get to that point), to make sure they're ready for it and so we don't make decisions for them. Chaotic Enby (talk · contribs) 19:18, 4 June 2025 (UTC)
@Cryptic, the volunteers for en-wiki and simple-wiki write in the same language. Obviously, en-wiki shouldn't make decisions for simple-wiki and anything involving both should have buy-in from both. But it's not like doing this would be throwing a bunch of work onto simple-wiki's plate and saying "your problem now, suckers!" Crucially, if we handle it, rather than some WMF AI gadget, we can handle any arising content and conduct issues as we usually do - including by giving up on the idea altogether. -- asilvering (talk) 19:07, 4 June 2025 (UTC)
I disagree with the proposal to add simple-wiki ledes to enwiki article. There just isn't enough moderation on simple-wiki and we could end up with vastly wrong or even outdated information in the lede of articles. Additionally, interwiki templates aren't a thing (and it would be a pain to add it specifically for this feature). Sohom (talk) 21:46, 4 June 2025 (UTC)
I think there's a distinction between Simple English and the concept of a simple summary. As described at simple:Wikipeda:About and simple:Wikipedia:How to write Simple English pages, Simple English Wikipedia uses a simpler set of vocabulary and sentence structures. A simple summary doesn't have to be constrained in these ways. As I understand it, it's essentially a very brief, high level overview of the topic. isaacl (talk) 21:57, 4 June 2025 (UTC)
If we're going to invest millions of editor-hours on something, it should be something much more self-evidently worthwhile. —Cryptic 17:36, 4 June 2025 (UTC)
I'm thinking that it would only be needed for very technical topics that a layman is likely to look up, so a small subset of all articles. Chaotic Enby (talk · contribs) 17:51, 4 June 2025 (UTC)
Don't forget "anything a child or language learner is likely to look up", as well. That's probably a bigger demographic, honestly. -- asilvering (talk) 18:00, 4 June 2025 (UTC)
Any article I controversial subject should not have a simple summary Doug Weller talk 19:32, 4 June 2025 (UTC)
That depends why the subject is controversial and how simply the controversy is to explain, e.g. Kashmir is an area of land in south Asia that is partly administered by India and partly administered by Pakistan but claimed in full by both countries. Thryduulf (talk) 19:45, 4 June 2025 (UTC)
@Chaotic Enby I like this idea. I think there is value in a "medium description" between the short descriptions and the article content. We already do this elsewhere, with the {{nutshell}} template. JackFromWisconsin (talk | contribs) 19:38, 4 June 2025 (UTC)
I like the idea of just having a note that says "Read more at Simple English Wikipedia" Somewhere in the lead (possibly as a hatnote, or at the end of the lead). It requires the minimal work and gives attention to a lesser-known project. It should be placed selectively on pages that are likely to have technical and layman audiences such as flowers. Ca talk to me! 23:01, 4 June 2025 (UTC)
Can't help feeling this is trying to solve the problem with leads, by creating a different lead. Instead maybe a drive to simplify leads and remove clutter from them. Many of the first sentences in articles run on forever, with multiple sections (and other parts in brackets), when they should instead be short and to the point. -- LCU ActivelyDisinterested «@» °∆t° 20:37, 5 June 2025 (UTC)
I don't think this is as simple as that, ledes need to summarize all of the information in the article per MOS standards, and that is often at odds with the goal of short simple to the point sentences. The ledes of one of my first articles, Cross-site leaks still suffers from the same problem, the lede can be either really long winding explaining every single detail,or not omit mention important interesting details mentioned in the article in an effort to be beginner accessible or it can be technical succint, comprehensive and short, in which case we effectively give up on the goal of making it accessible to the average reader and expect competence in the subject (my lede tries to toe the line between both but has to assume a basic level of understanding on web fundamentals, which many might not have). This kind of article would benefit heavily from having a small infobox/summary box that explains the concept of the attack in more accessible/non-techy language. Sohom (talk) 01:35, 6 June 2025 (UTC)

Or... just change your minds, allow the WMF to do its job, and let an AI generate those 7 million summaries in a couple of hours, instead of forcing people to work manually for years to get a similar result. And that, if a user consensus can actually go against the WMF. They are, after all, the owners of this site, and have not (as far I'm aware) requested feedback on that tool. They may decide to ignore the unrequested feedback and implement their project anyway (remember, "Wikimedia Foundation currently does not consider this page to be a communication venue"), which would make this whole endeavor pointless. Cambalachero (talk) 18:33, 4 June 2025 (UTC)

The WMF hosts Wikipedia. They don't own it. -- asilvering (talk) 18:38, 4 June 2025 (UTC)
Distinction without a difference. Cambalachero (talk) 19:24, 4 June 2025 (UTC)
I disagree in the strongest possible terms. -- asilvering (talk) 19:31, 4 June 2025 (UTC)
Even ignoring the philosophical issues some people have with AI use, current LLM technology (or at least the LLM used for the example given) is not capable of generating accurate summaries. An incorrect summary is worse than no summary. Thryduulf (talk) 18:41, 4 June 2025 (UTC)
To clarify, I never suggested writing summaries for all 7 million articles, just the few that are both highly technical and yet likely to be read by laypeople. Chaotic Enby (talk · contribs) 18:48, 4 June 2025 (UTC)
Right, because we should just roll over and let Wikipedia be enshittified. JackFromWisconsin (talk | contribs) 19:28, 4 June 2025 (UTC)
Funny thing, the WMF was probably thinking exactly that. The format of Wikipedia is a relic from the 2000s era of internet, it already decays well enough on its own. Cambalachero (talk) 00:29, 5 June 2025 (UTC)
I'm not opposed to this idea necessarily. But I'd want to see a more fully fleshed out proposal that clarifies a few things (in no particular order):
  1. What articles should qualify for this sort of "short/simple summary"? Specifically, should there be some minimum length of the lead before an article can "automatically" qualify? Alternatively, should there be some minimal level of technical knowledge needed to understand the lead before an article can "automatically" qualify?
  2. Similarly, should there have to be consensus before a simple description is added to the page? I would venture a guess that the answer to this is yes - because other solutions (such as making the lead less technical or shortening it) may be preferable to both editors and readers - but if the short summary can just be added and then it requires a consensus to remove it, it becomes another argument for "well we can make the lead as technical/complex/long as we want because there's this short summary here"
  3. Along the same line, how does this affect WP:LEAD and similar PAGs? For example, LEAD states It should be written in a clear, accessible style with a neutral point of view - if a short summary is necessary, then it seems likely that the lead is not "written in a clear, accessible style". Would the existence of short summaries merit changes to that or other PAGs to account for the short summary?
  4. If people disagree on whether an article even needs a short summary, should it go based off of STATUSQUO/"last stable version"? IMO it may be better to say if disagreement over whether an article even needs one, it should be removed pending consensus on the talkpage, even if it's been on the page for a while - because in the time since it was added originally, the lead may have changed significantly to either become shorter or become easier to understand. This prevents arguments of "it's not harming anything to have it" in a discussion to remove it, even if it's blatantly clear it's no longer necessary and just makes more work to keep it up to date.
  5. How to ensure readers understand if the description is based on an old version of the article? For example, WP:CHEMVAL style system - but even that's not clear enough to the reader in my opinion. Should there be a specific warning presented such as This article has been edited by others since this summary was last updated. This summary may thus be incorrect, out of date, or incomplete. If you want to read the most up to date summary, "click here" to be shown the lead section of the article, or "click here" to still see the outdated short summary. That brings up another point - if such a system like this is implemented, what sorts of changes should "cancel" the "validation" of it? Only changes to the lead? Changes of a specific size anywhere in the article?
  6. The interconnect between this system and the general lead expectations - for example, does an article having a "simple summary" mean that editors can make the lead as technical as they want to, regardless of if the technical parts are already discussed/covered later in the article?
  7. The interconnect between the short summary and "special circumstances" such as WP:CTOP procedures. For example, do short summaries need to be directly called out as subject to an increased level of scrutiny, since the goal is to have them be what someone who doesn't want to read an entire article will read? I foresee this becoming a big problem in very contentious areas because in a quest to be "short" and easily understandable, it's very easy to (un)intentionally violate NPOV because it's "more clear" or "more concise".
Ultimately I kind of like the idea - but I'm worried that many of the questions above are going to be hard to answer. I gave my opinion on some of them, which probably isn't the same as others would have (for example, defaulting to remove if it's challenged). But I look forward to seeing this develop further, because it ultimately could be helpful to readers who are just looking for a quick summary of a topic that has a very long lead section or is too technical, and not any sort of details or technical information about that topic. -bɜ:ʳkənhɪmez | me | talk to me! 19:47, 4 June 2025 (UTC)
Very good questions! I don't necessarily have answers to most of them. The question of whether it could be an excuse to make the lead more technical is definitely a foreseeable issue – I'm not sure of the exact difference between points 3 and 6 here.
Regarding the first two points:
  • This should clearly be limited to articles where there might be a disconnect between intended audiences, i.e. where a technically precise lead might not fulfill the needs of a lay reader, but where the latter is likely enough to look up the article. I'm envisioning this to be a pretty limited use case, and wouldn't want articles to "automatically" qualify just because they meet a certain level.
  • I definitely believe consensus should be necessary to add it (specifically, consensus that the lead paragraph itself can't be written in a manner that could satisfy both casual and specialist readers). If people disagree or there is no consensus, it should default to not having one.
Chaotic Enby (talk · contribs) 19:58, 4 June 2025 (UTC)
For point 5, I don't think that kind of update warning is really necessary – lead sections, for instance, don't have these kinds of warnings if the rest of the article is edited without the lead being updated.
Regarding point 7, I think very contentious articles should just not have these. Especially if we go the "transclude form simple.wiki" route (as they don't have the same CTOP aspect as us), but also (regardless of how we go at it), as you say, because simplifying to a few sentences makes it that much harder to keep something NPOV. Chaotic Enby (talk · contribs) 20:07, 4 June 2025 (UTC)
Oop, thought I replied to you when I saw this originally, I must not have hit reply or something. I agree with most of what you say here. I think the important thing is that a specific proposal is fleshed out - for example, will it be prohibited to add to a page where the disconnect applies? Is it just strongly discouraged? If the second, does it require a consensus before one can be added? If not, can it be removed by any editor and then require a consensus to readd it, even if it's been months (keep in mind many of these articles are likely low-traffic and/or low-watched)? On the subject of the update warning, I think Thryduulf below is on the right track towards beneficial information that isn't "robotic" like my original idea was. I would also fully support CTOPs not being allowed to have these. Most of my "questions" were just my rambling ideas - not all of them may be necessary/useful - they were just my brainstorming over potential problems because I would think an idea like this would be great... but it needs fleshed out for the community to be likely to accept. -bɜ:ʳkənhɪmez | me | talk to me! 21:59, 4 June 2025 (UTC)
Since low-traffic articles are specifically not the target for this (as their intended audience most likely doesn't include lay readers), it could make sense to require an affirmative consensus on the talk page to not have people just add them everywhere. Chaotic Enby (talk · contribs) 22:08, 4 June 2025 (UTC)
Hm, I'd think low-traffic but very technical articles would be a good target for this. For example, complex medical articles like Angiostrongyliasis. The current lead is good there - but it uses a lot of complex medical terms that someone just looking for a layperson's summary of it would not understand without clicking through and reading the articles on those terms (if they're linked). Obviously we aren't here for medical advice, but I'm thinking of the reader who gets a text from their family member from around the world (maybe without the best understanding of English, so they can't explain it themselves) saying "I was diagnosed with (disease)", and that reader coming here, typing it into the search bar hoping to just understand what it is, and reading a bunch of terms they don't understand.
Not to mention many people going through Wikipedia reading about something - whether they're just curious or are trying to learn about it - currently may have to click to 3+ other articles just to understand terms used in the lead. I don't think just because it's low traffic it shouldn't be the target - we're here for not only people with technical knowledge but also people who are just curious about something. Hence I don't think low-traffic is a good criteria.
That said, I do think consensus on the talkpage is still a good idea to be able to add one - because improving the lead to be more "reader-friendly" is preferable to just using a short summary to "make up for" the lead being too technical in the first place. -bɜ:ʳkənhɪmez | me | talk to me! 22:27, 4 June 2025 (UTC)
I didn't think of those cases but they completely make sense! Chaotic Enby (talk · contribs) 23:52, 4 June 2025 (UTC)
On point 5, one thing the WMF example got right was explicitly stating the date on which it was generated. If manual summaries are being supported by software in any way then it would be trivial to automatically add a note at the bottom along the lines of "This summary was last edited on <date>, the article was last edited on <date>." perhaps with an explicit "This summary may be out of date." if the two differ (and the article size differs by at least [amount to be determined]?)".
Regarding the threshold for removal due to being outdated or inaccurate, I think there should be two levels: Where it is objectively and unambiguously one ore more of the following then anyone can remove it without discussion (but with mandatory statement of reasoning):
  • Fundamentally incorrect (including due to being grossly outdated). Minor, inconsequential inaccuracies and simple disagreement don't qualify.
  • Nonsense
  • Vandalism
  • Copyvio
  • BLP violation
  • Added contrary to explicit consensus
In other cases I'd say removal should be proposed with the threshold for removal being any of the following:
  • A clear consensus to remove
  • A majority in favour of removal after ~5 days of discussion
  • No response to the proposal after ~5 days
In all cases, removal of a summary added with consensus is without prejudice to the addition of a new summary at any time, unless there is an active consensus to remove permanently. i.e. an active consensus to have (or not have) a summary requires an active consensus to reverse
Thryduulf (talk) 20:27, 4 June 2025 (UTC)
To me, merely listing the date generated isn't really sufficient. Similar to the CHEMVAL project, I suspect most people are likely to just ignore the "last edited" date as most of us ignore the checkmark/x-mark already. I like your proposed wording that includes the last edited date of both the summary and the article with a short comment.
But that said, I do tend to agree with most of your statements here regarding removal - especially the 5 days limit without response/dissent being an acceptable reason to remove pending new consensus. However, I'd pose that if a summary is removed "for cause" (i.e. for one of the reasons you list, or because no clear consensus to keep it after 5 days), it should be prohibited from being readded until there's a clear consensus that the article needs one in the first place, if not for the content of it. I think it's doing our readers a disservice to have this sort of short summary if it's not strictly necessary and beneficial for them - since it'll necessarily have less context/depth than the lead will. -bɜ:ʳkənhɪmez | me | talk to me! 20:35, 4 June 2025 (UTC)
In terms of the warning, it would probably be useful to have a way to indicate that the summary has been verified accurate more recently than the date it was last edited, e.g. this edit of mine would trigger automatic indications of a significant time between summary edit and article edit and significant change in article size but wouldn't have impacted the accuracy of the summary at all (I know that article almost certainly doesn't need a summary, it's just my most recent edit that clearly illustrates the point. A likely-to-be encountered similar scenario would be adding archive links to the references in a technical article). Thryduulf (talk) 21:00, 4 June 2025 (UTC)
Maybe: "This summary was last edited on (date), verified by an editor on (date), and the article was last edited on (date). There may have been significant edits since the last time this summary was verified" or similar? That gets a bit long. I also can't think of any way to really decide "significant" edit in terms of tracking it, hence why I was suggesting maybe just edits to the lead (and I guess outside of reference tags) - as ideally anything in the short summary should be in the lead as well (and anything removed from the lead likely shouldn't be in the summary). I don't really know - but I am glad that at least some of my random musings are generating productive ideas :P -bɜ:ʳkənhɪmez | me | talk to me! 21:30, 4 June 2025 (UTC)
I'm not sure it's worth the effort to establish consensus for summarizing an article. If the summary is the lead paragraph, then no discussion is necessary. Once a topic gets sufficiently complicated that one paragraph isn't enough for the lead section, the lead section can be re-written with the initial paragraph serving as a summary. isaacl (talk) 22:22, 4 June 2025 (UTC)
This would be acceptable too, but would require a change in the WP:LEAD guidelines. If people think that changing the LEAD guideline to account for long leads, making the first paragraph a "top level overall summary", followed by paragraphs specifically, then that may work too. But I'm curious how that would apply to an article like Donald Trump, for example. I would think that iff that article qualified for this sort of short summary (which I don't think it would), the short summary would be more than "is an American politician, media personality, businessman, and Republican who was the 45th President and is currently the 47th President". Yet I don't think having a full first paragraph summarizing more is appropriate for that article. -bɜ:ʳkənhɪmez | me | talk to me! 22:30, 4 June 2025 (UTC)
Yes, I mentioned below the need to change the guidance about the lead paragraph. Either way, something in the guidance has to change. My initial personal feeling is that it would be better to integrate a one-paragraph summary into the article. It would minimize repetition, thus making maintenance easier, and would use a familiar structure for readers. isaacl (talk) 22:49, 4 June 2025 (UTC)
That comment appeared to me right after I hit reply in the reply tool - but I didn't see a notice "1 new comment" like is supposed to happen :P I would've just replied to that one had I noticed it.
Ultimately I agree that making our leads more accessible to readers in general - such as following the inverted pyramid structure like you suggest - would be preferable... I don't know if massive changes to LEAD like that would pass the community as a whole. It almost seems "micromanagey" so to speak. Not to mention that different fields may have different ways a lead should be structured - such as WP:MEDMOS, which I would suspect probably would need updated to be an exception to the "inverted pyramid" structure for many articles. -bɜ:ʳkənhɪmez | me | talk to me! 23:15, 4 June 2025 (UTC)
Personally, I don't prefer a strict adherence to an inverted pyramid structure for an encyclopedia article. But in essence adding a summary at the top of an article would still be doing that, even if it's inside a collapsible box.(*) Thus if that's deemed important to do, I'd rather integrate it directly into the article.
(*) People already disagree on summarizing a topic inside a box: the infobox. So it's not clear to me that it would be easier to get consensus to put a summary inside a box, rather than improve the lead section of articles. isaacl (talk) 01:24, 5 June 2025 (UTC)
I didn't want to bring it up, but yes, the contention around infoboxes is a big reason I'm worried about this being a thing unless it's a strong proposal that can gain large consensus. I agree with you that I'd prefer it be in the article directly - but if that's not possible, this sort of thing would be a close second. -bɜ:ʳkənhɪmez | me | talk to me! 01:28, 5 June 2025 (UTC)
I think it is worth considering if the guidance on the lead paragraph should be modified to explicitly make it serve as a summary of the topic. This would push Wikipedia articles further towards the inverted pyramid form favoured by journalism, which has its pros and cons, but may be a better fit for reader needs. This would hopefully minimize the overhead of maintaining two summaries of each article. isaacl (talk) 22:05, 4 June 2025 (UTC)
(reply to this comment) LLMs are prone to NPOV and MOS:OP-ED violations and hallucinations. See Wikipedia:Using neural network language models on Wikipedia/Transcripts and Special:GoToComment/c-Chipmunkdavis-20250603184300-The_Dopamine_summary. Allowing one to go amok over all of our articles would be disastrous. OutsideNormality (mobile) (talk) 20:17, 4 June 2025 (UTC)
Yes it might take hours for a LLM to generate the summaries, but it would take hundreds of thousands of hours of work by editors to fix the rubbish it generates. -- LCU ActivelyDisinterested «@» °∆t° 20:44, 5 June 2025 (UTC)

Separation of User content.

Hello, Wikipedia contributors!

My proposal is to separate the encyclopedic content of Wikipedia from User content, such as User pages and User sandboxes. User content typically isn't encyclopedic or contributory and presents biographical and personal content that doesn't align with the encyclopedia's goals. If the Wikipedia content and User content were separated into two Wikimedia projects, current restrictions on User content could be more relaxed, since the content no longer needs to be (mostly) relevant to the encyclopedia. I don't support offensive or inappropriate content, and don't propose that those guidelines be forgotten.

If you have any feedback, please do speak up! Even small feedback is helpful! 22ManzanaBoy (talk) 16:09, 3 June 2025 (UTC)

if you want a social media platform, there's plenty of options out there. there not going to spin off user content here so you can make a pretty page about yourself. ValarianB (talk) 16:34, 3 June 2025 (UTC)
Thank you for your feedback! To clarify, I’m not personally interested in biographical content, but others are, and the removal of it entirely could cause backlash. Wikipedia is built by contributors, and the people who contribute enjoy writing biographical content on here.
Biographical content isn’t the entire extent of a user page. It’s also used for experimental projects, which could benefit Wikipedia.
Countless arguments on User content distract users from the main goal of the site. Separation could shine a bigger light on the encyclopedic content.
User pages aren’t normally visually compelling or stimulating, unlike social media, which is built for addiction. To add, the wiki format is much more accessible than a social media website, which can be helpful and accessible for all users.
Again, thank you for your feedback! 22ManzanaBoy (talk) 16:47, 3 June 2025 (UTC)
This sounds like you're asking for a wiki that hosts personal content that may or may not relate to Wikipedia. If so there are plenty of existing sites on the internet that offer this, notable ones are listed at Wiki hosting service. Thryduulf (talk) 16:37, 3 June 2025 (UTC)
While the spin-off site could have personal content, it’s not entirely irrelevant to Wikipedia. User pages showcase contributions, which can help build a reputation on the site. Experimental content can help better the site, and the User talk pages discuss issues.
Thank you for your feedback! 22ManzanaBoy (talk) 16:51, 3 June 2025 (UTC)
If content is "not entirely irrelevant to Wikipedia" then it can go on user pages. If it is entirely irrelevant then it can go on a social media site or anywhere other than Wikipedia. Phil Bridger (talk) 17:28, 3 June 2025 (UTC)
Content that's even just partly irrelevant shouldn't be on Wikipedia. We don't have have the dictionary definition for every word on Wikipedia because it's "partly relevant." We have it on a sister project called Wiktionary. I'm suggesting we treat user pages the same way and put them on a sister project.
I don't only suggest it as a website for personal content. It also functions as a database of Wikimedia Foundation users.
Thanks for the feedback! 22ManzanaBoy (talk) 18:06, 3 June 2025 (UTC)
I wonder if you could explain, in very concrete and simple words, what exactly you think it would mean to put User:22ManzanaBoy on "a sister project". For example, you might say something like "Right now, the URL for my user page says https://en.wikipedia.org/wiki/User:22ManzanaBoy but if it's on a sister project, then https://en.wikipedia.org/wiki/User:22ManzanaBoy will not exist and the URL will say https://en.wikipedia-users.org/wiki/User:22ManzanaBoy instead". Or you might say "Right now, if you click on my name in my signature in this discussion, you go to User:22ManzanaBoy, but if we put it on a sister project, then my signature will not have a link for my name". Whatever you think the change would do in practical terms, describe that. WhatamIdoing (talk) 18:21, 3 June 2025 (UTC)
I will note that userpages from Meta (being the "default" userpage) are already transcluded for users who have a userpage defined there but not on English Wikipedia, although I don't think that (or a similar thing) should be forced on all users or would be helpful in any way. Chaotic Enby (talk · contribs) 18:38, 3 June 2025 (UTC)
All user page links (or links to other pages with user content) would go to the sister project (for simplicity, we'll call it WikiUsers from now on). For example, my signature below would be a link to WikiUsers, where my user page will reside. Signatures will look the same as they do now, and the same account used for all Wikimedia projects can be used on WikiUsers. Existing links would automatically redirect to WikiUsers. 22ManzanaBoy (talk) 19:47, 3 June 2025 (UTC)
Why would a separate site be needed, instead of simply different policies for mainspace and userspace? Chaotic Enby (talk · contribs) 20:06, 3 June 2025 (UTC)
My concern is that new users could be confused and interpret it as encyclopedic content. Even if a "user content" notice was added, there's no guarantee that new users won't be confused anyway. 22ManzanaBoy (talk) 21:21, 3 June 2025 (UTC)
Some people have struggled to tell the difference between Wikipedia and other wikis (e.g., Fandom) or Wikipedia and other websites with 'wiki' in the name (e.g., WikiLeaks). If someone is actually stupid enough to believe that a page saying things like "When purchasing Wikipedia, this user is not included" or "My favorite food" is encyclopedic content, why do you think that changing the URL (which isn't really visible on mobile devices...) would make them understand that a User: page isn't an encyclopedia article? WhatamIdoing (talk) 23:12, 3 June 2025 (UTC)
Just because my user page is unlikely to be confused for encyclopedic content doesn’t mean others won’t be. Even if newcomers understand that my user page isn’t encyclopedic content, they might be confused why anything on Wikipedia would mention someone’s favorite food. While these silly user pages may seem useless, they have a purpose. One of Wikipedia’s biggest problems is editor retention, and user pages can compel editors to the site. 22ManzanaBoy (talk) 01:05, 4 June 2025 (UTC)
  • How often do you think readers stumble across a user page?
  • If you think that user pages increase editor retention, and that editor retention is a problem, then why are you trying to hurt Wikipedia by dumping user pages on another site?
WhatamIdoing (talk) 01:13, 4 June 2025 (UTC)
  1. Users can easily stumble across a user page by looking at an edit history or talk page. It’s not rocket science.
  2. User pages can be allowed more freedom on another site. Freedom is compelling, and increases editor retention. So why not add a guide to user pages? You could, but it gets in the way of the encyclopedia. Adding the guide onto the new site fixes this problem. It will also help Wikipedia by removing non-encyclopedic content.
22ManzanaBoy (talk) 01:24, 4 June 2025 (UTC)
  1. If readers stumble across user pages by clicking on links in history and talk pages on this site, then they will stumble across those same user pages by click on links in history and talk pages that point to another site, exactly as often as they do now.
  2. If readers are going to stumble across user pages by clicking on links in history and talk pages on this site, then we don't exactly want "more freedom", right? Because "more freedom" might well look like "making the user page look as much like a Wikipedia article as possible", which is the opposite of what you said you wanted. Also, putting material that Wikipedia links to in history and talk pages outside of Wikipedia's control will hurt Wikipedia.
BTW, we already have a guideline for user pages: Wikipedia:User pages. It doesn't appear to "get in the way of the encyclopedia" at all. WhatamIdoing (talk) 02:30, 4 June 2025 (UTC)
  1. While they still may stumble upon these links, the act of having an icon saying “WikiUsers” will make it much more likely that the reader will want to research further into what a user page is.
  2. By “more freedom”, I meant freedom of personal content, not encyclopedic content, which is already likely to be allowed on a user page. WikiUsers would be heavily connected to Wikipedia, not “outside of Wikipedia’s control.”
BTW, they get in the way of the encyclopedia by providing irrelevant information. 22ManzanaBoy (talk) 14:45, 4 June 2025 (UTC)
That is already how user pages work. User sandboxes and subpages can be used to work on new content, essays, scripts, etc., and user talk pages can already be used to discuss them. Chaotic Enby (talk · contribs) 18:17, 3 June 2025 (UTC)
New contributors that stumble upon the use of a namespace can make mistakes. The separation seeks to lower the amount of mistakes newcomers make. 22ManzanaBoy (talk) 21:28, 3 June 2025 (UTC)
Do you have any examples of high-traffic userpages that masquerade as articles that demonstrate the actual problem in practice? signed, Rosguill talk 20:05, 4 June 2025 (UTC)
The whole point of a sandbox is to create draft articles. Most dedicated users will have huge draft articles in their sandbox. 22ManzanaBoy (talk) 00:52, 5 June 2025 (UTC)
I'm willing to agree that someone might accidentally stumble upon User:22ManzanaBoy in a page's history, because that's actually linked there. But I'm not able to agree that someone will see a link to User:22ManzanaBoy in a page history and somehow (I dunno, a server glitch?) end up at User:22ManzanaBoy/sandbox or User:22ManzanaBoy/The Dark Side of Wikipedia. That's not a reasonable assumption. WhatamIdoing (talk) 03:10, 5 June 2025 (UTC)
Content in Wikipedia is already divided in namespaces for this reason. Cambalachero (talk) 20:00, 3 June 2025 (UTC)
New users typically aren't aware of what namespaces are. 22ManzanaBoy (talk) 21:23, 3 June 2025 (UTC)
True, but this means that they won't stumble upon the content outside of the main namespace, because Special:Search only looks at articles unless you explicitly tell it otherwise. WhatamIdoing (talk) 23:13, 3 June 2025 (UTC)
Links to user pages in edit histories and talk pages can easily be found by newcomers. 22ManzanaBoy (talk) 14:46, 4 June 2025 (UTC)
And won't they still be just as easily found if your proposal is followed? Phil Bridger (talk) 19:56, 4 June 2025 (UTC)
Yes, but Wikipedia's logo will be replaced with a WikiUsers logo, which will make it more likely that a new user will research what a user page is before making any mistakes. 22ManzanaBoy (talk) 19:59, 4 June 2025 (UTC)
You had an idea, which is all well and good, but on examination it turned out to be a bad idea. Just drop it and get on with editing. Phil Bridger (talk) 20:11, 4 June 2025 (UTC)
You can’t just say an idea is bad and expect someone to drop it. You always seem to exaggerate the cons and ignore the benefits, which I’ve clearly stated. Even if it doesn’t help new users, it does remove off-topic discussions from Wikipedia and allow more freedom for user pages, which increases editor retention. Having all these user pages on Wikipedia will hurt its reputation, which is already bad. 22ManzanaBoy (talk) 00:31, 5 June 2025 (UTC)
If we wanted to change the logo, that could be done on existing User: pages anyway. However, it's probably pointless to do so because Banner blindness is a real thing. WhatamIdoing (talk) 20:25, 4 June 2025 (UTC)
You only seem to be helping my argument. Tagging user pages with a banner just won’t help. Logos are a much more noticeable feature. 22ManzanaBoy (talk) 00:32, 5 June 2025 (UTC)
Logos are not a "more noticeable feature", because people turn a blind eye to logos. Logos are part of the "unimportant stuff at the top of the page that I can safely ignore", i.e., part of the "banners" that people are blind to. WhatamIdoing (talk) 03:11, 5 June 2025 (UTC)
I ask the doubters to take a minute and imagine this website with me. A website where you can easily view users. You can see which users have contributed the most, or which have experimented the most in their sandbox. View which periods of time had the most or least inactivity. See how Wikipedia grows with its user count.
Wikipedia is made by people, not policies and articles. 22ManzanaBoy (talk) 00:47, 5 June 2025 (UTC)
The only identified differences are:
  • the URL (which nobody looks at),
  • the logo (which we could already change in userspace without making it a different site), and
  • the possibility of having different rules (which we could do now, if we wanted to).
WhatamIdoing (talk) 03:18, 5 June 2025 (UTC)
Userspace logo change could be a fun idea (I think any individual user can overlay something with css anyway?), but also worth noting that Metawiki already exists as the site of users. CMD (talk) 03:36, 5 June 2025 (UTC)
That's right: You can change that with CSS, and whatever any individual can do to the appearance of a single User: page, the community can do for all the User: pages. WhatamIdoing (talk) 03:59, 5 June 2025 (UTC)
the possibility of having different rules (which we could do now, if we wanted to)
Don't we already have very different rules about what is acceptable in userspace vs in mainspace? Chaotic Enby (talk · contribs) 10:18, 5 June 2025 (UTC)
Yes. But the OP appears to want some other, unspecified rules. WhatamIdoing (talk) 18:20, 5 June 2025 (UTC)
Unspecified? All you had to do was ask. I just want lesser restrictions on personal and experimental content. People enjoy writing on their user pages, so editor retention will be higher, and the encyclopedic content can improve. 22ManzanaBoy (talk) 01:56, 6 June 2025 (UTC)
Or people will enjoy writing on their user pages, treat it like a free WP:WEBHOST, and be so distracted by their enjoyment of non-encyclopedic work that they'll do even less to improve encyclopedic content. WhatamIdoing (talk) 02:12, 6 June 2025 (UTC)
  1. Yes, you can view users, but…
  2. You can’t see them clearly. Even if we can see users by edit count, we can’t see them in different ways. Plus, that essay you provided was humorous (not meant to be taken seriously
  3. Just because you were able to find some fancy tools doesn’t mean others can. Accessibility is a factor here.
  4. Again, even if we already have THAT, there are other things we don’t. I was providing examples.
  5. We could just change the rules here, but reputation is key. Wikipedia’s reputation as a source of knowledge is already low, and adding rules to loosen up the rules on user pages won’t help and will just make it worse.
22ManzanaBoy (talk) 01:50, 6 June 2025 (UTC)
Which "different ways" do you want to see editors in? What does it mean to "see them clearly"? (That essay is written in a humorous style, but it is meant to be taken seriously.) WhatamIdoing (talk) 01:59, 6 June 2025 (UTC)
I have a question regarding "Having all these user pages on Wikipedia will hurt its reputation, which is already bad." 22ManzanaBoy, can you provide specific examples of existing user pages that hurt Wikipedia's reputation. Let's try to figure out what this is really about. Sean.hoyland (talk) 10:54, 5 June 2025 (UTC)

Backlog drive schedule page

Hi all—inspired by the WP:THEOTHERJUN25 shortcut, I have created Wikipedia:Backlog drive schedule. The main point of the list is to help backlog drive schedulers mimimize overlap with other drives to maximize how much we are able to improve Wikipedia. (Especially overlapping drives which would generally involve similar "types" of editors, like NPP and AFC.) It also helps editors find drives occurring right now, without tracking down each individual project which could be hosting a drive.

Thoughts/improvements welcome, especially if you know of other planned drives which can be added to the schedule! Best, HouseBlaster (talk • he/they) 21:34, 2 June 2025 (UTC)

Thanks for creating this! You may want to post a message about this on the relevant WikiProject talk pages as well, I didn't know this existed until I randomly came across it. ARandomName123 (talk)Ping me! 21:32, 5 June 2025 (UTC)
I've dropped a note at WT:NPPC and WT:GOCE; any other projects you had in mind? Best, HouseBlaster (talk • he/they) 05:24, 7 June 2025 (UTC)
Looking through MediaWiki talk:Watchlist-messages/Archive 13, WT:WPAFC, WT:WIG and WT:URA are the other projects with regular drives. I do drive planning for URA, so I can update it for us if needed, but a message there for other organizers would be helpful. ARandomName123 (talk)Ping me! 19:55, 7 June 2025 (UTC)
If expansion projects like WIG are included rather than just task backlogs, it is probably worth considering the WP:Core contest and various destubbathons. CMD (talk) 20:01, 7 June 2025 (UTC)
Dropped a note at WT:WPAFC and WT:URA. I didn't have content-improvement projects like WIG/WP:CUP/WP:DCWC/etc. in mind when creating the page, but I think they should be added to maximize the utility of the tool. Perhaps an additional column for "article expansion drives"? HouseBlaster (talk • he/they) 23:50, 8 June 2025 (UTC)
Sure, that sounds good. ARandomName123 (talk)Ping me! 00:45, 9 June 2025 (UTC)
Legitimately a great idea, I kinda expected this to already be a thing so it's great that you created it! Chaotic Enby (talk · contribs) 22:29, 5 June 2025 (UTC)

add games

wikipedia should add a game tab. Yes or no Nonobob8 (talk) 15:43, 5 June 2025 (UTC)

I would say no, unless it is a game to help new editors. But I'm an old fuddyduddy who remembers playing 'tennis' on the Binatone TV master and who still has and plays her N64. Knitsey (talk) 15:53, 5 June 2025 (UTC)
it is a game to help new editors 192.133.255.118 (talk) 13:22, 9 June 2025 (UTC)
There are WP:Wikipedia games, and some contributors will occasionally blow off steam at WP:Department of Fun related pages. However the primary focus here is encyclopedia building. Think a little less about a carnival and a little more about mining salt by hand and you'll have more manageable expectations. 184.152.65.118 (talk) 23:59, 5 June 2025 (UTC)
ok 155.190.1.6 (talk) 13:00, 9 June 2025 (UTC)

Linking to Commons category in description of an image

Hello everyone. I'm currently working on an article which mentions a lot of parliamentary debates. There are often more images from one debate, while I have only room for one. I try to select carefully, but it is always arbitrary. There is a {{Commons category}} at the bottom of the article, but that covers multiple images and categories.

What I would like, is a way for users to easily view related images when they are reading about it and seeing one of the selected images. The most effective - I think - is if there was a template like {{Commons category-inline}} designed for use in the description of an image. It might say something like "For similar images, see: xxx". The current Commons categories - as far as I can see - are designed for use in the External links section. One exception is {{Commons category-icon}}, but it gives no additional information.

What do people think about this? Dajasj (talk) 09:58, 7 June 2025 (UTC)

@Dajasj, I think that Wikipedia:If a rule prevents you from improving or maintaining Wikipedia, ignore it. WhatamIdoing (talk) 04:55, 11 June 2025 (UTC)

Notification of access to Wikipedia Library

I've found that lots of people aren't aware that they can access the WP:Wikipedia Library, maybe this could be addressed by having an automatic notification for editors once they hit 500 edits after 6 months (and have no active blocks)? This would hopefully lead to people more often using better sources, and potentially even save them money. On the flipside, notifying people manually is good for collegiality, but there must be so many that never get made aware. Kowal2701 (talk) 14:53, 7 June 2025 (UTC)

There is already an automatic notification for this, detailed in phab:T132084. the wub "?!" 16:21, 7 June 2025 (UTC)
Thanks, but I’ve never seen this, has it since been disabled? I’ve seen lots of people that were eligible but not aware Kowal2701 (talk) 16:27, 7 June 2025 (UTC)
No. I received my notification at the correct time a couple of months ago. Cheers, SunloungerFrog (talk) 16:33, 7 June 2025 (UTC)
I guess receipt of a notification and awareness are not necessarily the same thing. I got my notification on 26 January 2022 if that helps. Since my account has been around for a while, maybe that was when many accounts received it. Sean.hoyland (talk) 17:14, 7 June 2025 (UTC)...a quick check shows that this theory of mine is nonsense. I happened to receive it because I happened to log in that day (during a period when I was very rarely editing). Sean.hoyland (talk) 17:21, 7 June 2025 (UTC)
In the phab thread someone floated the idea that it be restricted to people with an additional user right to ECP, and you two both have additional rights, maybe that was what happened? Kowal2701 (talk) 17:22, 7 June 2025 (UTC)
ECP is granted automatically at 500 edits, 30 days, a lower requirement than library access. I received the EC grant back in 2016 when they were rolling it out. Sean.hoyland (talk) 17:39, 7 June 2025 (UTC)
Having access is great, but using this is a little on the confusing side. In particular, when I want to access a jstor item, I change the url prefix to "https://www-jstor-org.wikipedialibrary.idm.oclc" ... Am I doing this right? Fabrickator (talk) 19:14, 7 June 2025 (UTC)
Yes. You can also use an extension like Zotero to automatically send you to the proxy URL. ARandomName123 (talk)Ping me! 19:42, 7 June 2025 (UTC)
Maybe reminding people that they have access wouldn't hurt. Sean.hoyland (talk) 18:04, 8 June 2025 (UTC)
I wonder whether a link to the library could appear somewhere in the skin (e.g. under Tools or some such) for those with access? Cheers, SunloungerFrog (talk) 18:44, 8 June 2025 (UTC)
@SunloungerFrog, I like this idea. There's CSS code that makes it possible. WhatamIdoing (talk) 04:57, 11 June 2025 (UTC)
Another way to remind people is to tag the articles for notable sources with {{Wikipedia Library}}. See Talk:Holland–Frei Cancer Medicine: If you click the link for "10th edition", it will prompt you to login and then take you straight to the page where you can download chapters of this medical textbook. WhatamIdoing (talk) 04:59, 11 June 2025 (UTC)
Thanks, will be using that Kowal2701 (talk) 05:36, 11 June 2025 (UTC)

Revisiting the recall petitioning period ...

We have thus far had five Administrator Recall petitions closed as successful at WP:CLOSEDARP. The average time from open to close is five days with a high of 11 days and a low of one day (no outliers with an upper fence of 23.5 [Q3 + 1.5 × IQR], though this is a small set). Currently, the maximum possible petitioning period is 30 days. If I recall, this was the subject of some debate during discussion of recall with the idea being tabled that it could be revisited later if it was found to be too long or too short. Is it time to consider abbreviating the petitioning recall period to less of a Twisting in the Wind number (e.g. 20 days, 15 days, one week, etc.)? Chetsford (talk) 17:36, 8 June 2025 (UTC)

I'm not sure that the fact that all recalls so far have been successful comes from the fact that the maximum period is too long, rather than from the fact that people rarely start recalls and only do so in clear-cut cases. The short time between open and close can also be due to discussions at AN or ANI immediately preceding the recalls, and I am not sure which problem shortening the petition duration would solve. Chaotic Enby (talk · contribs) 18:47, 8 June 2025 (UTC)
The problem that needs solving with recalls is that they are happening too quickly. One day (let alone 6 hours) is simply way, way too little time to base a desysopping decision on. And the fact that only one person subject to a recall petition has initiated an RFA means we simply do not have any evidence of whether the community actually did think those editors needed desysopping. We should be slowing the process down, not encouraging it to be quicker. Thryduulf (talk) 19:56, 8 June 2025 (UTC)
There have been petitions for abuse and for inactivity. For the inactivity petitions, it's irrelevant whether they sought the tools again because they already weren't using them. For the abuse petitions, they were preceded by days of discussion, and years of warning before that. It seems that the main objection to recall so far is that people care more about the wellbeing of abusive people than about their victims. Thebiguglyalien (talk) 🛸 20:35, 8 June 2025 (UTC)
No desysopping decision is being made in six hours! All that happened was a petition was opened and closed. It was preceded by days of discussion. The admin has thirty days to decide to initiate an RRFA. I fail to see how this is considered too fast. Hawkeye7 (discuss) 20:43, 8 June 2025 (UTC)
The purpose of the recall petition needing 25 to agree is to ensure we are not wasting the community's time with frivolous petitions. Requiring it to be out longer is going to consume more community time, as the only thing that would make it cancel is if no one else joined and the original petitioners withdrew their own support. — xaosflux Talk 21:05, 8 June 2025 (UTC)
Just in point of clarification, the issue I'm raising is not shortening the period during which an Admin has the opportunity to decide to initiate an RRFA (which is 30 days) but the period in which petitioners have to collect signatures (which is also 30 days). Right now, based on the (admittedly limited) data we have from five successful petitions, 11 days is always sufficient, 10 days is sufficient 4/5 times, and two days is sufficient in a majority of instances. Based on that, I feel like shortening the petitioning period to 15 days would not create an undue burden for petitioners, but would ameliorate the (as of yet unrealized) potential of leaving someone twisting in the wind for several weeks at 12 or 13 signatures. Chetsford (talk) 21:43, 8 June 2025 (UTC)
Ah ok, I'm mostly ok with making the expiration duration 15 instead of 30 days, but this doesn't seem to be an actual problem. — xaosflux Talk 23:50, 8 June 2025 (UTC)
I totally agree, it's definitely not a problem we have experienced. I'm more of the mind that we should preempt future problems where we can identify potentiality instead of waiting for deleterious effects to act. In this case, during the discussion (IIRC) to create a method for recall, there was considerable back-and-forth about the appropriate length for the recall period and concerns about a too-long gap. Now that we have some actual data, it might be appropriate to revisit that. Chetsford (talk) 05:06, 9 June 2025 (UTC)
My initial thought is that I think it would be helpful to have more examples of the process being used before we can figure out if any adjustments to the petition period are desirable. isaacl (talk) 06:37, 9 June 2025 (UTC)
I agree, five examples is less than ideal to institute changes given the fact we (realistically) only have one shot at it. I'm a little uncomfortable potentially subjecting people to an inferior process for purposes of data collection. But maybe, all things considered, tabling this until we get to ten examples would be best. Chetsford (talk) 06:43, 9 June 2025 (UTC)
Personally, I don't feel that continuing to use a community-agreed upon process is just being done to collect data. The reality is that English Wikipedia processes reflect what the community is able to agree upon. There're benefits to maintaining some degree of stability so the community can accommodate a new process. It takes time to learn if those accommodations are a net improvement or not. isaacl (talk) 16:36, 9 June 2025 (UTC)
If we tweak numbers, I would rather increase the minimum number of petitioners. The process is currently very fast and could benefit from being slowed down a little. If recall petitions become normal occurrences, they ought to fail every now and then. —Kusma (talk) 06:06, 9 June 2025 (UTC)
The whole point of a recall is to force the administrator to prove they still have the consensus of the community that they should be an administrator. They can do so by either submitting an RRFA or running in an election (once those are regular) within a certain timeframe. If the administrator wishes to make statements/explain their behavior that led to the recall, they are free to do so at their RRFA. If they don't want to do so, then they shouldn't be an administrator still. Bluntly, I'd support all admins having to go through admin elections (or RRFA) at least every 2 years or so. But that's virtually certainly not going to get consensus, so the current recall system is the best we have to force admins to prove they still have the consensus of the community to be an admin.
Some people may say that it's problematic that 25 random editors can force someone to stand for an RRFA in which there may be many !votes that are spurious or based on a personal vendetta. We already trust the bureaucrats to remove personal vendetta !votes at RFAs - why can we not trust them to do so at RRFAs? RRFA also already has a lower threshold to retain the bits. If an admin is recalled and doesn't think they will pass a RRFA, then why should they keep the bit? There is no problem with a recall being able to take effect with 25 votes in 12 hours (for example). If there are 25 independent extended confirmed editors that think the admin should be forced to prove themselves... then they should be forced to prove themselves. If there are valid explanations to the behavior that led to the recall, then they have 30 whole days to formulate their ideas and post that as their RRFA statement. Plus they can be asked questions by other editors - someone voting for a recall does not necessarily mean that person is going to !vote against them in their RRFA. In other words, a vote to recall is not necessarily a vote against them keeping the bit - it's just a vote that they should have to prove themselves.
This thread started shortly after the Bbb23 recall petition, which I endorsed/voted for (whatever you want to call it). But that doesn't mean that all, or even a majority of us who endorsed the recall, would've !voted against them in a RRFA. Myself, for an example, I'd already come up with the 2 questions I was going to ask Bbb23 at their RRFA if they chose to run. My !vote in their RRFA would've depended on their answer to those two questions I asked (and any other information in their RRFA). I endorsed the recall not because I supported removing their bit, but I supported them having to prove themselves in a RRFA where they would be scrutinized and evaluated (and asked questions) by the whole community.
TLDR: A recall is not forcing anyone to give up their bit. It's just forcing them to prove they still have the consensus of the community to be an admin. They're free to explain themselves in their statement/by answering questions. Whether they choose to do so or not is not anything the community can control. -bɜ:ʳkənhɪmez | me | talk to me! 06:18, 9 June 2025 (UTC)
While there are a lot of interesting thoughts here about the admin recall process, in the interest of not expanding the scope of discussion to cover the motivation for the process, perhaps you might consider trimming back (or collapsing) some of your comments that aren't directly related to changing the maximum petition period? (I appreciate that a certain core portion of your comments is about not requiring a minimum petition period.) isaacl (talk) 06:34, 9 June 2025 (UTC)
I think my comments are directly related to making any changes to the process at all. My whole point is that if 25 extended confirmed editors each think that an admin should have to "prove themselves", then they should have to do that. Personally, I don't see a need for a maximum at all - and as I say, I'd support a more ongoing process where every admin has to every x months/years whether they've been recalled or not. I think my comment as a whole explains why I think no changes are needed at all. -bɜ:ʳkənhɪmez | me | talk to me! 07:00, 9 June 2025 (UTC)
Sure. I just think it's better not to expand this discussion to one where any changes at all are being discussed, which will make it harder to isolate discussion on the specific question that was raised. I appreciate that others may of course like to discuss any changes (something that was being done at Wikipedia talk:Administrator recall/January 2025 request for comment). I feel that the broader scope is significantly expansive to warrant a separate thread. isaacl (talk) 16:23, 9 June 2025 (UTC)
It seems prudent to link to the last RFC about this topic. Re "(as of yet unrealized) potential of leaving someone twisting in the wind for several weeks at 12 or 13 signatures", well, that may well have happened in my case if I'd been much more careful in my dealings at the time, but alas, it didn't ... Graham87 (talk) 05:05, 10 June 2025 (UTC)
I think we can make a number of tweaks to the process based on these first 5 recalls. First, I think we can shorten the petition signature period up to 14 days. We have evidence that recalls with legs can get there speedily, and the contrary case of a genuinely bad recall that only attracts a few supporters would have real benefit from a speedier wrap-up. Secondly, I think we can increase the number of signatures required, albeit I want to be careful here. 4 out of the 5 times this process was used, it was not simply to check that the request wasn't a waste of the community's time, but rather was the de facto desysop process. Finally, I think that we can remove the 30 day deadline on running the RRFA under the RRFA thresholds/standing in an admin election under the lower threshold. We should still reclaim the bit after 30 days, but the recallee should have the opportunity to demonstrate changes and the ability to choose a lower pressure election method. Any of these changes should be positive in any combination. Tazerdadog (talk) 08:46, 10 June 2025 (UTC)
At risk of getting too far afield, I support all three of these modifications. Though, if they were advanced for consideration, I'd prefer they be offered individually and not part of a package deal. Chetsford (talk) 18:04, 10 June 2025 (UTC)
Yeah, individual questions is 100% the proper way to structure the RFC. I'm just trying to float a few ideas and hoping some of them will be good and sticky. Tazerdadog (talk) 18:03, 11 June 2025 (UTC)
That's what an RRFA is for. They have 30 days to demonstrate how they can continue to constructively be an admin (and by my reading, they could keep the bit for duration of the RRFA, even if they start it at 29 days 23 hours and 59 minutes after the recall was certified). Who decides whether the recalled admin "demonstrate[d] changes" if not an RRFA? Furthermore, why should it be "lower pressure"? That invokes a Super Mario mushroom effect by saying "to get the bit, you have to demonstrate the trust of the community, but there's no pressure on you to actually keep that trust to keep the bit". In other words, it's designed to be pressure, if for no other reason than to ensure that the administrator demonstrates they still have the trust of the community to remain an admin. The RRFA (or admin election) allows the community to ask questions in a set environment, and see the answers/opinions of the admin (in their opening statement and answers to questions) before deciding whether to support them retaining the bit or not. -bɜ:ʳkənhɪmez | me | talk to me! 03:19, 11 June 2025 (UTC)
Berk, when you say They have 30 days to demonstrate how they can continue to constructively be an admin, I think you're talking about a different part of the process. The part under discussion is "The filer has 30 days to find 24 other people who want to vote the admin out".
So let's change the context. Imagine that tomorrow, I'm going to start a discussion about whether you should be indeffed.
Now, you probably know that the typical Wikipedia:Administrators' noticeboard/Incidents or Wikipedia:Arbitration/Requests/Enforcement discussion gets wrapped up in a few days, at the most. You probably also know that flimsy cases get wrapped up even faster. But that's irrelevant, because I'm invoking a special rule that says this 'discussion' goes on for 30 days. Oh, and only people who want to kick you out are allowed to have any say in the 'discussion'. The 'discussion' will be heavily advertised. Even if you have actually done nothing wrong, people will be watching every move you make – or don't make – for the next 30 days, and anyone who disagrees with anything you do for the next 30 days can vote you off the island. People who like what you're doing don't get to say anything at this stage; this 'discussion' is only for people who want to complain about you.
The question here is: Do you want to me to have 30 days to find editors who are willing to vote against you? Do you want to spend the next 30 days second-guessing whether reverting or disagreeing with an experienced editor will result in that editor voting against you? Or would you find that needlessly stressful, especially if my attempt to get you punished never goes anywhere?
If I had a good case lined up, I'm confident that I could pre-arrange to have 25 people ready and waiting to sign the petition on the first day. Even with a weaker case, I'm pretty sure that I could a handful lined up in advance; after all, most long-time editors have accumulated a few 'wiki-enemies'.
AFD lasts for a week (it used to be five days). Perhaps RRFA should be similarly short, with a recommendation that the filer not actually start a petition until they're certain that other editors will join in. WhatamIdoing (talk) 05:20, 11 June 2025 (UTC)
The main difference here is that the recall petition is not the "discussion" about whether someone should be indeffed. It is not voting the admin out. It is only a thresholding mechanism to start an actual vote – the RRfA. Admins have a choice on whether to RRfA, but the fact that some chose not to run doesn't make the recall petition any more binding as a discussion. Chaotic Enby (talk · contribs) 05:25, 11 June 2025 (UTC)
I'm saying:
  • Alice is the subject of an RRFA, spends 30 days wondering what will happen, but only 12 people sign the petition, and nobody signed it after the first week, so the answer is 'nothing'. That was 23 unnecessary days of stress for what purpose, exactly?
You seem to be saying:
  • Bob is the subject of an RRFA, and 25 people vote to recall him. He decides not to undergo RFA again at this time, because his personal life won't allow him to spend a week working the RFA process, so he is desysopped. But that's not "binding"? I doubt that the person pushing the desysop buttons would tell you that it was strictly optional and they could have chosen to ignore the results of the recall petition, because those 25 votes aren't "binding".
WhatamIdoing (talk) 05:38, 11 June 2025 (UTC)

He decides not to undergo RFA again at this time, because his personal life won't allow him to spend a week working the RFA process, so he is desysopped. But that's not "binding"?

This is exactly the reason why Bob has a 30 day window to begin a RRfA, so it can be planned around real-life schedules. There is a difference between being "strictly optional" and being non-binding: the admin can't fully ignore the results of the petition, but, if it is not based on actual problems with the admin's conduct, it won't be binding in the sense that the following RRfA can still reconfirm the admin even with minimal effort on their part. Chaotic Enby (talk · contribs) 06:50, 11 June 2025 (UTC)
My point is that this isn't the recall process - it's one part of it. Admins who continue to maintain the trust of the community shouldn't have a problem running a RRFA or an election if 25 editors think they should have to. As I said, I would support periodic re-RFA requirements anyway, but I know that's not going to gain consensus. There has been no issue shown with the current method other than "well it may make some people have to run an RFA just because 25 people said they should have to" - which is not a good enough reason if you ask me. -bɜ:ʳkənhɪmez | me | talk to me! 05:28, 11 June 2025 (UTC)
Yes, but that "one part" lasts for 30 days, if 25 editors don't sign up before then. Maybe that "one part" could be shorter than that. WhatamIdoing (talk) 05:33, 11 June 2025 (UTC)
I can't see a reason that it should be shortened. If 25 EC editors in good standing think within a month that a given administrator should have to "re-prove themselves", then there's no harm in requiring them to do so. If the administrator still maintains the trust of the community, they will have no problem whipping up a quick statement and answers to questions at an RRFA or election happening soon. Concerns about how "easy" it would be to recall an administrator were more than resolved (in my view) by the lower requirements for passing RRFA or being elected.
And to your point above, I could support an admin being able to be given an extension if they request one from the bureaucrats, even retroactively if they can't request during the 30 days - within reason, of course. But if they aren't active enough to respond to an RRFA or election questions during that 30 day allowance, there is very little harm potential from removing the bit from them until they return and can do so. -bɜ:ʳkənhɪmez | me | talk to me! 05:45, 11 June 2025 (UTC)
It's untrue that the discussion is only for people who want to complain about you. To the extent there has been discussion (and usually there is comprehensive discussion elsewhere), non-supporters have participated. CMD (talk) 07:01, 11 June 2025 (UTC)
While non-supporters have participated, their comments are completely irrelevant. If there are 25 supporters it doesn't matter whether there are no non-supporters or 200 non-supporters, the petition still passes and the administrator has to either resign or face a week of hell. Only if they choose the latter option is there any way to know what the actual community consensus is, especially when the petition phase lasts only a few hours. Thryduulf (talk) 10:32, 11 June 2025 (UTC)
I'm not sure what this reply is for. I pointed out a statement is untrue, you seem to agree? The rest of that is the intended process, it is to avoid a frivolous "week of hell". CMD (talk) 13:47, 11 June 2025 (UTC)
While I completely understand where you are coming from, I don't think it would be "a week of hell" if there were 200 non-supporters to 25 supporters in the petition itself, especially with the much lowered threshold at RRfA. There is no reason for a RRfA to be painful if there is overwhelming opposition to the premise behind the recall, although we haven't seen that case yet. Chaotic Enby (talk · contribs) 11:03, 11 June 2025 (UTC)
That's a good theory, but unless and until there is actual evidence of a re-RFA being something other than a week of hell, choosing between that and resignation is the choice that recalled administrators are actually making in practice. They already know that there are at least 25 editors who believe they should be desysopped, at least some of whom will be keen to point out all their flaws and misdeeds again. Thryduulf (talk) 11:08, 11 June 2025 (UTC)
To be fair, we also haven't seen the case you describe where the vast majority of editors explicitly refuse to support the recall petition. It feels like, without any clear data points for admins recalled despite a clear majority opposing the petition, we can't really say anything with concrete evidence either way. Chaotic Enby (talk · contribs) 11:13, 11 June 2025 (UTC)
Indeed, we have exactly one datapoint about whether recall is leading to the correct outcomes (Graham87). Every other recalled administrator has chosen to leave the project - regardless of whether they should or should not have remained as an administrator this is not a good thing. Even discounting the pointlessness of explicitly not supporting a petition, in at least two cases the petition was certified so quickly that most people who would have commented (either way) were likely not aware that it was even happening.
What I'm primarily pushing back against are the claims that recall is working - admins leaving the project because 25 people don't like them being admins, with no opportunity for other opinions to be registered, it is very clearly not. Thryduulf (talk) 11:28, 11 June 2025 (UTC)
No admins have left the project: 4 editors have left the project because they had lost their admin status through a community-approved process. And "25 people don't like them being admins": it seems highly uniikely that only 25 people thought they shouldn't be admins any longer, the rapid influx of such opinions by a wide variety of editors was a clear indication that many others would have certified as well if the threshold hadn't already been met. What isn't a good thing is that people are so attached to their admin status that they don't want to remain part of enwiki when that status is removed. This isn't solved by refactoring the recall process though. Fram (talk) 11:46, 11 June 2025 (UTC)
Wikipedia is supposed to work on consensus. Your (or my) theories about how many people would or would not certify and/or support or oppose an RFA are entirely meaningless.
What isn't a good thing is that people are so attached to their admin status that they don't want to remain part of enwiki when that status is removed. That's one theory as to why they chose to leave. Another theory is that a few vocal editors made them feel so unwelcome that they chose to leave rather than subject themself to more of the same. Both theories are equally supported by the available evidence. Thryduulf (talk) 11:52, 11 June 2025 (UTC)
Any reason why you would consider your theories meaningless yet important enough to post here? Fram (talk) 12:07, 11 June 2025 (UTC)
I do not consider my theory any more or less meaningless than your theory, which you present as if it were both factual and meaningful. Thryduulf (talk) 13:21, 11 June 2025 (UTC)
Even discounting the pointlessness of explicitly not supporting a petition
I actually don't think it is pointless – even if they don't count as votes (which makes sense as the petition would, in an ideal world, only be a thresholding mechanism), they provide reassurance to the admin being subject to the recall, and could convince them that a RRfA wouldn't be as painful. Again, purely theorizing, but encouraging this mechanism for informal discussion could make admins feel more confident to go to a (formal) RRfA afterwards. Chaotic Enby (talk · contribs) 11:47, 11 June 2025 (UTC)
I guess the question is whether recall in its current form is better or worse than the old pitchforks and torchesWP:RFC/U (see for example Wikipedia:Requests for comment/Kelly Martin and its subpages if you want to delve into Wikipedia history). —Kusma (talk) 12:18, 11 June 2025 (UTC)

There doesn't seem to be a problem that needs to be solved. Process works as designed, and so far none of the results have been shown to be problematic. Fram (talk) 10:43, 11 June 2025 (UTC)

Only one of the results has been shown to be anything. Thryduulf (talk) 10:53, 11 June 2025 (UTC)
A good thing we don't do recalls so far for consistently making meaningless or false statements I guess? Fram (talk) 11:40, 11 June 2025 (UTC)
What is incorrect or meaningless about my statement? Thryduulf (talk) 11:48, 11 June 2025 (UTC)
And then four minutes later, in this same discussion, you write "Your (or my) theories about how many people would or would not certify and/or support or oppose an RFA are entirely meaningless." Anyway, if people want to solve a problem, they first have to show that there is a problem. Replying that only one has been shown to be correct (in your opinion) is meaningless as a reply to that statement. Fram (talk) 12:12, 11 June 2025 (UTC)
Thank you for explaining how you have misinterpreted my words to suit your point of view. We do not know that "the process has worked as designed" and it is decidedly the opposite of meaningless to point out that statements that you present as incontrovertible fact are actually nothing of the sort and are exactly as supported by the evidence as the exact opposite. Thryduulf (talk) 13:24, 11 June 2025 (UTC)
Your reply was obviously to "none of the results have been shown to be problematic", not to "process works as designed". IF I say "A and B", you reply with "not B", then don't expect people to read that as "not A". As usual, no point having a prolonged discussion with you. If 1 out of 5 has been shown to be correct, and 0 out of 5 have been shown to be incorrect, then "exactly as supported by the evidence as the exact opposite." is obviously false as well. See also the above, where you call your own theory "entirely meaningless" but see no harm in spouting it anyway. Fram (talk) 14:03, 11 June 2025 (UTC)

Should there be some sort of policy to state that transgender people are transgender?

It can be confusing in some contexts to read an article that doesn't mention at all the fact that someone is transgender. I think there should be some sort of guideline to make it clear. Pxldnky77 (talk) 09:02, 9 June 2025 (UTC)

Can you give an example where this causes confusion? ClaudineChionh (she/her · talk · email · global) 09:11, 9 June 2025 (UTC)
I guess "confusing" wasn't all encompassing. Being transgender is an important piece of information, along with things like age and hometown. It's something that the reader of a person's Wikipedia article should know about the person. You shouldn't have to look up "Is this person transgender" outside of Wikipedia in order to figure that out. I know most articles on transgender people include that information in one way or another but it might be helpful to have it as a standard in the infobox or something. Pxldnky77 (talk) 09:27, 9 June 2025 (UTC)
What are you proposing to do that is not covered by MOS:GENDERID? 331dot (talk) 09:38, 9 June 2025 (UTC)
That probably covers any concerns I had on the topic. I'm fairly new to editing and Wikipedia manages to be a step ahead in any improvements I can think of. Thank you for the guidance. Pxldnky77 (talk) 09:43, 9 June 2025 (UTC)
Like other personal attributes this is often relevant but not always, so I do not think it should be in policy. Phil Bridger (talk) 10:23, 9 June 2025 (UTC)
See WP:DEADNAME - We respect the gender identity that is stated by an individual, and unless they or extremely high quality RSes have noted themselves as being transgender, we do not include that fact. Masem (t) 12:04, 9 June 2025 (UTC)
Also, it might be a personal privacy (and even safety) aspect if the person is not out as transgender, or wants to keep a low profile about it for various reasons. Chaotic Enby (talk · contribs) 12:25, 9 June 2025 (UTC)
Exactly. I know of one case of a transgender person where editors were improperly using court documents to affirm that (this was back during Gamergate so you can probably guess why they wanted to show that), which is why if are going to be including if someone is transgender, it needs to be a self-statement, or something well and clearly documented in high quality RSes appropriate for a BLP. Masem (t) 12:33, 9 June 2025 (UTC)
Don't most articles on people publically known to be trans have one or more categories indicating this? It isn't that hard to scroll to the bottom of the page. --User:Khajidha (talk) (contributions) 13:01, 9 June 2025 (UTC)
WP:PEOPLECAT doesn't have something about trans people specifically, but, as per the general guidelines, they would only be categorized that way if being trans was a defining part of their notability. Chaotic Enby (talk · contribs) 13:43, 9 June 2025 (UTC)
Category:Transgender people (and subcats) exists and is probably used a little more often than PEOPLECAT would recommend. We also have Category:Transgender rights activists, which would be expected to include trans and cis people who are activists for trans rights.
I don't think categories are displayed on the mobile site. WhatamIdoing (talk) 05:30, 11 June 2025 (UTC)
Didn't know that was a thing, thanks. Is there a reason for that exception in policy? Chaotic Enby (talk · contribs) 07:13, 11 June 2025 (UTC)
(This reply assumes that the existence of Category:Transgender people is the "exception in policy".)
I find that there are two main approaches to cats, roughly minimalist and maximalist. The difference is most obvious in large articles, especially large articles about BLPs. Michelle Obama is my usual example. There are 52 cats on that page right now.
The extreme minimalists say "We should only have cats if they're Wikipedia:Defining. Michelle Obama's defining characteristics are that she was the first Black woman married to a US president. Oh, and because we'll generously compromise, you can add the cat for the year she was born and Category:Harvard Law School alumni."
The maximalists (who have clearly won that article, BTW) say "Let's add a category for everything we associate her with. But we, too, can generously compromise: We'll limit it to the top fifty or so categories."
I suspect that the latter approach is guided by the notion of cats as being similar to lists. The point, therefore, isn't that Obama's old law firm is super important to her reason for being notable; the point is that Category:People associated with Sidley Austin itself would be incomplete if her name wasn't listed there. WhatamIdoing (talk) 20:30, 11 June 2025 (UTC)

Turn WP:ClosingDiscussions into a guideline

It's been recently pointed out once again that Wikipedia:Closing discussions is an information page. However, it effectively commands the respect of a guideline already. And unlike e.g. BRD, I can't see a reason why this shouldn't be a guideline. The talk page archive seems to imply it was a guideline proposal that went stale. What do we think? Aaron Liu (talk) 03:15, 11 June 2025 (UTC)

Aaron, I think you should read WP:PROPOSAL. WhatamIdoing (talk) 05:32, 11 June 2025 (UTC)
Yeah, I've read that. I'm wondering if there's any reason we shouldn't start this process for this information page. Aaron Liu (talk) 16:04, 11 June 2025 (UTC)
Offhandedly I could see objections arising because it's not worth the bother, though admittedly that line of thinking ends up proving too much. Another concern is that sometimes informal norms can be better when the community disagrees on specifics of implementation, and yes I'm aware of the counterarguments to that line of reasoning as well.
As to the question to whether it really documents accepted community practice, on a first read it seems fine, but I'm largely inactive these years so it's possible there are shifts I've missed. 184.152.65.118 (talk) 01:45, 12 June 2025 (UTC)
Thanks. Aaron Liu (talk) 10:59, 12 June 2025 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(idea_lab)/Archive_67&oldid=1296857074"