Wikipedia:Village pump (policy)

"WP:VPP" redirects here. For proposals, see Wikipedia:Village pump (proposals).

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

The policy section of the village pump is used to discuss already proposed policies and guidelines and to discuss changes to existing policies and guidelines.

• If you want to propose something new that is not a policy or guideline, use Village pump (proposals).
• If you have a question about how to apply an existing policy or guideline, try one of the many Wikipedia:Noticeboards.
• If you want to ask what the policy is on something, try the Help desk or the Teahouse.
• This is not the place to resolve disputes over how a policy should be implemented. Please see Wikipedia:Dispute resolution for how to proceed in such cases.
• If you want to propose a new or amended speedy deletion criterion, use Wikipedia talk:Criteria for speedy deletion.

Please see this FAQ page for a list of frequently rejected or ignored proposals. Discussions are automatically archived after remaining inactive for two weeks.

« Archives, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192

Request for Comment: Should editing on Wikipedia be limited to accounts only?

Should editing on Wikipedia be limited to accounts only? - jc37 15:04, 18 May 2023 (UTC)

Introductory information

Times have changed.

Technology has changed.

Online privacy laws have been created in some locales.

IP addresses have new/additional types.

And we also know more about IP addresses' usage than we did when Wikipedia was founded.

So there are some questions:

a.) With all the ways that it is just simply difficult to track by an IP address

b.) With VPN, proxies, and other such ways to mask

c.) With how there are now privacy concerns related to IP addresses

Is it time for us to just say "If you want to edit Wikipedia, please create an account".

We would still be the free encyclopedia that anyone can edit.

And as far as I know, accounts are free, and do not require any personal information.

2 other things to note:

a.) editing from an account, rather than an IP (which could be a dynamic IP) makes discussion amongst editors easier.

b.) While patrollers may spend a lot of time is spent addressing IP edits, I would imagine that that would only somewhat change, as a vandal could just create a new account instead. However, I think we'd see a small decrease in vandalism, because I think we might see fewer "impulsive" acts.

So with all that (and I'm sure, far more that others may think of) in mind, Do you think we should deprecate IP editing on Wikipedia?

I am not adding "support/oppose" sections, because this is not a vote. I think it's fair to say that this topic deserves a thoughtful discussion.

A few pages possibly worth reading in relation to this:

• Wikipedia:IP users
• Wikipedia:Personal security practices
• Wikipedia:Open proxies
• m:No open proxies
• m:IP Editing: Privacy Enhancement and Abuse Mitigation
• m:IP Editing: Privacy Enhancement and Abuse Mitigation/IP Editing Restriction Study

- jc37 15:04, 18 May 2023 (UTC)

Discussion (requiring an account to edit)

• Editing? No. Giving article feedback, asking for technical help, etc - I'm not really seeing any reason this is a problem. I might consider "editing articles" IF enough problems could be identified. — xaosflux ^Talk 15:47, 18 May 2023 (UTC)

  Well, namespaces are numbered. the talk pages of each are odd-numbered. What would you think of limiting IP editing to the odd-numbered namespaces? - jc37 15:54, 18 May 2023 (UTC)

• If the answer is "IPs should not be able to edit" it's not clear what changes and so I don't think this ready to actually be an RfC. This feels like a precursor discussion to that RfC. Barkeep49 (talk) 15:48, 18 May 2023 (UTC)

  I'm not concerned If this ends up being a brainstorming RfC which leads to a "next step" RfC. - jc37 15:54, 18 May 2023 (UTC)

  Then I would suggest we remove the RfC tag and just let this be a policy pump discussion. We definitely should remove it from CENT (and not watchlist notice it which I'd want to do for any serious proposal). Best, Barkeep49 (talk) 15:56, 18 May 2023 (UTC)

  An RfC is an RfC. I think we can let the discussion go where ever it goes. - jc37 15:58, 18 May 2023 (UTC)

• Someone proposing to ban IPs from editing? Is it Thursday already? Seriously, can we not do this yet again. --Jayron32 15:50, 18 May 2023 (UTC)

  I think we (and the world) are in a different place on this. I think it's fair to say that wikipedia editors are not merely desktop users anymore, for one thing. Also. see some things that meta is working on concerning IP masking. I think that this topic is timely and is something we should probably discuss. - jc37 15:57, 18 May 2023 (UTC)

  I'm not aware of any serious discussion of this since ptwiki did it and there's been real research from their results. I'm also not aware of any real discussion since IP masking became something that could happen at any moment. Best, Barkeep49 (talk) 15:58, 18 May 2023 (UTC)

  I guess you're right, the last serious discussion I found on the matter was two years ago here. Still, I think it's not a good idea. We still have lots of good editing happening from IP editors, and I haven't seen a good argument that anything has changed. I see assertions that it's different now. But an assertion without evidence can be dismissed without evidence. Are IP editors really no longer making any good contributions to Wikipedia? --Jayron32 16:12, 18 May 2023 (UTC)

  I don't have links on hand, but there have been more recent discussions about IP editing within conversations about the proposed IP masking initiative, which appears to be moving forward at a slow but steady pace. (I suspect we will see more discussion when a substantial update to that comes forward, but with that in mind it's a bit difficult to have the full IP editing discussion until we have more details on how IP masking will work.) CMD (talk) 16:25, 18 May 2023 (UTC)

  Do we have evidence that those good edits from IP editors would not have happened if the editors had been forced to create an account? Account creation is pretty low friction. Seems like it would be a minor speed bump that might cause a portion of prospective editors to walk away, but surely not all of them. Barnards.tar.gz (talk) 16:30, 18 May 2023 (UTC)

  Evidence is needed to enact a change to things, if it ain't broke, don't fix it. No one has shown that it's broke. Demanding that we change a major policy merely because evidence doesn't exist not to change it is nonsensical. --Jayron32 16:39, 18 May 2023 (UTC)

  Well, the ptwiki experiment certainly seems to be evidence that requiring account creation reduced vandalism while not materially reducing edits. Barnards.tar.gz (talk) 16:45, 18 May 2023 (UTC)

  An experiment is not evidence by itself. Is there actual data about the result? ~ ToBeFree (talk) 17:04, 18 May 2023 (UTC)

  @ToBeFree There's a report by the WMF anti-harassment team here: Meta:IP Editing: Privacy Enhancement and Abuse Mitigation/IP Editing Restriction Study/Portuguese Wikipedia. 192.76.8.85 (talk) 17:19, 18 May 2023 (UTC)

  Ah perfect, I had looked for a page like this. Perhaps I had even seen that one in the past but forgotten about it. That, and the below-linked meta:IP Editing: Privacy Enhancement and Abuse Mitigation/IP Editing Restriction Study/Farsi Wikipedia are two pages we should definitely closely look at before making a decision. ~ ToBeFree (talk) 17:33, 18 May 2023 (UTC)

• This RFC should be deferred until the imminent deployment of IP masking. MER-C 16:01, 18 May 2023 (UTC)

  Normally I would write off a proposal to block IP editing as another perennial proposal with little chance of succeeding, but the imminent deployment of IP masking is probably the most compelling reason to talk about this now. Thebiguglyalien (talk) 16:13, 18 May 2023 (UTC)

  Would IP masking mean that IP editors would change the nature of IP contributions? Which is to say, once IP masking goes live, what about the contributions of those editors who contribute without an account would change? If John Doe, who edits without an account, was providing high-quality work to Wikipedia, why would he suddenly not be doing that once IP masking goes live? --Jayron32 16:20, 18 May 2023 (UTC)

  Some IP editors – in particular the ones that edit from a single static IP address as a long-term joke/to make a point – do prefer to have a user page and/or talk page that is identifiable, like 199.208.172.35 (AKA Tarlonniel) and 76.117.247.55. It's unknown whether these sorts of IPs would leave the project or make an account (or if they give up on being identifiable and keep editing, we probably would never know!). Of course, IPs like 64.229.90.172 (whom I call "Movie Soundtrack IP"), who edit simply because they don't want another password to remember, would probably stick around. Snowmanonahoe (talk · contribs · typos) 17:03, 18 May 2023 (UTC)

  (This is the Tarlonniel mentioned above) For what it's worth, IP masking is not going to make me leave the project (or create an account) - it might actually be helpful to combat the problem of telling me apart from others using this IP (there's at least one other person who semi-actively edits Wikipedia from "here"). Of course, banning IP editing would be a big "Exit!" sign for me. 199.208.172.35 (talk) 17:16, 18 May 2023 (UTC)

  If you don't mind me asking, why is that? - jc37 17:25, 18 May 2023 (UTC)

  Because I greatly prefer editing as an IP, @Jc37 (see the FAQ on "my" talk page for links to further opinionated blathering), as do other long-term IP editors I've encountered. I can't say what they'd do if IP editing was restricted - you'd have to ask them yourself - but for me it would be a signal that, in spite of all I've tried to do in the realm of positive contributions, Wikipedia has decided to move in a direction I can't agree with, and that I should concentrate on one of my other hobbies. Or, y'know, my actual job. 199.208.172.35 (talk) 17:40, 18 May 2023 (UTC)

  I did look at that before asking and saw it seemed to essentially be a matter of preference. Thank you for clarifying. - jc37 17:45, 18 May 2023 (UTC)

  I agree. IP editing is still a net positive, and we should encourage it, especially if it inspires many IP editors to register later (as I did). We should revisit the question if and when we see the effects of IP masking. Certes (talk) 17:51, 20 May 2023 (UTC)

  Looking at what IP masking would be doing, I think it will greatly affect how my contributions are recorded, as it is kept in a cookie. As I use multiple browsers and multiple OSes, that would each have a separate identity under this scheme. I also tend to delete all my cookies every so often, which would reset the identity much more often than how long my dynamic IP address now seems to last on average (though Wikipedia crashing Chrome/Chromium-based browsers by using up all the available memory on the system (sometimes crashing the entire system instead of just the browser) and sometimes taking out all the cookies doesn't help matters). -- 64.229.90.172 (talk) 05:38, 21 May 2023 (UTC)

  or hide IP addresses. Cwater1 (talk) 20:33, 5 June 2023 (UTC)

• Jc37, you mention Tor above. When you wrote this, were you aware that editing using Tor is prevented by mw:Extension:TorBlock? ~ ToBeFree (talk) 16:59, 18 May 2023 (UTC)

  I wasn't aware of that extension. And to be honest, I was relying my my memory of the past. But, while creating this RfC, I discovered that m:Editing with Tor was marked historical, and points to m:No open proxies, which I linked to at the top. Interestingly, that page says "may block". Not "will block". And also states that some are temporarily blocked (dynamic IPs being a thing). And of course there's WP:IP block exempt and m:IP block exempt, as well. - jc37 17:09, 18 May 2023 (UTC)

  Okay; seeing it there made me worried about a potential lack of research done before starting a huge RfC. Regarding exemptions, sure, these exist for specific trusted users yet shouldn't have an effect on the discussion. ~ ToBeFree (talk) 17:28, 18 May 2023 (UTC)

  I changed the word to "proxies". Hopefully that will help prevent further confusion. My apologies. - jc37 17:49, 18 May 2023 (UTC)

• Can we get some data/discussion on how this change has gone for Portuguese Wikipedia? {{u|Sdkb}} ^talk 17:07, 18 May 2023 (UTC)

  Meta:IP Editing: Privacy Enhancement and Abuse Mitigation/IP Editing Restriction Study Snowmanonahoe (talk · contribs · typos) 17:11, 18 May 2023 (UTC)

  I just read that page, and it's interesting. One thing that jumps out at me is that they said vandalism was reduced. And that there was also a slight reduction of total new edits. But it doesn't seem to say if the reduction of vandalism edits was taken into account when talking about the reductoin of total edits. If the loss of total edits was (mostly) vandalism edits, I think that's worth knowing. - jc37 17:23, 18 May 2023 (UTC)

  @Jc37 Did you read the more detailed reports on the individual projects? They go into this somewhat:

  • Meta:IP Editing: Privacy Enhancement and Abuse Mitigation/IP Editing Restriction Study/Portuguese Wikipedia
  • Meta:IP Editing: Privacy Enhancement and Abuse Mitigation/IP Editing Restriction Study/Farsi Wikipedia

  192.76.8.85 (talk) 17:29, 18 May 2023 (UTC)

  Thank you. #Net_non-reverted_edits would seem to suggest an overall increase in non-reverted contributions. - jc37 17:42, 18 May 2023 (UTC)

• I've notified 2 active IP editors of this discussion. I'm aware this violates the letter of the votestacking policy, but I think it's fine because IP editors tend to not be as interested in our "meta"-discussions, and their input is obviously important. Snowmanonahoe (talk · contribs · typos) 17:09, 18 May 2023 (UTC)

  My very unhelpful input is that y'all should do what you gotta do to protect the project. I don't have any illusions that Wikipedia won't survive without me (and any idealistic fellow IP editors who might join me in leaving). 199.208.172.35 (talk) 18:01, 18 May 2023 (UTC)

  Thank you for the heads up - 64.229.90.172 (talk) 05:11, 21 May 2023 (UTC)

• Everyday, along with normal browsing, I use private browsing and/or tor/VPN. I switched to a new ISP all almost an year ago (dynamic IP addresses). In that year, I never saw "edit" option. All the IP addresses/ranges were blocked. I'm not sure how many IP addresses/ranges can actually edit. —usernamekiran (talk) 17:18, 18 May 2023 (UTC)

  Most can. The IP addresses assigned to a single ISP are likely an inconsequential fraction of the entire IP space. --Jayron32 18:11, 18 May 2023 (UTC)

  We have constant ip edits. — xaosflux ^Talk 18:15, 18 May 2023 (UTC)

  yes. But I was wondering about how many were blocked for various reasons. —usernamekiran (talk) 19:06, 18 May 2023 (UTC)

  I believe most of it is done by Special:Log/block/ST47ProxyBot. Snowmanonahoe (talk · contribs · typos) 19:08, 18 May 2023 (UTC)

  It greatly depends on country. In some, particularly in the developing world, a majority of IP ranges are blocked. In others, you're only likely to run into a rangeblock if your carrier happens to allocate IPs in a particularly confusing way. (For instance, my IP range on T-Mobile has more people on it than the population of most countries, and is blocked as a result.) -- Tamzin^{[cetacean needed]} (she|they|xe) 19:15, 18 May 2023 (UTC)

• I would tentatively support proposals to restrict IP editing in certain ways—throttling to an edit or two a minute, much more aggressive filtering of potential vandalism, more liberal use of semi-protection—but I don't see any basis to leap to the nuclear option of disabling IP editing entirely. IP editing is how I learned to edit, and how many constructive contributors did as well. ;) -- Tamzin^{[cetacean needed]} (she|they|xe) 19:09, 18 May 2023 (UTC)

  Throttling is an interesting option. Edit filters also allow automatic blocking which we have disabled, but we could enable it for IPs and autoblock IPs who run afoul of our low-false-positive, antivandalism edit filters. — Wug·a·po·des 21:18, 19 May 2023 (UTC)

  I already run afoul of those and need to file false positive reports (such as for a buggy filter, which I've done before), or edit requests for some editor with higher status who can avoid the edit filter. If I get autoblocked on top of that I think I'll just stop contributing to Wikipedia, instead of needing to file a request for unblocking every time a disallow filter is activated, and my editing privileges are withdrawn because a filter was tripped. Would you be suggesting 24-hour blocks or elevating automatic blocks, successively lengthy blocks on the same IP over the course of a year?

  As for the suggestion of only 1 edit per minute, that would mean no person could go back and correct typos they didn't notice before, and would result in a higher rate of reversions, since some patrollers revert any edit that isn't completely correct, likely sometimes with a user-warning attached, as the editor wouldn't be able to correct anything waiting for the timer to expire. It would also mean one couldn't separate edits by content, so one would need to do a massive edit to a full page, instead of individual edits to each section needing a change and what reason that was changed. Then everything would be gone with a revert as someone objected to a single sentence change and not the rest of the edit. (though that already happens with full rollbacks over the objection to a single sentence change but not other edits; as rollback seems to be default over revert for some patrollers) -- 64.229.90.172 (talk) 05:26, 21 May 2023 (UTC)

  The community has consistently rejected automatic blocking, and with good reason. Users who repeatedly trip filters are already automatically reported to AIV. 74.73.224.126 (talk) 02:21, 5 June 2023 (UTC)

• I concur with those above that this should absolutely have been workshopped better prior to running. It would be one of the most drastic RfCs we've ever run and being a reasonable question to raise needs the best pre-consideration possible. Nosebagbear (talk) 21:09, 18 May 2023 (UTC)
• Personally, I don't care whether this discussion crosses all the Ts and dots all the Is for a "proper" RfC. I'm happy just to discuss this issue in a workshop-y sort of way. Long ago, I used the userbox that says that account registration should be required for editing. But over time, I've come to appreciate that IP edits can be a good thing. I agree with the comments above, that it would be useful to examine data from the Portuguese WP. My recollection is that it worked out surprisingly well, but my recollection could be faulty. And I also think that we should be significantly guided by whether IP masking is a decision that is going to be made for us. --Tryptofish (talk) 21:49, 18 May 2023 (UTC)

  See the October 2020 announcement at m:IP masking#Statements from the Wikimedia Foundation Legal department. That decision was made a couple of years ago.

  Realistically, IP masking will start at this wiki some time next calendar year. I'm talking to the AHT team about how to make it as smooth as possible, but I'm sure there will be some bumps on this road. However, we have no real choice here. This has to happen whethe we like it or not. Whatamidoing (WMF) (talk) 23:49, 19 May 2023 (UTC)

  It doesn't have to happen, WMF just wants it to happen. -- Rockstone^{Send me a message!} 21:53, 25 May 2023 (UTC)

  The new facility offered to vandals (deleting their cookies and continuing as a new user) will probably force Wikipedia to abandon its core feature of being the encyclopedia anyone can edit. I'm not sure whether the WMF is gambling on that not happening, or sees it as less bad than storing IP addresses. Certes (talk) 22:05, 25 May 2023 (UTC)

  I really think the WMF is just trying to justify their budgets by making unnecessary changes, but that's the cynic in me. I just haven't seen (and WMF has not provided) any explanation for why this unwelcome change is needed. -- Rockstone^{Send me a message!} 22:19, 25 May 2023 (UTC)

  IP addresses can be regarded as personally identifiable information, though knowing that someone edits from 123.45.67.89 doesn't immediately reveal that it's John Smith of Kalamazoo. The WMF has decided that Wikipedia will prioritise privacy and suffer the collateral damage to vandal fighting and accessibility of editing. Certes (talk) 22:42, 25 May 2023 (UTC)

  @Rockstone35, have you read the October 2020 statement from Legal yet? Look for the words "Please understand that sometimes, as lawyers, we can’t publicly share all of the details of our thinking" – you'll have to un-collapse the section to see them. Whatamidoing (WMF) (talk) 03:30, 1 June 2023 (UTC)

  Whatamidoing (WMF) - I have, but I'm still skeptical that there's a valid reason for this since WMF won't explain their thinking... maybe I'm just cynical. -- Rockstone^{Send me a message!} 03:44, 1 June 2023 (UTC)

• I think that IP editing should be allowed because there are many great IP contributors on Wikipedia. The person who loves reading (talk) 23:45, 18 May 2023 (UTC)
• The point that would really interest me is whether there's a case to be made that "anon" editing is actually likely to be harmful to users who (despite the current warning notice) may not realize the kind of trail they're leaving. (The long-overdue IP masking initiative would change the landscape here somewhat, but only to an extent -- as I understand it, IP masking will involve pseudonymization of data but not true anonymization.) If allowing IP editing is causing editors to unwittingly compromise their privacy (in ways that we now recognize as problematic), I would find that to be a stronger argument than whatever the incremental effects on vandalism or admin workload might be. -- Visviva (talk) 00:27, 19 May 2023 (UTC)
• can't wait for the community to waste a month on this, and then waste another on the close review. lettherebedarklight晚安 01:25, 19 May 2023 (UTC)

  Not to mention the disaster that closing this discussion would be as-is anyway, given that there's no votes and just a bunch of hap-hazard thoughts spread around (apparently by design). ThadeusOfNazereth(he/him)^{Talk to Me!} 01:43, 19 May 2023 (UTC)

• I oppose banning IPs from editing entirely as we would lose a lot of productive contributors, but I would support an immediate ban in the event of the WMF deploying IP masking on the English Wikipedia. —pythoncoder (talk | contribs) 01:51, 19 May 2023 (UTC)
• I would say no, because I have felt edit-stalked since I created an account. Although I was reverted more often as a floating IPv6 editor, I didn't have to deal with others stalking my unrelated contributions. I don't mind scrutiny, but when it comes from disapproval of edits on unrelated topics, it's wrong, period. Sandizer (talk) 04:51, 19 May 2023 (UTC).
• I would oppose as a long-time anonymous editor, and I can say that, if registering were required, I probably would not be here, either because I wouldn't have noticed it, or, if I did, not do it simply because I did not want to. And there are a lot of valid reasons for IP addresses to not create accounts. 47.227.95.73 (talk) 20:48, 19 May 2023 (UTC)

  Hi User:47.227.95.73, I'm curious as to what the valid reasons are for not creating an account, and why you think you'd not be here if you had to create an account. SilkTork (talk) 12:16, 20 May 2023 (UTC)

  See my comment on my talk page. 47.227.95.73 (talk) 13:11, 20 May 2023 (UTC)

• No signs that the current system is WP:BROKE, so don't fix it. Yes, there was ptwiki's implementation of this, but that's a different wiki with a likely different culture surrounding IP editors. IP masking should fix some of the problems initially brought up, and I'm not convinced barring IP editing as a whole is going to make Wikipedia better; in fact, I think it would make it worse. Skarmory (talk • contribs) 10:17, 20 May 2023 (UTC)
• It's not worthwhile having this discussion now, when temporary accounts / IP masking is due soon. Once that change has happened and any issue have been ironed out maybe it will be necessary to have a discussion, but we can't know for the moment. The only concern I can see is that vandals can just reset their temporary account by clearing cookies, but that's only slightly easier than getting a new dynamic IP, and even then will only be an issue for non-admin vandal patrollers. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 14:35, 20 May 2023 (UTC)
• Too late to fix the stable door after the horse has bolted, the WMF has already wasted massive amounts of developer time on not doing this. Or too early, we don't yet know how the "IP masking" will turn out in practice. —Kusma (talk) 10:42, 21 May 2023 (UTC)
• Editing should not require an account. One of the original principles, still valid today, is (with my emphasis here) "You can edit this page right now ... We must respect this principle as sacred." It is not "you can edit this page after registering and logging in". This principle is common to all Wikimedia projects (with my emphasis here) "The ability of almost anyone to edit (most) articles without registration."
  In a world where everything wants me to register, have an identifier (even if it's not required to be my real name), have a separate password to keep track of, it's a refreshing change to have something that just lets people do something (edit) without having to jump through hoops first, no matter simple those hoops may be.
  Recording and displaying IP addresses is a privacy issue, but the solution is to limit the recording/display of IP addresses (which presumably IP masking will do), which can be done independently of registration. In any case, if we choose to record/display IP addresses, but tell the editor first, then it is the editor's choice - they always have the choice to create an account, but we do not require it.
  There will be vandals and other bad actors, and making people register might deter some of them, but one of Wikipedia's guidelines is to assume good faith, so we should do that for an anonymous editor - to ask people to register so as to make it easier to reduce bad actors is effectively to assume bad faith. The price of "anyone can edit immediately, without registering" might be an small increase in vandalism, but I think that is a price worth paying for our principles. Mitch Ames (talk) 12:43, 21 May 2023 (UTC)
• Prohibit Masked edits. The WMF has declared that IP-editing is going to be terminated, and they consider that non-negotiable. They intend to replace it with Masked edits, hiding logged out users behind temporary coded identifiers. This will only increase the aggregate problems caused by logged out users, and it will only make it more difficult for the community to deal with them. This significantly shifts the cost-benefit calculus. We need to establish consensus and bar Masked edits before the WMF turns them on, because if we allow so much as a single Masked edit we're stuck with these new coded-identifiers stuck in our database forever. Many of our tools and software will BREAK whenever they encounter one of these edits in history, many of those tools will never get fixed, and all future tools will have to deal with these junk-identifiers forevermore. I fear the WMF is going to screw itself with permanent software headaches if they enable Masked edits anywhere, and it's ultimately abandoned. The need to keep the junk-identifiers in the database permanently for attribution reasons, leaving them stuck supporting the random garbage identifiers in all of their software forevermore. Alsee (talk) 15:11, 19 June 2023 (UTC)

  The "junk-identifiers" will be reserved by MediaWiki anyway. Snowmanonahoe (talk · contribs · typos) 15:18, 19 June 2023 (UTC)

  Identifiers being reserved isn't the problem; being used may be. More generally, if we can't effectively fight vandals who conceal their IP addresses, there is a case for blocking IP editing from the moment IP masking is released rather than later. In other words, we'd prevent IP masking from happening on this wiki; the new code (which runs when an IP edits) would be released but never executed here. For 13 years, I've displayed a userbox supporting the right of anonymous users to edit Wikipedia, so I don't suggest blocking IPs lightly, and it's hard to tell yet whether it would be worse or less bad than IP masking. Certes (talk) 18:10, 19 June 2023 (UTC)

  Alsee, you begin your argumentation with the (for me, astonishing) claim that, The WMF has declared that IP-editing is going to be terminated. Can you provide a link to someplace where the WMF states this so clearly (and non-negotiably)? Also, if that's true, why would the WMF screw around with the complexity of masked IPs and not just go directly to "logged-in editing is required on all platforms starting on yyyy-mm-dd"? — JohnFromPinckney (talk / edits) 20:15, 19 June 2023 (UTC)

• I think this would be net negative as it may drive away prospective editors who would have created an account at a later point and contributed. I started editing Wikipedia as an IP long long ago. Created an account less than 5 years ago, and became a regular contributor less than 3 years ago. I do not think I would be contributing here today if I hadn't begun editing as an IP. —CX Zoom[he/him] ^{(let's talk • {C•X})} 18:52, 19 June 2023 (UTC)

Discussion about the RfC

• I would recommend Idea Labing the proposal first before this turns into a trainwreck. Curbon7 (talk) 19:23, 18 May 2023 (UTC)

  Jc37, How dare you call my comment essentially useless bureaucracy when I'm giving you advice on how to make your RfC stand on two feet rather than flop like a fish out of water. Sectioning off comments like this might be one of the most inappropriate things I've seen in an RfC, especially considering this is formatted as an open-ended discission. Curbon7 (talk) 00:22, 19 May 2023 (UTC) Resolved. Curbon7 (talk) 03:29, 19 May 2023 (UTC)

  I appreciate that your suggestion may have been well-meant.

  Discussion of the question proposed? above. Discussing the RfC itself? right here. Your statement was one of "venue", and has nothing to do with the question of "whether Wikipedia limits editing to accounts". Whether intended to be or not, these arguments are essentially just WP:NOTBURO arguments. Do it this way, not that way, have the discussion there not here. There are also some who are attempting to predict the future, but that's still not addressing the question of the RfC, and still just about the RFC itself. - jc37 00:35, 19 May 2023 (UTC)

  Upon further reflection, and re-reading your comments, I decided to remove BURO from the heading. I didn't ever say or imply that your seemingly well-meant suggestion was "useless", and I am sorry that you interpreted it in that way. - jc37 02:15, 19 May 2023 (UTC)

• @Jc37: I just removed the RfC tag, and this from CENT, but you have reversed me. This is not formatted like an RfC, especially given that this appears to be a de facto referendum on IP editing. Where is the brief and neutral statement? You have provided a rationale, not a neutral RfC question. The proper way to do this would be to set forth a short, neutral question or prompt, and then put your rationale as say the first comment. Instead, this looks like a pre-RfC, designed to workshop an eventual RfC. You can't just slap an RfC tag on anything you want more people to look at, and you especially can't just put it at CENT. Please self-revert. CaptainEek ^{Edits Ho Cap'n!}⚓ 19:40, 18 May 2023 (UTC)

  a.) This is an RfC, per WP:RFC. "A request for comment (RfC) is a request to the Wikipedia community for comment on an issue." In this case: "Should editing on Wikipedia be limited to accounts only? " b.) it follows the way we have created RfCs for decades. c.) Actually an RfC question does not need to be neutral. It just needs to be a question. Perhaps you are thinking of a neutral notice about an RfC. - jc37 19:53, 18 May 2023 (UTC)

  ​ Um... from WP:RFCOPEN, #4: Include a brief, neutral statement of or question about the issue in the talk page section (emphasis in original). So yes, an RFC question does need to be neutral. Primefac (talk) 19:59, 18 May 2023 (UTC)

  First, this isn't on a talk page of an article or policy page, because it's an overall policy. I put it at the VP - which is what we do - look up for examples.

  Second, "Include a brief, neutral statement of or question about the issue - I did. look at the top. I not only provided the question (which the bot copied). but I also explained. it.

  So I followed that. - jc37 20:14, 18 May 2023 (UTC)

  WP:RFCNEUTRAL → Keep the RfC statement (and heading) neutrally worded, short and simple. 192.76.8.85 (talk) 20:02, 18 May 2023 (UTC)

  As I noted above, I agree that this is not really fit as an RFC and so I have re-removed the tag. Obviously discussion can (and should) continue to see if there's something that should be proposed as an RfC. Best, Barkeep49 (talk) 20:04, 18 May 2023 (UTC)

  In what way do you think this does this "not really fit as an RFC"? All an RfC is, is a request to the community for comment. That is exactly what this is. And the question is very straight-forward - "Should editing on Wikipedia be limited to accounts only? ". - jc37 20:17, 18 May 2023 (UTC)

  If the RfC question was the header, that is a bad practice. Further, it makes your !vote look way more important because you have made it appear as if your comment is in fact the RfC prompt. Look, a discussion about IP editing was inevitable. But such a conversation will be extremely contentious. It will take a well crafted RfC to ensure consensus can be found. But what you've created here is not designed to create consensus. It will be a nightmare to close. You assume there won't be voting, but I'm almost certain that before the halfway point it will devolve into supports and opposes. Further, you have not followed WP:RFCBEFORE to workshop this RfC, which is evident in the fact that we're having this discussion. Overall, this is an important conversation that will have to be had at some point. But doing it prematurely or poorly will only serve to delay the issue. This is just not the way to do it. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:43, 18 May 2023 (UTC)

  This isn't a "vote". And second, you can tell the RfC prompt by the first signature - that's why it's there. And it's all above the "discussion" heading, so it's clear that it's the introduction. Just... like... any... other... RfC...

  And yes, this is important. And I did a fair amount of reading before hand, or I would not have started it. I'm not stupid or naive.

  As for closing, we've had discussions on Wikipedia before now, including fundamental ones like this, and they managed to close them. - jc37 20:54, 18 May 2023 (UTC)

  While we're all aware that consensus is not a vote, this discussion simply is not set up to arrive at a meaningful consensus. You wrote a handful of brief, vague sentences, gave us half-a-dozen links of optional reading, and asked us to discuss amongst ourselves. I really don't foresee how this RfC will lead to a substantive result. I see that you commented above that you wouldn't mind if this became a brainstorming RfC; well, I think that's all it can be. LEPRICAVARK (talk) 06:35, 20 May 2023 (UTC)

  No, I wrote 1 straight-forward question: "Should editing on Wikipedia be limited to accounts only?". Then I wrote some explanatory text after it, including (some of) why I am asking the question. What I said above was that I am not placing a preconception on what the result of this RfC will be, and am content that the discussion (and thereby, the community consensus) goes where ever the community takes it. We've had RfCs designed to "force" commenters to respond in one way or other. (and in reading some responses here, it's apparently a shock to some that I'm not trying to do the same in order to force a certain outcome.) But this isn't that. I think this is too important, too fundamental a question to do that. Everyone should be able to have their say on this question and not be railroaded by anyone trying to "herd cats" in a certain direction. Let the community have its say. And once it has, it can be determined if the community has come to a consensus. I find anyone trying to upend that, honestly, is merely being disruptive, whether intentionally or not. - jc37 00:27, 21 May 2023 (UTC)

• In re-reading the above, and thinking about the fact that we're talking about a template that merely summons a bot to add a notification, I'm thinking that everyone involved could use a WP:TROUT, and some time re-reading WP:NOTBURO. The idea that you all seem to be suggesting that there are RfC discussions and then there are "special" RfC discussions, is rather an eye-opener, to be sure. - jc37 20:54, 18 May 2023 (UTC)

  The most blatant problem with this RFC could easily be fixed by jc37 moving everything past the first line into the discussion section. Could you just do that and see if anyone objects to anything else? Phil Bridger (talk) 21:00, 18 May 2023 (UTC)

  Looking at Wikipedia:Village_pump_(policy)#RfC_on_a_procedural_community_desysop and Wikipedia:Village pump (policy)#RFC: MOS:GENDERID and the deadnames of deceased trans and nonbinary persons, as examples, I can add an additional header, if that helps resolve concerns. - jc37 21:06, 18 May 2023 (UTC)

  The issue is important but this proposal is deeply counter productive. The main problem is that this is guaranteed to fail—it is too soon after the last couple of failed attempts, and it is too early before we see the consequences of IP masking. We could have a stirring argument but a proposal to limit editing to accounts will fail at the moment. The secondary problem is that having yet another failed argument will poison the well for the future. My prediction is that IP masking will be problematic, but I'll keep an open mind and see what happens. A pointless argument now will only make it more difficult to raise the issue again if IP masking is a problem. Please just drop it. Johnuniq (talk) 00:05, 19 May 2023 (UTC)

  Funny how this started about should IP users be banned from editing the wiki to Admins and above have different views on different policies. I (and some who have no choice like Russia, North Korea, etc.) either prefer to edit as an IP or do not want to create an account that can be traced back to them. If a user creates an account they are prompted for their email so now their privacy to those countries is blown away. Not a good idea. It’s great those smaller wikis had done test runs but come-on English is the largest wiki and the most targeted. The more restrictions put on WP the harder it is for anyone to edit. I’m on AT&T first response network and I’m blocked in a range block if I’m not on a wifi somewhere. Some networks you have already blocked have numerous blocks against them and the blocks won’t expire for a couple of years (which I believe is not the policy). So if you want to turn off IP editors I personally feel you will lose a lot of editors. Admins and up are in place for a reason and I feel this is an attempt to stifle IP editors and to lower the work load for admins. Hey if you admins don’t want the work, turn over your mop. — Preceding unsigned comment added by 2600:8801:CA05:EF00:4405:B060:E0C7:DB35 (talk) 02:07, 19 May 2023 (UTC)

  Giving an email address is optional. And if you do provide one it is not available to the public. Snowmanonahoe (talk · contribs · typos) 02:24, 19 May 2023 (UTC)

  It may be optional but if they forget their password, they would need to create yet another account and there is no policy on deleting old user named accounts that haven’t edited in years. 2600:8801:CA05:EF00:4405:B060:E0C7:DB35 (talk) 06:43, 19 May 2023 (UTC)

  Your edits are not "deleted", whether done as an account or an IP. As for the account name, there's always WP:RTV. - jc37 08:57, 19 May 2023 (UTC)

  @Jc37 you completely missed that point. Why would someone want to use vanishing because they forgot their password? Maybe they want it to be credited to them but they make complicated passwords or mistype it? You are looking at this as you are the iron fist (from what I’m reading throughout this conversation, and so addressed by other editors) that you won’t take any other answer other than block all IPs. This will drive away new editors who are dipping their toes in the water before wanting to even commit to creating an account. Also you used, once again, a guideline and not any policy. Granted you are pretty passionate it seems about banning IP addresses and uprooting the Encyclopedia that anyone can edit to Encyclopedia that anyone who gives us their information can edit. 2600:8801:CA05:EF00:4405:B060:E0C7:DB35 (talk) 17:32, 19 May 2023 (UTC)

  I was merely responding to "...and there is no policy on deleting old user named accounts that haven’t edited in years". As for the rest you are welcome to your opinion, but I believe you completely mischaraterize me and what I've said. - jc37 17:45, 19 May 2023 (UTC)

  I'm struggling to understand what it is you want. When you edit logged out you give the world access to your IP address which can be used to determine your rough location. You seem to at least be aware of the fact you're editing from an IP, so I'll assume you're ok with that. So why exactly is it better that the whole world knows where you live, than giving the Wikimedia Foundation (and no one else) your email address, which I remind you, is not something you even have to do? And why do you need the old account to be deleted if you lose access to it? Snowmanonahoe (talk · contribs · typos) 17:50, 19 May 2023 (UTC)

  This is deeply misguided. Anyone concerned with privacy should immediately stop editing as an IP, and create an account. CMD (talk) 04:58, 19 May 2023 (UTC)

  ...isn't it more dangerous to have your exact IP visible in Russia/North Korea than an account without an email? A prompt for an email in these countries, under your explanation, would be ignored by anyone that cares about their safety, and if they don't care about their safety this comment is no longer applicable by my understanding. Skarmory (talk • contribs) 07:46, 20 May 2023 (UTC)

  @Jc37@Skarmory@Snowmanonahoe@CMD - Most people in those countries and a few others like the great firewall of China use VPNs so that covers their tracks to get to Wikipedia and possibly edit it unless someone blocked the entire range (as I mentioned early that AT&T and T-Mobile cellular networks are completely range blocked) and to get around that as a non-admin requires extra work and if I remember correctly when requesting that flag you have to submit a utrs that includes your personal information to those who have access to that queue. That is where the privacy issue then comes into play. 2600:8801:CA05:EF00:95AD:57F8:C033:7A83 (talk) 11:09, 20 May 2023 (UTC)

  The only personal information that gets submitted in an IP-block exemption request is your IP address, and only to administrators. Snowmanonahoe (talk · contribs · typos) 13:22, 20 May 2023 (UTC)

• Shouldn't we wait for a while after IP masking is implemented before making this decision? Sandizer (talk) 04:53, 19 May 2023 (UTC)

  Waiting to see how IP masking works out in practice seems like a reasonable and prudent choice. 68.189.242.116 (talk) 16:09, 19 May 2023 (UTC)

  I think we know some bits, enough to resolve a few of the questions that @Jc37 opened above, and maybe to add some more. Among them (numbered for convenience):

  1. The new "temporary accounts" (see mw:Help:Temporary accounts and mw:User account types) will have some predictable username pattern. This is being discussed on Meta-Wiki (join!). I think the current idea is that the username format will be User:~2023-123456, but it's not final. The number in the username is just a steadily incrementing number. The first account will be "1", the second will be "2", and by the end of the first year, we'll probably be up above ten million.
  2. The temporary account will be per-browser (cookie based), not per-IP. If you use the same device/browser, it'll be the same username no matter where you are editing from (at home, at school, at work, via VPN, etc.). This will make it easier to track some editors, but not necessarily everyone.
  3. Pretty much everyone who is active in this discussion will be able to "reveal" the full IP address. See foundation:Policy:Access to temporary account IP addresses and m:Access to temporary account IP addresses FAQ.
  4. This should improve privacy for these editors overall, but it's not a pure, unmixed improvement. In particular, if a temporary editor uses multiple IP addresses, you'll be able to see all of them (for the 90 days that we keep them).
  5. If you think this is going to make tracking people harder, then please read up on the changes to Chrome, which are going to hide editors' (actual) IP addresses. Chrome might end up being a bit more like T-Mobile or the iCloud Private Relay system than it is now, and that's the most common web browser among editors.
  6. We'll be able to ping editors using temporary accounts and otherwise have a much easier time communicating with temporary accounts than with IP editors (especially dynamic IPs).
  7. It might be possible to stop some of the m:Talk:No open proxies/Unfair blocking problems since we won't be relying solely on IP addresses.
  8. Some tools will need to be updated. We have months to get this done in, but it will be work. Realistically, some tools will break, and some will be unfixable. It might also open other opportunities for new and better tools.
  9. Help pages and other documentation will need to be updated. It's probably too early to do that work, but it's not too early to make a list of key pages.

  I'm sure there are other relevant points, but perhaps this is enough for a Friday evening. Feel free to ask questions. Whatamidoing (WMF) (talk) 04:32, 20 May 2023 (UTC)

  @Whatamidoing (WMF), I'm curious:

  1. Will the cookies be persistent or per session?

  2. What happens if someone has cookie blockers set up?

  3. I'm not entirely sure how the mobile apps work - will each launch of the app be treated as a new browser session, with a new ID assigned? 199.208.172.35 (talk) 20:14, 22 May 2023 (UTC)

  1. Persistent, up to some reasonable length of time. This is currently set to one year, but could be shorter. I've seen a proposal that's as short as 90 days. (I personally prefer a full year.)
  2. They'll get a new temporary account each time. If they don't like that, they'll need to accept cookies from Wikimedia websites.
  3. The apps should look basically the same as the website (from the POV of the user) in this respect, so you'll get a temporary account on your first edit and re-use it until it expires. (However, since it's impossible to log in to a temporary account, if you edit from the app + the website, those will be two separate temporary accounts.)

  Whatamidoing (WMF) (talk) 00:09, 23 May 2023 (UTC)

  Very interesting, thanks! Perhaps the most interesting point is #6. Guess it's going to be much harder for me to pretend I didn't see something. 199.208.172.35 (talk) 14:42, 23 May 2023 (UTC)

  @Whatamidoing (WMF): Will we be able to see all the temporary accounts coming from an IP address, or ideally a range of them? Snowmanonahoe (talk · contribs · typos) 22:47, 25 May 2023 (UTC)

  This is an open question, and I believe that Legal will have to answer their part of it before Product will figure out whether it's technically feasible (i.e., without making major changes to MediaWiki). The legal answer might sound like "only for Stewards, CUs and others who have signed up to the m:Access to nonpublic personal data policy" (or it might not; that's the thing about waiting for legal advice).

  On the community side, I believe there are concerns that this could be too similar to a Global CheckUser, which has not been an especially popular idea in the past. A vandal could use multiple IPs in a range, but so can innocent, unrelated editors. Whatamidoing (WMF) (talk) 03:26, 1 June 2023 (UTC)

  @Snowmanonahoe, the AHT team is looking into this. We have no promise that it will happen, but I consider this a step in the right direction. My best guess is that we probably won't have any more/clearer information until at least September. Keep an eye on m:IP masking; that's where they're making official announcements. Whatamidoing (WMF) (talk) 19:35, 9 June 2023 (UTC)

  Things are changing? Cwater1 (talk) 02:29, 10 June 2023 (UTC)

RfC: Delete all webcitation.org links

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

Keep. RfC proposal invalidated by WebCite itself, which came back online while the RfC was ongoing. The WebCite outage lasted about 1.5 years. Further discussion about WebCite at Talk:WebCite GreenC 18:01, 24 June 2023 (UTC)

---

This is a continuation of the previous RfC three years ago that passed to deprecate WebCite. The proposal today is to delete all remaining WebCite links. -- GreenC 17:46, 22 May 2023 (UTC)

As background, WebCite archives became unavailable over a year ago. Attempts were made by The Internet Archive to work with the owner of WebCite to transfer the content to Internet Archive, but no agreement was reached due to the owner's insistence on being paid a significant amount of money. Other entities also tried to work with the owner to no avail, his evident position was/is either pay up, or let it burn. The WebCite software is outdated and convoluted and the technician who was able to keep it going left the company. It's unclear even we had the data it might be non-trivial to move to another provider due to how it was built with frames to prevent transferring of the archive pages. The owner ran WebCite as a side project, there are no indications it is coming back online.

• Bots have already moved to other providers. The remaining WebCite links have no known archives elsewhere.

The proposal would allow for bots to automate deletion of links with the end goal of having none left. The exact procedure for deletion is still be worked out since the links exist in different formats and in various ways (CS1|2 templates, {{webarchive}}, square and bare links, {{official}}, etc...). The underlying source URL would be preserved where possible. -- GreenC 17:46, 22 May 2023 (UTC)

Survey (delete webcitation.org links)

• Delete per/as nom. -- GreenC 17:46, 22 May 2023 (UTC)
• Keep -- I have severe concerns when a disclosed paid agent of the Internet Archive is telling us that because the IA itself was unwilling to pay the price for the resource, all links to it should be removed. Having been told that the resource has been made available for purchase, we should be open to the thought that some other player may choose to purchase it, at which point the absence of those links becomes a matter of devaluing both the resource and Wikipedia. At the very least, we should not be deleting the record of a webcite where we do not have the original underlying URL, as the webcite is our record that there was something, somewhere being cited. --Nat Gertler (talk) 20:15, 22 May 2023 (UTC)
• Keep per NatGertler, who said everything I would have but more concisely. This proposal is too soon, and too mired in IA's own organizational politics. Agree with AquilaFasciata under "Discussions" below that when possible a WebCite link should be replaced with a working IA (or other) one.  — SMcCandlish ☏ ¢ 😼  22:04, 22 May 2023 (UTC)
• Remove eventually per nom, but it seems like the devil is in the details as to what an automated removal/replacement process could look like. -- Visviva (talk) 22:18, 22 May 2023 (UTC)
• Keep until the details of how the removal will be effected and what they will be replaced by are agreed. There should be some way for humans to identify that there used to be a webcition.org in an article and what it was, and some way to easily find these articles. Deletion without replacement or replacement with a {{citation needed}} or similar template will lead to the loss of probably-verifiable information because it is uncited. Thryduulf (talk) 02:19, 23 May 2023 (UTC)
• Close as premature, because of the discussion immediately below this one.—S Marshall T/C 08:42, 23 May 2023 (UTC)
• RfC unnecessary as if a link becomes dead we immediately work to find the archived link. If there is a need for an RfC, then I concur with replacing the broken archive links with archive links that actually work, and if that means using Internet Archive, that's that. Aasim - Herrscher of Wikis ❄️ 13:36, 23 May 2023 (UTC)
• Delete: Links to WebCite have been dead since October 2021. Any WebCite URLs that are used in citations in our articles, and whose original source is unavailable or deviated, are not serving any purpose towards WP:V. Removing any remaining links to WebCite that were missed in earlier runs of GreenC's bot, along with tagging with {{dead link}} will allow IABot to attempt a fix. Yes it is possible that no archival copy of those citations exist on other archive platforms, but this will at least fully reveal the scale of that problem which already exists (because WebCite links are already broken anyway).
  Is it possible that WebCite could still be bought and somehow restored at the same URL? Or restored at a different URL? Sure, maybe. And if that happens, and the citations aren't covered by another archival service, that's something that can be solved either by restoring the URL from the article history, or a bot who can re-add the URL in whatever format the revived service uses. Sideswipe9th (talk) 13:52, 23 May 2023 (UTC)
• Delete. Keeping these broken links doesn't fix anything and just stands in the way of actually seeing the full scope of the issue. A dead archive is a dead link, and it should be tagged as such. If we need to know when a website was accessed, then that's exactly what the |access-date= parameter would be for. –MJL ‐Talk‐^☖ 03:04, 24 May 2023 (UTC)
• Keep as per SMcCandlish. Instead of deletion, could we tag these references so that people who do want to replace these links or find other archives can do so? - AquilaFasciata (talk | contribs) 13:15, 24 May 2023 (UTC)
• Keep per NatGertler, SMcCandlish, et. al. --Jayron32 16:54, 24 May 2023 (UTC)
• Keep, but tagging en masse may be appropriate. As I understand it, all of these links are dead and the only archive was held by WebCite. I don't see how one dead link is better than two. These are difficult cases of link rot that may require finding new references or removing information—this suggestion doesn't aid this manual task. — Bilorv (talk) 15:45, 30 May 2023 (UTC)
• Keep on the understanding these links are only still included in Wikipedia articles where the original link is dead and no other archive service has the content. I don't think removing the link is an improvement in that narrow circumstance. (at least not yet) Walt Yoder (talk) 19:23, 31 May 2023 (UTC)
• Delete My understanding, unlike my understanding of some of what the keep !votes are arguing, is we're just deleting completely dead links, not anything more. If I'm not mistaken, this should be done post-haste. SportingFlyer T·C 18:04, 6 June 2023 (UTC)
• Delete I wonder if anyone has entertained the possibility of the domain being taken over by a rogue operator and redirecting traffic to shady sites or other not related sites. It is a lucrative domain for any black-hat SEO people to take over. The current module do not seem to have protection from archive urls getting usurped. – robertsky (talk) 03:20, 9 June 2023 (UTC)
• Delete. GreenC, as a longtime volunteer in this area (that's how he got hired by IA), is the right person to make the suggestion he has. But besides that, we are not served whatsoever by dead archive links. They are literally the most useless links we could have.

  Simply deleting the link and setting |url-status=dead is sufficient to identify in a citation that the citation is malformed and needs repair by emitting a maintenance message (see also Category:CS1 maintenance): "Google".{{cite web}}: CS1 maint: url-status (link). I think that would be a blunter instrument than preferred for this case, and would probably prefer to see the archive URL removed and |url-status= set to some other keyword (we already have bot: unknown, bot: webcitation may be appropriate). Of course, in some cases the URLs are in a separate template entirely due to use with a "manual" citation, which probably merit removal entirely with the addition of {{dead link}}. Izno (talk) 19:49, 13 June 2023 (UTC)

Discussions (delete webcitation.org links)

• Is there any idea how many citations are only available on WebCite vs. how many are available through alternative archives? Would it be possible to move those to alternative platforms? - AquilaFasciata (talk | contribs) 19:23, 22 May 2023 (UTC)
• I was just going to ask the same question that AquilaFasciata asked. Also, what is more "preserving" of the current link than the status quo? Or, to combine the questions, can a bot try to link somewhere newer, and, when not possible, leave it in place as with any other completely dead link? Actually not surely permanently dead per NatGertler|'s post. North8000 (talk) 20:33, 22 May 2023 (UTC)

  It's in the 10s of thousands I don't have an exact count. Bots have already moved everything that can be moved. Whatever is left doesn't exist elsewhere. -- GreenC 22:04, 22 May 2023 (UTC)

  Using this naive search I get a little over 20k occurrences of "webcitation.org" in article space. But the couple that I've looked at (e.g. this one on Clint Eastwood) seem to be replaceable with IA archives. But it seems like they might require a human in the loop to verify that the new archive, which will generally be from a different day, actually still supports the cited assertion. -- Visviva (talk) 22:16, 22 May 2023 (UTC)

  That should have been converted by my bot on June 14, 2022 but the {{cite web}} template contains {{'-}} which is either an old bug fixed or an unidentified bug that threw off the parser. When the WebCite link is removed, it will add a {{dead link}}, then IABot will add any available archive URL. It shows how these WebCite links are gumming things up. -- GreenC 01:26, 23 May 2023 (UTC)

  National Front (UK) election results has links with titles that imply they are from webcitation.org but actually link to pages on the Internet Archive. This appears to be because GreenC bot changed the archives but left the titles alone, I haven't investigated how common this is, nor whether it is something that a bot could reliably fix, but if it is common it will distort the scale of the problem (because while the titles are a problem, it is a different, lesser one). Thryduulf (talk) 02:53, 23 May 2023 (UTC)

  @GreenC: looking through the raw list I found Kit Hinrichs, where almost all of the external links used just www not http://www which seems to have mean it wasn't spotted by whatever process you used to find webcitation.org links. I fixed this issue and ran the normal fix dead links tool on the article, but all it did was mark the webcitation.org links as dead (even though the main URLs are also no longer working in at least some cases). Please could you recheck that article for working archives on other services and any others that might have the same issue. Thryduulf (talk) 21:11, 28 May 2023 (UTC)

• Responding to Nat Gertler's concerns, I was not asked by IA to do this work, it's my own initiative as a Wikipedia editor for the past 20 years, this has nothing to do with IA. IA has no interest if these links are kept or deleted. The idea that WebCite will sell the content to be made live again is laughable for a couple reasons some of which I touched on in the nom. IA offered to pay for reasonable expenses, such as for the hardware and shipping and time to prepare it all, but WebCite wants to make a lot of money from it. Since no one bit, and a few entities tried, the owner of WebCite walked away from it burning the open source community and community of archive providers who usually work together (this all happened over a year ago). I am paid by IA but also work with other archive providers towards the common goal of saving dead links (Special:Diff/1155651594/1156379648). The idea that someone else might pay for it in the future is extremely unlikely. I suppose Wikipedia can hold out hope, but the cost is 10s of thousands of inoperable archive links that are non-verifiable cluttering the system wasting people's time. -- GreenC 22:04, 22 May 2023 (UTC)
• Comment If the citations still exist, albeit just inaccessible barring a commercial arrangement, wouldn't deleting them all leaving content unsourced be inconsistent with WP:SOURCEACCESS? Betty Logan (talk) 02:25, 23 May 2023 (UTC)

  The proposal is to delete dead WebCite links, not citations. -- GreenC 03:32, 23 May 2023 (UTC)

  Yes, but if Webcite is the only resource where they exist then deleting them will render them irretrievable. While there is a clear advantage to replacing this links if possible, I don't see what the upside is to deleting them. There is a clear downside if the licensing issue is resolved and Wikipedia has deleted the links. Betty Logan (talk) 06:04, 23 May 2023 (UTC)

  The WebCite URLs are already dead. They functionally serve no purpose towards WP:V, because clicking on them doesn't actually bring you to an archived copy of whatever the citation is supposed to be. The SOURCEACCESS problem already exists.

  There is a clear downside if the licensing issue is resolved and Wikipedia has deleted the links. There's two solutions to this. Deleting the WebCite links doesn't actually remove the link itself from the article history. If the service does somehow become live again at the same URL and with the same URL pattern as previously, those links can be easily retrieved from the article history. However, if the service does become live again, either at the same URL or a different one, it is I think reasonable to assume so will its APIs. If that is the case, then bots like IABot can use those APIs to query for archived copies of a given URL in the same manner as they did previously to the site going offline in October 2021, and automatically restore/re-add the archived URLs. Sideswipe9th (talk) 14:04, 23 May 2023 (UTC)

• Comment: Examples Some examples of what would happen:

Type 1: CS1|2:

Source: {{cite web |url=http://example.com |archive-url=https://www.webcitation.org/5eWaHRbn4?url=http://www.example.com/ |archive-date=2000-01-01 |title=Example}}

Result: {{cite web |url=http://example.com |title=Example}}{{dead link}}

Type 2: Square-url:

Source: [https://www.webcitation.org/5eWaHRbn4?url=http://www.example.com/ Example]

Result: [http://www.example.com/ Example] {{dead link}}

Type 3: Square-URL with {{webarchive}}:

Source: [http://www.example.com/ Example] {{webarchive |url=https://www.webcitation.org/5eWaHRbn4?url=http://www.example.com/}}

Result: [http://www.example.com/ Example] {{dead link}}

Type 4: Bare-url:

Source: * https://www.webcitation.org/5eWaHRbn4?url=http://www.example.com/

Result: * http://www.example.com/ {{dead link}}

• Note 1: The above should be at least 80% of them. The remaining may not have a ?url= (such as "https://www.webcitation.org/5eWaHRbn4" only) in which case they will be removed when Type 1 or 3, and kept elsewhere for manual review.
• Note 2: In terms of logging that is easily done with a CSV on wiki, containing 1 line per citation, with the first column page title, second column the unmodified citation (newline converted to "__newline__"), third column the replacement citation, and fourth column the WebCite URL. In this way the entire thing is easily reversible on a per page or entire site basis.

-- GreenC 05:16, 23 May 2023 (UTC)

Why is there an assumption that the original source url is a deadlink? — xaosflux ^Talk 14:58, 23 May 2023 (UTC)

Well this is the case in all of the above "Source" examples (except for Type 3). They were originally treated as dead so nothing changes. For Type 3 it can do a status check and not mark as dead if it's 200; this is a problem for soft-404s in which case running IABot on the pages post-processing will weed some of those out. -- GreenC 15:09, 23 May 2023 (UTC)

@GreenC sorry I'm missing something, say we have this source: https://www.webcitation.org/6YloKPaFj?url=https://www.princeton.edu/mudd/news/faq/topics/Non-Cooperative_Games_Nash.pdf Example; and we convert it to https://www.princeton.edu/mudd/news/faq/topics/Non-Cooperative_Games_Nash.pdf Example -- why would {{dead link}} be appended if the link isn't actually dead (in this example the link is not actually dead)? While the webcitation link is dead, this would actually revive the link and make it no longer dead. — xaosflux ^Talk 13:24, 24 May 2023 (UTC)

Are you suggesting that a bot re-test whether the original link is dead, since some of them may have been incorrectly marked as dead when they weren't? WhatamIdoing (talk) 23:54, 24 May 2023 (UTC)

He's suggesting a very edge case scenario. And if it happened, while a problem remains, it's a less severe problem then before. At least now we have a working live link, whereas before it was a dead archive link. It's a step in the right direction. -- GreenC 20:17, 25 May 2023 (UTC)

I'm asking what the tolerance is for making a bad edit unnecessarily. If someone is going to go out of their way to insert a warning notice, we would normally expect this to be accurate. If this is all going to be handled by a bot, the bot could do live checking no? — xaosflux ^Talk 19:07, 31 May 2023 (UTC)

If the site is completely gone, then it's easy to check, but if it's still there and has been re-organized, or taken over by a squatter, then it's an AI problem for a bot to figure out if the current link target matches the intended target. Many common cases could probably be dealt with by heuristics, but I suspect there would still be a lot of pages that wouldn't be handled by simple rules. isaacl (talk) 21:14, 31 May 2023 (UTC)

@Thryduulf and Visviva: pinging re: implementation details posted above. -- GreenC 05:22, 23 May 2023 (UTC)

I don't have time right now for more than a quick response, but while that's better than nothing it doesn't do anything to indicate that it was formerly a webcitation.org url so editors could waste time searching in other archive sites even though we know that the URIs aren't there. I don't understand your CSV comment. Thryduulf (talk) 09:22, 23 May 2023 (UTC)

@Thryduulf, the CSV comment suggests essentially that we should keep a record of the changes made. — Qwerfjkltalk 10:31, 23 May 2023 (UTC)

I don't see how keeping the webcitation link solves your problem. Users will still be wasting time trying to find a replacement for the webcitation link. But this problem is universal to any link marked {{dead link}}, users will waste time trying to find replacements. This is why we have archive bots that do this automatically. There are over 20 archive providers. -- GreenC 14:56, 23 May 2023 (UTC)

Unless there could be something useful in the archive's URL itself (last date it was active?), maybe the archive's URL should be removed and replaced with a note that a bot has attempted and failed to find an archive of the webpage. WhatamIdoing (talk) 03:39, 1 June 2023 (UTC)

FWIW, this sounds OK to me, and I definitely support keeping an on-wiki CSV (or similar) log of the changes. -- Visviva (talk) 03:05, 28 May 2023 (UTC)

In "type 1", why would we do {{cite web |url=http://example.com |title=Example}}{{dead link}} instead of {{cite web |url=http://example.com |title=Example |url-status=dead}}?  — SMcCandlish ☏ ¢ 😼  17:58, 16 June 2023 (UTC)

When you set |url-status=dead without also setting |archive-url=, the CS1/2 templates output a maintenance error, and adds the article to the tracking Category:CS1 maint: url-status. Sideswipe9th (talk) 18:48, 16 June 2023 (UTC)

Keep Insofar as I can tell, existing webcitation.org links are currently working. Fabrickator (talk) 04:32, 24 June 2023 (UTC)

Well well. After a year and half outage, it came back online concurrent with this RfC. I'm glad to see, because while Enwiki only has about 30k links, Wikipedia as a whole across languages and projects has more than 2 million. Even if this RfC has passed with support and the links removed, it would have been trivial to re-add them so no damage would have been done. At this point I think the RfC can be closed as invalid. -- GreenC 17:51, 24 June 2023 (UTC)

It might be worthwhile to use this opportunity to backup the now accessible archives to another service, so that if WebCite goes down again we at least have alternatives to substitute in. Is this something that could be automated? Sideswipe9th (talk) 17:57, 24 June 2023 (UTC)

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

Wikipedia copyright policy regarding episode synopses for documentaries

As a relatively ok but not technically advanced user can I ask that there be some sort of clarification or discussion on wikipedia's policy on the use of episode synopses for multi-episode programmes that are factual, in particular documentaries, and whether that's considered a breach of copyright or acceptable use. A few days ago I created the article Once Upon a Time in Northern Ireland, and as part of that I used the episode synopses/descriptions used on the BBC website. I was unsure of the policy on this but checked against other documentaries including Once Upon a Time in Iraq, Russia 1985–1999: TraumaZone, and The Vietnam War (TV series) which all do the same (or in the last case use the PBS ones).

Cut to today and one user removed and marked them for copyright violations, giving no justification when asked as to why it's been fine on other equivalent subjects but here it's been immediately flagged and removed. They have also not removed the same offending content on these other pages despite being brought to their attention when asking for their justification.

I'm not seeking to claim this person acted unfairly or against policy (because there doesn't seem to be a clear cut one) and I don't want to get engaged in an edit war that could see my account sanctioned, but I hope my frustration after putting the effort in to keep it in line with other similar content is understandable and hope something productive comes out of this. Apache287 (talk) 19:06, 30 May 2023 (UTC)

Across the board, using either short or long synopsis from other websites is a copyvio. We expect editors to create their own short summary for episode pages. Masem (t) 19:16, 30 May 2023 (UTC)

Well if that's the case can it be made explicitly clear in the copyright policy and better enforced, because in the case of The Vietnam War (TV series) copywrite violation summaries have been used for in excess of five years now and no one's enforced it which, along with how quickly I was able to find other documentaries that did the same, suggests there's a knowledge gap there. Apache287 (talk) 19:36, 30 May 2023 (UTC)

It's in this paragraph of Wikipedia:Copyrights, and I don't know how much clearer we could be. We have a volunteer project for finding and dealing with copyvios of this kind, at WP:CP, but it's horribly backlogged and badly in need of more volunteers. I wish we had more automated tools for detecting copyvios (is there a way to make a bot for it?)—S Marshall T/C 21:51, 30 May 2023 (UTC)

Except as a layman I don't find it clear, at all. That one paragraph both declares "never use materials that infringe the copyrights of others. This could create legal liabilities and seriously hurt Wikipedia. If in doubt, write the content yourself, thereby creating a new copyrighted work which can be included in Wikipedia without trouble" but also links to the non-free content policy that says actually you can use infringing-works in certain circumstances as long as it's limited, and then there's simply the principle of Fair Use (that Wikipedia also subscribes to).

How exactly are you even meant to define a documentary episode summary under that? Yes someone wrote it but it pertains to a description of a much larger body of work so is it the whole body that's being assessed or just the summary? Why can I use the image of a documentary's poster in a article despite being non-free because it accurately represents the documentary but not the description likely created by the same organisation?

Even the incident that spurred this section was a wikipedia tool that caught out the summaries on a third party website (one of those TV listings type websites) that didn't create the summary of the work in question, so if it's under copyright then it's been claimed to be violating the copyright of a website violating another website's copyright.

And again I come back to the fact we have examples of these summaries being used for more than half a decade and it's been fine. So it comes across as a nebulous policy because it's not uniformly enforced and isn't being picked up on during just scanning over articles by people reading them. Apache287 (talk) 23:02, 30 May 2023 (UTC)

If you write a documentary, and I write a summary of that documentary in my own words, then the copyright in the summary belongs to me. Another person could write their own summary and copyright in that summary would belong to them, as long as they didn't just copy my summary.

I don't like the non-free content policy either, and in my view Wikipedia's NFCC aren't fit for purpose. I've sometimes come across media that we could fairly and legally re-use, and would be genuinely helpful to our readers if we did re-use, but still get removed/deleted because some editors are here as free content ideologists (which means they're not here to write an encyclopaedia, but we're nevertheless expected to put up with these people).

It's true that other websites do routinely rip off other people's copyright. Some of them rip off Wikipedia. But we try not to. Wikipedia has its own copyright rules that go beyond the bare legal minimum.

If we've had these summaries for more than half a decade, then it hasn't been fine. It's been wrong and problematic but hasn't been noticed. Could you be more specific about which summaries we're talking about, please?—S Marshall T/C 08:25, 31 May 2023 (UTC)

For me the issue is that given it's a factual documentary and the summaries are more than likely written by the documentary team themselves, would that tie in to the copyright of that work? If so then you can argue that Fair Use comes into play here given it's a small use of copyrighted material relating to the documentary, doesn't impact the commercial viability of the work (we aren't uploading hundreds of minutes of footage), and is of educational use.

For the current situation of them being used in an instance for more than five years, it's The Vietnam War (TV series) as a quick google of any of the summaries will show it's straight from the PBS website. I personally wouldn't call it wrong and problematic given the context of use, so much as an example of what seems to be a legal grey area everyone's been happy to let exist because it's not detrimental to anyone. Apache287 (talk) 09:41, 31 May 2023 (UTC)

So, I think you are a little confused. All text should be deemed as being copyright protected unless specifically stated otherwise. Even if it was written by the team making the documentary, that's a copyright infringement. If it was written by someone who had released the text, that would be something different (but, arguably, we should just have our own anyway).You point to other articles that have similar issues, but they should also not copy from elsewhere. These can be safely removed if they are unambiguously copyright violations. Lee Vilenski ^{(talk • contribs)} 11:23, 31 May 2023 (UTC)

Copyright of text is not part of NFC's policy, that's strictly under WP:COPYVIO. We only mention text under NFC as the question comes up enough there, but we don't require the same rigor for non-free files and their justification ,compared to text segments. Masem (t) 12:21, 31 May 2023 (UTC)

For example, you can't just copy television episode summaries from a TV Guide magazine or an official website for the show, even if you see them used on other websites.

When someone says that they find something unclear in the policies and guidelines, it's safe to assume that they actually do find it unclear. If one editor finds this unclear enough to ask for help, then others are probably also finding it unclear and making mistakes, rather than asking for help.

This is easy enough to solve by spamming an example into that section. WhatamIdoing (talk) 00:43, 2 June 2023 (UTC)

I wholeheartedly agree with this. There is so much confusion surrounding copyright. I also think there is some confusion on Wikipedia on the difference between what might be copyright infringement and what might be plagiarism. If recipes are not copyright protected, then I doubt things like episode summaries would be either since they contain no substantial literary expression. Even individual items in a cookbook are not protected when the whole cookbook is. Huggums537 (talk) 19:05, 2 June 2023 (UTC)

@Huggums537: Except episode summaries and synopses do contain substantial literary expression; many of them can be rewritten, but the ones that are copied from other places have very flowery, detailed language that can and should be rewritten. Sennecaster (Chat) 18:58, 16 June 2023 (UTC)

I think you might be confusing episode summaries/synopses with episode reviews/profiles etc. Huggums537 (talk) 19:06, 16 June 2023 (UTC)

The episode reviews/profiles etc. are fully comprised of literary expressions from authors describing their own personal views about episodes, while the episode summaries/synopses are just restatements of the basic facts already obviously known about the episode. It shouldn't really matter if it contains flowery or detailed language. I mean I could add flowery language to a basic recipe, but it doesn't change the fact that I'm still just giving you a recipe, and only the flowery language would be copyrighted, not the facts about the recipe. If I've added any "flowery or detailed" personal commentary beyond what a summary or synopses is, then it really falls into the territory of being an entirely different thing all together, so yes I would agree those need to be rewritten since they are no longer just simple restatements of known facts, but these BBC summaries aren't "flowery or detailed". Huggums537 (talk) 20:24, 16 June 2023 (UTC)

As an example, Watching The Family Album is like coming across a long-lost box of family photos: it's enchanting, humorous and sometimes even eerie. Director Alan Berliner spent years blending home movies and tape recordings collected from 60 different American families to assemble a composite lifetime which moves from childhood to adulthood, from innocence to experience. is a direct copy of its source and is well above the TOO. It would need to be rewritten entirely to be compliant, since it uses creative means of expressing text. This is the type of plot synopsis and summaries that we do not allow, not simple ones like "Bart and Lisa rob a store". Sennecaster (Chat) 23:30, 16 June 2023 (UTC)

Right. I can see where you're coming from, and I fully agree the flowery language from that source doesn't matter because it can and should easily be rewritten to be compliant by omitting the flowery talk and keeping the basic facts, but the BBC summaries don't have any flowery language so they are just straightforward basic facts that should be able to be copied over. Most personal interpretations and understandings of our copyright policy are way overly strict in my view. The fact we had those things for I think more than five years is more than just a simple WP:OTHERSTUFF argument, it's pretty good solid evidence that there's no concern. Huggums537 (talk) 08:47, 17 June 2023 (UTC)

Huggums, I wish I could say that it's more than a simple OTHERSTUFF situation and that there's no concern, but copyright is horribly backlogged and lacking in both resources and editors. Saying that a copyright issue was only discovered recently and has existed for a while is merely a product of there being no manpower between 2015 and 2019 to discover them in the first place, and that compounds any situation we assess from that timeframe. Sennecaster (Chat) 02:38, 18 June 2023 (UTC)

You seem to have bypassed my comment below. I was mostly talking about there being evidence that no outsiders have even so much as complained about it in more than five years much less even thought about being the copyright trolls I mentioned below. Huggums537 (talk) 02:48, 18 June 2023 (UTC)

Copyright is still one of our legal policies that we're obligated to uphold... even if no one's complained. I accept we won't see eye to eye (I mostly do copyright enforcement, after all!), but I respect your opinions and view on this matter. Sennecaster (Chat) 03:05, 18 June 2023 (UTC)

Thanks. I did forget to mention that those articles existing that long isn't merely just a product of there being no manpower to correct it because the factor of no complaints must also be considered as well, and I would argue of even more importance since a fast removal would prove nothing while five years with no complaints speaks volumes. I'm just wondering if the facts that nobody in the rest of the world seems to care about Wikipedia's backlog, or articles that have existed just fine for five years might be some kind of indicator to those who've had their head buried in the Wikipedia sand that maybe the current "legal policies that we're obligated to uphold" are being overly strictly interpreted or perhaps even misinterpreted by some. Huggums537 (talk) 03:37, 18 June 2023 (UTC)

Especially considering copyright trolls are a thing that are real big business, but we haven't heard a peep out them about it in those five years... Huggums537 (talk) 09:21, 17 June 2023 (UTC)

Copyvios on Once Upon a Time in Iraq and Russia 1985–1999: TraumaZone removed. Will do Vietnam War after lunch - X201 (talk) 11:56, 31 May 2023 (UTC)

Verifiability of Tables

I am mediating a content dispute at DRN which is really a policy question about the verifiability of a table. I am not stating my opinion because, as a mediator, I am trying to maintain neutrality. There was a table in an article, and the table had links to other Wikipedia articles, and no citations of its own. By the way, the article is The Adventures of Priscilla, Queen of the Desert .

An editor removed the table because it had no citations. The other editor says that the table passes verifiability because the linked articles all have references. So the question is whether a table in an article is required to have its own citations, or whether it can rely on the verifiability of the articles that it links to. Also, if a table has no citations, what should be done, tagging the table, or removing the table pending addition of citations? Robert McClenon (talk) 22:06, 1 June 2023 (UTC)

There's nothing special about a table from a WP:V point of view. It's just a different way of formatting information, as opposed to text (or for that matter, a graph, image, or anything else). We don't cite other wikipedia articles because wikipedia is WP:UGC and thus not a WP:RS. Not to mention, if you're relying on another other to transitively provide a citation, what happens if the citation in that other article is removed. Are you expecting that somebody with do a global search for other articles which depend on that citation? -- RoySmith (talk) 22:41, 1 June 2023 (UTC)

If an editor is making a serious challenge to the verifiability of the content, then sources must be added by the editor who wishes to preserve the content, per WP:BURDEN. The existence of sources in linked articles is not sufficient, per WP:CIRCULAR: "Confirm that these sources support the content, then use them directly."

In this case, however, it seems the editor in question (User:Koavf) is not claiming that the information is unverifiable, and is instead insisting that everything on Wikipedia must be sourced as a matter of principle. The question of whether otherwise unproblematic information can be removed purely on the basis of being unsourced was recently the subject of a long VPP discussion which did not arrive at any clear conclusion. I personally find this behaviour unconstructive and believe it goes against the spirit of WP:V, but the letter of the policy doesn't disallow it. Sojourner in the earth (talk) 22:59, 1 June 2023 (UTC)

I agree. "All unsourced information needs a source" is factually wrong. The policies do not require "all" information to be sourced. They require four specific categories of information to be sourced (see WP:MINREF for a handy summary).

Were an editor to show up and say something like "I could be wrong, but I genuinely doubt any editor could find a reliable source that WP:Directly supports this particular content" or "I believe that this is the kind of statement that editors might fight over, so it's 'contentious matter about a living person' and needs at least one good source", then the material would be fall into one (or two) of the required categories. But insisting that information which you believe to be correct be removed from articles until someone else does some extra work is more WP:POINTY than helpful. Providing sources shouldn't be exclusively Somebody Else's Problem. If you think the material needs a source, it should be yours, too. WhatamIdoing (talk) 00:35, 2 June 2023 (UTC)

All information (apart from truly WP:BLUE statements) must have a source. WP:MINREF is only what requires an inline citation, but that doesn't mean of content can be unsourced. Tagging the information if you believe it's true is the correct course (I couldn't tell of that table is true or not), but it's upto the editor wanting to keep the content to source it. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:47, 2 June 2023 (UTC)

@ActivelyDisinterested, it must be possible for someone to find a reliable source that Wikipedia:Directly supports all material, including truly BLUE material.

I'm not sure what distinction you're drawing between "must have a source" and "requiring an inline citation". Are you saying that (some) uncited material "has" a source even though it is "unsourced"? WhatamIdoing (talk) 00:38, 6 June 2023 (UTC)

It seems were equaly at odds with understanding each other, as I'm at a lose to what your second point means. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 10:11, 6 June 2023 (UTC)

In the discussion on the article talk page, I understood ActivelyDisinterested to mean that all material must be supported at least by general references, while MINREF material requires specifically an inline citation. MINREF explicitly rejects this idea, and says that non-MINREF material does not require named sources to be present in the article.

Tagging the information if you believe it's true is the correct course I can't understand this mindset at all. The purpose of a tag is to identify a problem with the article. If you believe that the information is true and verifiable (and has no other issues like NPOV etc.), then surely there isn't any problem with that content? Sojourner in the earth (talk) 11:40, 6 June 2023 (UTC)

Even if that is the case, in this instance it doesn't apply as the content was not non-contentious and has now been referenced. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 12:51, 6 June 2023 (UTC)

@Sojourner in the earth, an editor might run across information that is true, verifiable, neutral, appropriate, and encyclopedic, like "Smoking cigarettes can cause lung cancer", and still believe that the sentence should be followed by an inline citation.

MINREF doesn't set any rules. It repeats the rules that exist elsewhere. No content policy has ever required a citation anywhere on the page for everything; citations are only required for certain kinds of content. (Depending the subject area and your personal POV about what's Wikipedia:Likely to be challenged, the amount of content required to be cited could be anywhere from 10% to 95% of article content, but the requirements are for specific kinds.)

Every time a citation is required by a policy, the policy requires an inline citation. You can think of this as an accidental happenstance, but it's what we've got. Consequently, according to policy (and accurately reflected in MINREF), there are two kinds of content: content that is required to have an inline citation (e.g., contentious matter about BLPs), and content that is not required to be cited at all (e.g., "The capital of France is Paris"). WhatamIdoing (talk) 23:08, 8 June 2023 (UTC)

• This sounds like a case where tagging is more appropriate than removal. Yes, each article needs to stand on its own regarding Verifiability and citations, but we should also assume good faith (at least initially) that the information is properly cited at the linked articles. So… instead of removing… what needs to be done is to copy those citations from the other article into the table. Now, if it turns out that this can’t be done (ie the linked article does not actually contain an supportive citation to copy over)… THEN we can talk about removing information from the table. Blueboar (talk) 23:27, 1 June 2023 (UTC)

Note: the reason WHY we need to copy the citations into the table is that our articles are never set in stone. The linked article might undergo a complete re-write at some future date… and the citation that supports the information in the table might be not be included after that future re-write. That would “orphan” the information in the table. Blueboar (talk) 23:34, 1 June 2023 (UTC)

In the case of what awards a film has received, yes it absolutely needs to be referenced and shouldn't have been restored per WP:BURDEN. The awards a film has received is obviously not WP:BLUE or non-controversial, and the references in the award article are not good enough. Vandals regularly target awards and having to verify each award in the award article isn't acceptable. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:43, 2 June 2023 (UTC)

But... if that really concerned you, then why didn't you just copy the sources over from the linked articles yourself? It probably would have been faster, and it certainly would have won you more friends. WhatamIdoing (talk) 00:41, 6 June 2023 (UTC)

The burden to do so is with the editors wishing to keep the content, as you well know. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 10:24, 6 June 2023 (UTC)

Sure, but standing on your inalienable right to remove good content is not a way to win friends and influence people. Wikipedia is a community, not just an article. WhatamIdoing (talk) 22:59, 8 June 2023 (UTC)

@Robert McClenon: I have never edited the page in question, thus am uninvolved. As sympathetic to table inclusion as I am, one argument in its favor – "the Awards table has been up for a very long time and has hitherto been unchallenged." – reminds me of Wikipedia:Arguments to avoid on discussion pages, specifically WP:UNCHALLENGED aka WP:CONTENTAGE: "While WP:Consensus policy reminds us that any undiscussed edit that is not disputed by later can be assumed to have consensus, the act of challenging it (in good faith) removes that default assumption, by definition. 'It's been here a long time' does not equate to 'it has had actual consensus for a long time'. [...] There is a big difference between material that, on the one hand, someone simply inserted and no one bothered to talk about until now, and, on the other, material that has been repeatedly challenged and retained (by source- and/or policy-based consensus, not a false consensus)." One specific example given, of an argument to avoid, is: "Has remained in the article for 6 years already and no one has challenged it." [emphasis added] – .Raven  .talk 06:32, 4 June 2023 (UTC)

I believe such tables should be sourced. I wouldn't add an unsourced award to a table. To add a citation needed tag and then remove it a few weeks later if no citation was added might be solution, this practice I have also observed in other articles. There is likely no consensus to prohibit unsourced tables, even though I'd welcome that every table is sourced. Paradise Chronicle (talk) 08:46, 4 June 2023 (UTC)

There is no reason for contents of a table to be any different than any other contents; that is, citation needed tags can and most certainly should be added for an uncited Awards table. What exists in other Wikipedia articles is irrelevant. (And WP:MINREF is neither policy nor guideline, but that's off-topic here.) SandyGeorgia (Talk) 23:16, 8 June 2023 (UTC)

I'm not sure why anyone is having difficulty with the policy on this. "All material in Wikipedia mainspace, including everything in articles, lists, and captions, must be verifiable. All quotations, and any material whose verifiability has been challenged or is likely to be challenged, must include an inline citation to a reliable source that directly supports the material." And other policies like BLP also add some categories of information that must have a cited source. But there is no policy that all information in the 'pedia must have a source cited; it simply has to be verifiable, i.e. it has to be possible to create a source citation that backs it up. Otherwise, we'd have to delete literally tens of millions of statements from Wikipedia.  — SMcCandlish ☏ ¢ 😼  17:22, 16 June 2023 (UTC)

RFC

I thank all of the editors who have offered their comments on the issue. The two editors are as far apart as they were when the discussion at DRN began, so I will be starting an RFC on whether the table should be removed or kept. If a third editor pops up and provides sources for the awards, that will render the RFC overtaken by (useful) events. Robert McClenon (talk) 07:39, 4 June 2023 (UTC)

I have launched the RFC. Participants in this discussion are welcome to add their opinions and statements to the RFC on the article talk page. Robert McClenon (talk) 15:52, 4 June 2023 (UTC)

A third editor, User:Schazjmd, popped up and provided sources for the awards, which rendered the RFC overtaken by useful events. The RFC served a secondary purpose of publicizing the need of the table for references. Robert McClenon (talk) 17:15, 5 June 2023 (UTC)

@Robert McClenon can you link to the RfC? Paradise Chronicle (talk) 03:49, 6 June 2023 (UTC)

User:Paradise Chronicle - It is/was at Talk:The_Adventures_of_Priscilla,_Queen_of_the_Desert#RFC_on_Table_of_Awards. It has been closed because the table now has sources. Robert McClenon (talk) 05:59, 6 June 2023 (UTC)

Would have reasoned similar. Sourced content is preferable to unsourced. Paradise Chronicle (talk) 08:13, 6 June 2023 (UTC)

WP:ANI polices and guidelines

Are there specific policies and guidelines that pertain to conduct and editing behaviors at WP:ANI? I didn't find this particular question in the searches. ---Steve Quinn (talk) 08:18, 6 June 2023 (UTC)

I also meant to say, that I have been unable to find policies and guidelines specific to ANI. As far as I can tell, all that is available are policies, guidelines, and often mentioned essays that are applied across Wikipedia. Steve Quinn (talk) 10:12, 6 June 2023 (UTC)

If the participants at ANI would abide by the existing policies and guidelines regarding editor conduct, a lot of the drama would be drained out. Why should we expect additional conduct rules just for ANI to help? Improving the atmosphere at ANI will require a culture change, which is hard to achieve with regulation. Donald Albury 13:10, 6 June 2023 (UTC)

In theory, WP:CIVIL, WP:ETIQ, etc apply on all pages, including ANI. But in practice? Less so. Thebiguglyalien (talk) 16:40, 6 June 2023 (UTC)

No, there's no specific policies for ANI. Policies for a single page are, I think, unheard of. But do read Wikipedia:ANI advice. -- zzuuzz ^(talk) 17:13, 6 June 2023 (UTC)

Yeah, there's a whole book about best practices for ANI participants! jp×g 05:43, 17 June 2023 (UTC)

RfC on MOS:SECTIONCAPS after a colon

Should MOS:SECTIONCAPS recommend that, in a heading, the first letter after a colon is capitalized?

That is, should this example be reversed?

Use: 1891–1940: early history
Avoid: 1891–1940: Early history

Similar past discussions: May 2023, October 2022, March 2022. Wracking ^talk! 05:43, 9 June 2023 (UTC)

• Yes. Nobody follows this guidance, on or off Wikipedia. On Wikipedia, most people already capitalize after the colon. (85% of articles, by my count.) The Chicago Manual of Style and APA style recommend capitalizing after a colon in a heading (yes, even in sentence case). Wracking ^talk! 05:45, 9 June 2023 (UTC)
  • Remove the example/don't specify. Thanks all, for your thoughtful comments. I agree. We really didn't need this example in the first place per WP:CREEP. Wracking ^talk! 18:36, 10 June 2023 (UTC)
• Yes. AP Stylebook as well: Capitalize only the first word and proper nouns in headlines that use AP style. Exception: The first word after a colon is always uppercase in headlines. Hyphenation Expert (talk) 08:02, 9 June 2023 (UTC)
  • Remove, capitals used as is consistent with the page's variant of English Hyphenation Expert (talk) 09:49, 9 June 2023 (UTC)

    The idea that variants of English come with capitalization styles is novel to me. Did you just invent that, or does it come from somewhere? Dicklyon (talk) 16:40, 11 June 2023 (UTC)

    Yeah, I've read nearly every style guide published since the late 19th century, and I've never seen any evidence for such an idea.  — SMcCandlish ☏ ¢ 😼  02:43, 14 June 2023 (UTC)

    UK: don't capitalise.

    The Guardian When a colon is used in a headline, the next word is usually lowercase, eg Osborne: there is no plan B.

    Cambridge Use sentence case for headings and headlines (and also remember to use lower case after a colon)

    Oxford Headlines, journal articles, chapter titles and lecture titles: Only capitalise the first word... ‘Multiplicity of data in trial reports and the reliability of meta-analyses: empirical study’

    ICL Sentence case should be used for headlines and the titles of articles, chapters and lectures... ‘The impact of sleep and hypoxia on the brain: potential mechanisms for the effects of obstructive sleep apnea’ Hyphenation Expert (talk) 01:16, 18 June 2023 (UTC)

    Zero of them say this is a feature of British English, and you can find American style guides that also prefer this capitalization habit. You are mistaking the cross-pollinating habits of a handful of publishers in Britain with an inherent feature of the language of Britian. It's a common error, but still an error.  — SMcCandlish ☏ ¢ 😼  20:35, 18 June 2023 (UTC)

• Don't specify. We don't need a rule about this and we certainly don't need to follow what some American style guides do.—S Marshall T/C 08:45, 9 June 2023 (UTC)

Agreed. No one's reading speed or comprehension is going to be affected by a single capital letter. This specification provides absolutely no benefit to readers and belongs to the WP:CREEP territory. Carpimaps ^{talk to me!} 16:10, 9 June 2023 (UTC)

• US usage varies. The guideline is fine as it is. Tony (talk) 11:49, 9 June 2023 (UTC)
• Treat it as just another WP:STYLEVAR issue. Either is fine, in case of dispute retain whichever variant was first used. 74.73.224.126 (talk) 22:03, 9 June 2023 (UTC)
• Australian government style manual: After a colon, capitalise the first word of questions that are complete sentences. This makes it clear that the question mark applies only to the text after the colon. [1] Hawkeye7 (discuss) 00:40, 10 June 2023 (UTC)

  I wouldn't cite the "Snookbook": it's crappy. Tony (talk) 01:20, 10 June 2023 (UTC)

  There's no such thing as a crappy style guide. Language is whatever people want it to be. The better question is if the style guide unpopular? That's the real issue... I would agree an unimportant, unused style guide's opinion doesn't matter. (but Chicago Manual of Style, regardless of an Australian guide, is pretty damn important regardless.) SnowFire (talk) 17:23, 10 June 2023 (UTC)

  capitalise the first word of questions — Not applicable here, because MOS:SECTIONSTYLE says that "section headings should ... Not be phrased as a question". Mitch Ames (talk) 13:10, 10 June 2023 (UTC)

• No change (the existing "use lower case, avoid capitalisation" is correct). According to Colon_(punctuation)#Use_of_capitals, with my emphasis here, "American English permits capitalisation" but does not require it. Wikipedia's MOS:CAPS says "avoid unnecessary capitalization", use sentence case (and a colon does not start a new sentence) and we should be consistent — Preceding unsigned comment added by Mitch Ames (talk • contribs)
• Remove guidance. Initial capitals following colons are standard, as a quick browse of many published books or Internet sites shows. Wikipedia should follow actual usage, and besides, plenty of perfectly valid style guides explicitly recommend the usage. I'd personally be inclined to reverse the guidance and mandate capitals, but per WP:CREEP, just let the main editor of an article use a consistent style, regardless of what it is. People who prefer the lowercase can be happy that way, just let others use the valid, common, and style-guide approved capital. SnowFire (talk) 17:23, 10 June 2023 (UTC)
• No change for the following reasons:
  1. The existing guidance is marginally simpler (no need to carve out an exception to sentence case for word after colons).
  2. There’s no need to comply with any particular 3rd party style guide - Wikipedia defines its own style and doesn’t need to stick to sources in this respect, unlike for article content. This is not to say we should completely ignore best practice in sources, but they are a weak influence. There’s every chance that we are the experts for our use case and will come up with better guidance than any external style guide.
  3. Change may prompt a flurry of rather pointless edits to achieve “compliance”.
  4. There does seem to be some (very) slight advantage to the existing guidance: Linking is easier if titles are in sentence case. It is easier for articles to be merged or split if headings resemble titles.
  5. There’s so little difference either way that my second choice after no change would be to remove the guidance completely and leave it to local consensus. Barnards.tar.gz (talk) 18:38, 10 June 2023 (UTC)
• Remove guidance , unnecessary rules creep with no demonstrated strong advantage. It is also good to remove rules in the MoS that go against common usage and real world style manuals. —Kusma (talk) 18:43, 10 June 2023 (UTC)
• Remove. No need to have MOS guidance on post-colon capitalisation if nobody follows it anyway. Can be revised if situation changes. Alpha3031 (t • c) 03:50, 11 June 2023 (UTC)
• Do specify - There have been several suggestions to ""remove guidance", but I propose that we should have an example or explicit guidance in any case: either a specific example, or an explicit statement that either is acceptable (so MOS:STYLEVAR applies). The reason:
  1. MOS:CAPS and MOS:SECTIONCAPS already say "sentence case", and - in the absence of any other specific guideline - from that one can reasonably deduce that lowercase "1891–1940: early history" is both correct and mandatory. (The text following a colon is not a new sentence.)
  2. Multiple other style guides say "capitalise" and that is (apparently) common practice already on Wikipedia and elsewhere.

If we don't explicitly specify one, or explicitly state that either is acceptable, we run the risk of ongoing disagreement between those who assert that lower case is implicitly required by MOS:CAPS, MOS:SECTIONCAPS (and they could legitimately uncapitalise existing instances because STYLEVAR does not apply, because CAPS, SECTIONCAPS is clear), and those who assert that capitalisation is OK, or even necessary (because of common practice). Mitch Ames (talk) 06:32, 11 June 2023 (UTC)

STYLEVAR applies whenever there is no specific guidance; it would be neither practical nor desirable to list out every single case where it applies, even if occasionally we do so because some specific point has become particularly contentious. 74.73.224.126 (talk) 21:28, 12 June 2023 (UTC)

• Such a change would violate the sentence case we've had for two decades on WP. Tony (talk) 07:11, 11 June 2023 (UTC)
  • Yes, it would change an old rule. But it would change an old rule that most people already don't follow. Wracking ^talk! 17:54, 11 June 2023 (UTC)
    • Most people don't follow any of the capitalization rules. They create new articles with title-case titles, and populate them with title-case headings, and capitalize what's important to them. Those things get noticed and fixed by gnomes like me. I hadn't done much on this particular pattern yet, but I might try taking it on (the trouble is that the thing after the colon in the heading has to be looked at carefully, case-by-case, to see if it's a proper name or not, so this will be slow). Dicklyon (talk) 23:24, 11 June 2023 (UTC)
      • I provided a source when I said "most people do X", so I'd ask that you do the same. :] Capitalizing after a colon while maintaining sentence case is not the same as unexperienced users improperly using title case. My guess would be that most gnomes don't notice this "issue" because they don't know the rule exists—and they don't know the rule exists because it's unintuitive (going against other prominent style guides). And if they do know the issue exists, I think they don't want to devote their time to its (as you noted) tedious mending. Wracking ^talk! 01:46, 13 June 2023 (UTC)
    • @SchreiberBike: for example fixed the ": Early years" to ": early years" at Charlie Chaplin in 2021. Nobody gave it a mention or touched it since. Dicklyon (talk) 23:44, 11 June 2023 (UTC)
• No The proposal is to mandate capitalisation after a colon in section headings. While some styles guides might advocate this, it is far from being consistent and one must also consider whether such guides would advocate sentence case or title case for section titles. MOS:COLON specifically deprecates capitalisation after a colon with few exceptions, of which this would not be such a case. Removing the guidance at MOS:SECTIONCAPS would create an inconsistency with the superior guidance and with the overarching principle at MOS:CAPS to avoid unnecessary caps. It is not shown that the proposal falls to a case of necessary caps. I am seeing no cogent (evidence based) arguments to change the existing guidance and sound reasons to retain. Cinderella157 (talk) 10:32, 11 June 2023 (UTC)
  • For clarification, the guidance I cited is specifically for sentence-case display text such as titles and headings, not body-text sentences. Wracking ^talk! 17:54, 11 June 2023 (UTC)
    • My first sentence makes it quite clear that I have understood the proposal. The rationale I give is that the proposal would be inconsistent with superior guidance, which applies generally and not specifically to just body text. Cinderella157 (talk) 23:12, 11 June 2023 (UTC)
      • Sorry for misunderstanding you, thanks for explaining. This was a point of confusion in the past. Wracking ^talk! 01:46, 13 June 2023 (UTC)
• No, leave it – There are many different reasons for why people do not always follow the guidance, e.g. to use sentence case in headings, but mostly it's just that they aren't aware. Having this guidance as a reminder for a common error case is useful, and guides that who want to move toward consistency. It's not clear what kind of simple rule could replace what we have and expect more people to do the right thing; sentence case except after color is just arbitrary and awkward, and inconsistent with out general guidance of avoiding unnecessary capitalization. Dicklyon (talk) 23:20, 11 June 2023 (UTC)
• Comment - I'd recommend no changes be made in any pages, concerning this uppercase/lowercase topic. Until this RFC's decision is rendered. GoodDay (talk) 00:04, 12 June 2023 (UTC)

  Was that comment in reaction to the edits I made shortly before? I fixed case after years with colons in 3 high-profile articles, not just because the guideline says to, but also to test the waters and see if any of the many editors of those articles notice or care; you can look at my contribs it you want to see which, but please do not revert to the un-preferred state. Dicklyon (talk) 15:28, 12 June 2023 (UTC)

  I went ahead and fixed another dozen or more prominent articles with "Early years" after colon, including about a hundred other headings with caps after color, and also a few dozen with fully over-capitalizaed "Early Years" after color. Pretty much no reaction, except one editor who reverted a few and then read the guideline and self-reverted. This little test seems to make it clear that editors generally don't mind the WP style of avoiding unnecessary capitalization, and that they're often just not aware, and that moving in the direction suggested by guidelines is a good way to make things more consistent. Dicklyon (talk) 23:11, 17 June 2023 (UTC)

  @Namdor67: OK, I finally provoked a notice and revert here, by a 5-weeks-new editor, with edit-summary argument Case is correct. Refer to any footballer with section titles, Messi, Ronaldo,Trent Alexander-Arnold and so on... Now, I'm pretty sure this is not really a styling question about footballers, nor about sports, but this kind of domain-specific over-capitalization is pretty well known to us, having been discussed extensively recently at WT:MOSCAPS. — Preceding unsigned comment added by Dicklyon (talk • contribs) 21:33, 20 June 2023 (UTC)

• No change: continue in sentence case for consistency with treatment of colons within the text. Certes (talk) 19:53, 12 June 2023 (UTC)
• Remove guidance. As long as articles are internally consistent that's all that matters for something so completely trivial as this. Thryduulf (talk) 23:16, 12 June 2023 (UTC)
• No change. I've thought about this (see original WT:MOSCAPS thread), and the reason that some other style guides do this is they are treating each element as a "title" and giving it sentence case independently. WP even does this (usually) with sentence-case citations of articles with a title and a subtitle (|title=Mammal barbering: Proper procedure for shaving weasels). However, WP headings are headings, they are not article titles; "Colour: palettes and meaning" looks kind of ridiculous as "Colour: Palettes and meaning", and makes the reader wonder why "Palettes" is capitalized. "Is it a proper name? Is this some kind of emphasis?" Capitalizing after a colon is fussy as well as potentially confusing, half of editors won't do it, and changing to that style would involve a tremendous number of twiddly edits to probably a hundred thousand+ pages (WP:MEATBOT?). I agree with Dicklyon above that current advice is consistent with MoS's general avoidance of capitalization that is not necessary. I am quite certain we should keep a rule on this, as just the heat in this discussion makes it clear that certain individuals feel very strongly about this, which means people will editwar about it if there is no rule. MoS's two purposes are presenting consistent content to readers, and forestalling (or at least quickly ending) repetitive "style fights" among editors.  — SMcCandlish ☏ ¢ 😼  02:24, 14 June 2023 (UTC)

  STYLEVAR is a thing. We don't need MOSBLOAT; if people start to editwar, whichever style was used first controls. 74.73.224.126 (talk) 14:11, 14 June 2023 (UTC)

  The very fact that this RfC is an ongoing heated fight about the matter (and not the first one) is a clear indication that we do need a specific rule on it, even if it's rather arbitrary..  — SMcCandlish ☏ ¢ 😼  20:37, 18 June 2023 (UTC)

• Remove guidance - No reason for having a guidance that everyone ignores and that goes against standard style guides. : Alexcs114 :) 16:12, 17 June 2023 (UTC)

  So the cited style guides that are like ours and suggest lowercase are not "standard"? Or you just didn't notice that such guidance, matching ours, is not uncommon in style guides? See refs and above.Dicklyon (talk) 21:35, 20 June 2023 (UTC)

• Allow both as acceptable MOS:STYLEVAR. Between removing the guidance and explicitly noting that both examples are valid, I agree with Mitch Ames that we should explicitly say so, given that it has been the subject of significant discussion. But 74.73.224.126 is of course also correct that removing the guidance would mean MOS:STYLEVAR applies no less. Adumbrativus (talk) 06:00, 23 June 2023 (UTC)

References

Defunct companies: can they stay in the company section of a navbox or not?

I've noticed someone has moved an article for a company which went defunct in 2019, from the company section of a navbox, to the miscellaneous section of a navbox, where it looks out of place next to crime, history, military, timeline, and geology.

Can I move it back to the company section? Danstarr69 (talk) 06:34, 9 June 2023 (UTC)

I would say that this is an incredibly vague question with no context, so it's difficult to say. Gun to my head, I don't know why it would've been removed from the company section in the first place. I would probably move it back. - AquilaFasciata (talk | contribs) 14:56, 9 June 2023 (UTC)

Here is some more context: Wikipedia:Teahouse#Defunct_Companies_-_Can_they_stay_in_the_Company_section_of_a_navbox_or_not? RudolfRed (talk) 19:23, 9 June 2023 (UTC)

• I would definitely reverse it. We navboxes for a reason. Greenwood's page is missing history like it's ownership of stores like Busbys in Liverpool.Davidstewartharvey (talk) 16:58, 11 June 2023 (UTC)

New RfC on Wikipedia talk:Manual of Style/Gender identity

I created a discussion and a RfC regarding pronouns of AIs, chatbots, etc. I would appreciate if other users gave their two-cents on the subject. The discussion can be found here. Thanks, Di (they-them) (talk) 04:09, 12 June 2023 (UTC)

RfC: Proposed addition to MOS:GENDERID - when to include deadnames

Should the following text be added to MOS:GENDERID, inserted before the fourth paragraph? Sideswipe9th (talk) 22:01, 12 June 2023 (UTC)

For a deceased trans or non-binary person, their former name should only be included if the encyclopaedic significance of the deadname is established through in-depth analysis or discussion of the name in high quality sources, or if they were notable prior to transitioning. Introduce the former name with either "born" or "formerly". For example:

• From Leelah Alcorn: Leelah Alcorn (November 15, 1997 – December 28, 2014) ...
  Note: While Alcorn's gender identity is discussed in significant detail in high quality sources about her, her former name is not.
• From Gloria Hemingway: Gloria Hemingway (born Gregory Hancock Hemingway, November 12, 1931 – October 1, 2001) ...
  Note: Hemingway's struggles with her gender dysphoria, and relationship with her gender identity, gender expression, and name are discussed in significant detail in sources about her life.
• From Danielle Bunten Berry: Danielle Bunten Berry (February 19, 1949 – July 3, 1998), formerly known as Dan Bunten, ...
  Note: Berry was notable prior to transitioning.

Notes

Background (GENDERID addition)

A recent RfC closed with the consensus that the community believes that, for the most part, the prior name [of a deceased trans or non-binary person] should not be used. However, the community fell short of finding a consensus for a specific phrasing based on the options presented. The purpose of this RfC is not to re-litigate the previous RfC, but to find consensus for a phrasing that reflects the closure of the previous RfC, namely that previous names of deceased trans or non-binary people should have some relatively high but not absolute barrier to their use. Loki (talk) 23:09, 13 June 2023 (UTC) based on wording proposed by Sideswipe9th below

Survey (GENDERID addition)

• Support as proposer While the previous RfC did not find consensus for the proposed options, it was remarked in the closing that it is clear that the actual consensus lies somewhere between option 2 and option 3, and that there is clear consensus that a former name is not automatically of encyclopedic interest. This proposal builds upon the wording of the closure, by setting out two inclusion criteria for when a former name of a deceased trans or non-binary person could be included in an article: that the deadname is of clear encyclopaedic significance based on in-depth coverage or discussion in high quality sources, or if the person was notable prior to transitioning. Explicit links are made to the WP:NOTEVERYTHING and WP:BESTSOURCES policy points, with the intentional effect of tying this guideline to both the What Wikipedia is not and Neutral point of view policies.
  With regards to the specifics of the closure, this sets the bar for inclusion at a level that is both lower than never (option 3) and higher than sometimes (option 2). It fulfils the consensus that articles should not routinely include the deadnames of deceased trans or non-binary individuals, while giving specific policy based guidance for what the inclusion criteria are. Finally it provides three examples of the applications of the inclusion criteria.
  While I had hoped that we would be able to find a consensus for inclusion through a discussion at WT:MOSBIO, it seems as though a clear consensus for or against this proposal is not emerging and an RfC is necessary. Finally, while the examples give what I believe to be clear applications of how those articles could meet the proposed criteria, they are not perfect. If better examples are found, either during the RfC or after, I don't think there should be any objection to substituting those in as they otherwise would not alter the scope of the proposal itself. Sideswipe9th (talk) 22:01, 12 June 2023 (UTC)
• Oppose - WP:BLP adequately covers the issues of former names, quality of sources, privacy issues, and transition time of the deceased. Specifically, WP:BLPNAME for privacy of names and WP:BDP for the continuing privacy of recently deceased. I would support a proposal to specifically recommend extending the range of privacy concerns to the maximum recommended for the special case of transgender individuals, but not indefinitely. Cuñado ☼ - Talk 22:55, 12 June 2023 (UTC)

  Extending BDP to its maximum of two years would still leave us in a situation where in the lack of other specific guidance and once that time period has elapsed, the deadnames of deceased trans or non-binary individuals who were not notable prior to transitioning could be routinely included. Such a situation would be against the clear consensus that a former name is not automatically of encyclopedic interest that was established just under a week ago. Sideswipe9th (talk) 23:02, 12 June 2023 (UTC)

  It's a blog (inherently non-RS), but this addresses the concerns many trans people have that their life choices will not be respected after their deaths. Two years is long enough to wear away the lipstick marking Wanda's name from the gravestone engraved "Alvin". – .Raven  .talk 23:57, 12 June 2023 (UTC)

  This oppose should be given no weight by the closer, as it is explicitly at odds with the result of the above previously closed RfC. This discussion here is not to re-tread the arguments made there, but to determine the specific language in the MOS in order to enact the result of the RfC. Silverseren^C 23:58, 12 June 2023 (UTC)

  I think you should focus on the merits of your argument and not turn to authoritarianism. Cuñado ☼ - Talk 03:18, 13 June 2023 (UTC)

  WP:DISCARD. – .Raven  .talk 04:00, 13 June 2023 (UTC)

  Nothing there would justify throwing out my comment about BLP. Cuñado ☼ - Talk 04:31, 13 June 2023 (UTC)

  What justifies "throwing out" the conclusion of the prior RfC less than a week ago? – "With around a hundred editors responding across these RFCs taking place at VPP, it is obvious that there is a consensus against using the former names of transgender or non-binary people, living or dead, except when of encyclopedic interest or when necessary to avoid confusion. Also, there is clear consensus that a former name is not automatically of encyclopedic interest." [emphasis in original] – .Raven  .talk 07:33, 13 June 2023 (UTC)

  WP:DISCARD is an info page, not policy/guide, and even that does not say to throw out my comment. It says a closer may discard arguments that, flatly contradict established policy, those based on personal opinion only, those that are logically fallacious, and those that show no understanding of the matter of issue. So, if anything, most of the comments on the last RFC should have been thrown out as personal opinion that flatly contradict established policy, but certainly not this one. Again, try making good arguments that are based on policy. You are proposing expanding an exception to WP:NOTCENSORED and acting like people who don't agree with you are violating policy, when they're not. You are WP:RGW, and I hope the closer has some sense. Cuñado ☼ - Talk 15:35, 14 June 2023 (UTC)

  And WP:LISTEN is a behavioral guideline. Don't relitigate the closed RfC from just a week ago; respect that consensus. Here we are in fact following that closure's recommendation: "Where, exactly, the lines of encyclopedic interest and avoiding confusion are is not simple or clear and will likely need discussion...." That is the topic of this discussion. – .Raven  .talk 16:36, 14 June 2023 (UTC)

  Cuñado you're repeating arguments you already made in the previous RfC on 7 May 2023 and 31 May 2023. By definition that is re-litigating the same points. If you have a specific reason for why this proposal doesn't fulfil the requirements of the existing consensus from a week ago, by all means make contributions on those points. But simply rehashing the same arguments you made previously is not helpful here. Sideswipe9th (talk) 17:26, 14 June 2023 (UTC)

• Support per proposer, although I would prefer "...notable under that name" rather than "...notable prior to transitioning" as transitioning is a process not a moment in time and at what point in the process people choose a new name varies; and also people can have multiple names - for example someone may have extremely private birth name, a different name under which they became notable but before they transitioned and a post-transition name under which they are notable, our article should include the latter two but not the first. However, while not perfect the proposal is better than the status quo. Thryduulf (talk) 23:12, 12 June 2023 (UTC)

  I think that might've come from me. based on your reasoning, I agree that it's imperfect, but I think time has to be taken into account. When I was researching prior discussion in preparation for the last RFC, I saw a few arguments that, effectively, went like this: If a person became notable after transitioning but was widely noted or principally identified by their former name, the person was notable under that name.

  When I drafted the last RFC, I substituted that for "notable prior to transitioning" because I felt doing so was necessary to emphasize the difference between option 2 (which focused, in part, on how the media covered the person) and option 3 (which rejected such focus and said the deadnames of persons not notable prior to transitioning should not be used). To put it clearly: Option 3 was supposed to be a "never include" option, but I worried that, if it used the "notable under that name" language, it would be interpreted as a "sometimes" under the argument I mentioned above.

  Perhaps "notable prior to discarding that name" would have been the better choice?--Jerome Frank Disciple 17:50, 13 June 2023 (UTC)

  I agree that we should differentiate between the subject's use of their birth name and other sources use of it. I think that's a good option, but I would have a preference for something like "notable prior to adopting their new name" as I think it's possible people will say you need to find a reliable source to support that they are no longer going by their birth name in addition to a reliable source supporting the use of their new name. of course, the implication when someone starts using a new name is that they are no longer using their old name, but I'd like to make it as unambiguous as possible. Tekrmn (talk) 16:23, 15 June 2023 (UTC)

  That works for me!--Jerome Frank Disciple 17:44, 15 June 2023 (UTC)

  If the rest of this proposal finds consensus, with one exception I don't think there'd be much issue swapping to "notable under that name", as it would mirror the existing language already present in GENDERID's third paragraph. I would be a little concerned that "notable under that name" would be a backdoor for a "name is verifiable from an obituary, so we must include" type argument that was already rejected by the previous RfC. Maybe that could be addressed in the footnote though with a small addition to the first sentence that verifiability alone is not enough for inclusion?

  I do think Tekrmn's "notable prior to adopting their new name" is maybe a better way to phrase this concept. It raises the barrier above mere verifiability, and puts it in line with the practice of GENDERID's third paragraph, if not the letter of it. Sideswipe9th (talk) 18:34, 15 June 2023 (UTC)

• Support, ideally but not necessarily with Thryduulf's proposed amendment, as the most accurate and precisely worded version of the consensus from the previous three RFCs that anyone's proposed so far. (As a side note, I'd support pinging everyone who voted in that RFC, since this RFC is a clear follow-up to that one.) Loki (talk) 23:44, 12 June 2023 (UTC)
• Oppose The addition, and particularly the established through in-depth analysis or discussion of the name in high quality sources wording, will just lead to tendentious wikilawyering and unnecessary WP:CREEP. Under this proposal, the notable deadname of the Nashville school shooter would've been excluded from the article from the very beginning, and editors who try to add the name would've been reverted and pointed to this guideline in the MOS. If an overwhelming number of reliable sources use and report the deceased shooter's birth/deadname, it shouldn't take an uphill battle to include that name in the article. Some1 (talk) 00:53, 13 June 2023 (UTC)

  The deadname of the shooters was discussed in high quality sources, so if we adopted this change to the MOS nothing about that article would change. I don't think that would have been a lengthy discussion either, unlike the incredibly lengthy discussions that were had about not using his deadname to refer to him throughout the article, not misgendering him throughout the article, where to include his deadname, etc, which included a lot of reversions in all directions, and has landed us with an article that still overemphasizes his birth name and his transness in ways that are out of line with the MOS. I do not think including deadnames where relevant is ever going to be an uphill battle the way excluding them where they aren't relevant is. Tekrmn (talk) 16:39, 15 June 2023 (UTC)

  I've only checked twenty of the sources in that article so I may have missed something, but I'm not seeing any in-depth analysis or discussion of the name; the name is mentioned in every article, but a mention doesn't meet that standard. This is where my concern about the wording comes from; it is overly restrictive and per the examples given doesn't appear to align with the intent. BilledMammal (talk) 16:52, 15 June 2023 (UTC)

  I'm not attached to the wording in this proposal but I do think that if you take into account the context of the existing MOS this isn't really a concern. the MOS currently says "Where a person's gender may come as a surprise, explain it on first occurrence, without overemphasis." the fact that almost all of the reporting on the shooter referred to him by his deadname indicates that the inclusion of his deadname is necessary. I'm not going to go dig up the sources, but we also would not have sources saying he went by Aiden if we didn't have sources discussing his name change.

  to some extent, as long as we allow for the inclusion of deadnames in a way that allows for /any/ interpretation, the deadname will almost certainly be included in ways that are gratuitous for the article in question, so to me it does make sense to err on the side of more restricting. Tekrmn (talk) 19:44, 15 June 2023 (UTC)

  the fact that almost all of the reporting on the shooter referred to him by his deadname indicates that the inclusion of his deadname is necessary - I agree. The issue is that we would be forbidden from doing so by this policy, as to the best of my knowledge there are no sources providing in-depth analysis or discussion of the name, and I would be very surprised if such sources did exist. BilledMammal (talk) 19:57, 15 June 2023 (UTC)

  Aiden Hale is somewhat of an unusual case. Had he survived, we would have found ourselves in the situation where the second paragraph of GENDERID would have unambiguously applied. At the time Hale started shooting, he was using the name Aiden, and regardless of whatever sourcing existed we would have used only that name in our article per the existing guideline.

  However that is not the circumstances we find ourselves in. I've explained my thinking in more detail in this reply at WT:MOSBIO, but in short I believe that the circumstances surrounding the publication and use of Hale's former name is one that is best handled through an application of the WP:IAR policy. The American legal maxim of hard cases make bad law applies here, as the circumstances involved make this a very hard case to handle with any degree of respect and care. Trying to address the specificities of Hale's case in this guideline would necessitate us setting the bar significantly lower than the consensus afforded by the previous RfC, and would be too permissive a barrier for inclusion for the vast majority of uncontroversial articles. Sideswipe9th (talk) 20:12, 15 June 2023 (UTC)

  @Sideswipe9th, LokiTheLiar, and -sche: If this was the only exception I would agree with you that it could be handled by IAR, but it isn't. So far in this discussion two examples have been provided where everyone agrees the former name should be included - Aidan Hall and Gloria Hemingway - but in both of these examples it appears that the proposed policy would prevent us from including them.

  In fact, I am struggling to think of circumstances where it would permit us to include the name; I'm not even convinced that it would permit us to include Jemima Wilkinson at Public Universal Friend, as while her preferred name has recieved such analysis I have been unable to find any for her former name. As written, the proposal is far too restrictive; requiring occasional exceptions is acceptable, but requiring them most or all of the time is not. BilledMammal (talk) 14:17, 16 June 2023 (UTC)

  @BilledMammal: Not saying I agree with you, but if, as you say, the barrier for inclusion is set too high, where then would you set it? Would Trystan's proposed amendment of is established through discussion of the name in high quality sources be suitable for you?

  Please bear in mind that, per the previous RfC the level has to be set high to account for there is a consensus against using the former names of transgender or non-binary people, living or dead, except when of encyclopedic interest or when necessary to avoid confusion. Also, there is clear consensus that a former name is not automatically of encyclopedic interest. Any barrier that would allow the inclusion of Hale's former name outside of IAR would be too low, as it would require a straight "majority of sources", which has explicitly been rejected per the existing consensus. So where exactly would you set the barrier? Sideswipe9th (talk) 16:28, 16 June 2023 (UTC)

  Replies moved to #Discussion (alternatives) BilledMammal (talk) 17:20, 16 June 2023 (UTC)

  (e/c with Sideswipe9th, who I see has said much the same thing as this:) I don't know that argument-by-extreme-edge-case is persuasive; we're also technically forbidden by the same Manual of Style from saying Mein Kampf has "racist" content or that Rocky Suhayda is a "neo-Nazi", but as other editors argued when I raised that issue, and as I would say here, trying to base policies and guidelines on the most exceptional "extreme cases make[s] bad policy". In the same way we've managed, despite the zealous enforcement of MOS:WTW, to still say Mein Kampf has racist content and Suhayda is a neo-Nazi, I trust our ability to treat extremely exceptional cases in exceptional ways here, too; if we don't need to rewrite policy to explicitly caveat "you can't say someone is a neo-Nazi unless they're the leader of the Nazi Party", we don't need to spell out "don't use a deadname that hasn't been discussed in depth unless the person only transitioned unbeknownst to most people shortly before committing a crime and then dying, leading most sources to stick with the only name they were aware of"; the exceptional extreme cases are what IAR is for. -sche (talk) 20:33, 15 June 2023 (UTC)

  Agreed with both of these replies. Aiden/Audrey Hale is the epitome of "hard cases make bad law". What harder case could there be than someone for whom even the basic fact of whether they meant to transition at all is ambiguous, who is notable for the same event in which they died making their wishes fundamentally unknowable, where that event is a mass murder they committed, and who was simultaneously referred to primarily by their legal name but whose transition was also widely reported?

  We are probably never going to get a case that ambiguous and so we really shouldn't design policy to handle it cleanly. Cases like that are the whole point of WP:IAR. Sometimes, even after you design a policy that handles 99% of cases cleanly, you get a 1%er. Perfect policy is impossible and attempting it is an enemy of good policy. Loki (talk) 00:44, 16 June 2023 (UTC)

• Support seems a very reasonable standard that only allows using the name when it is of encyclopedic interest. Definitely prefer "notable under that name" rather than "prior to transitioning", which matches the wording in the living section of MOS:GENDERID. Galobtter (talk) 05:25, 13 June 2023 (UTC)
• Oppose per Some1. Apart from introducing special privileges for sourcing to a single group, this also deliberately introduces further argument points for reliable sourcing. "High quality" is another subjective determination, let alone the requirement of 'in depth analysis and discussion'. The simple and relatively common example of someone's published work under their prior name would fail those, as sources rarely do that level of discussion/analysis on specifically their name. It's setting the inclusion criteria to a level that will be functionally unachievable, on the basis of an ideological starting point rather than the goal of a comprehensive encyclopedic article. If the goal is to prevent their prior name ever being used, the wording above is certainly suffices, if the goal is to provide a MOS guideline on the appropriate context? It fails miserably. The MOS is a style guideline, it is subservient to our actual policies. If we start including proscriptive content rules that directly come into conflict with policy, it will be ignored. Only in death does duty end (talk) 07:13, 13 June 2023 (UTC)

  > "special privileges for [...] a single group" – Oh, where have I seen/heard that phrasing before? – .Raven  .talk 07:36, 13 June 2023 (UTC)

  You could always say what you actually mean. Or perhaps you can't because they would be unsupported allegations which our editing rules prohibit, but sadly do not explicitly disallow cowardly snide insinuations. Only in death does duty end (talk) 09:00, 13 June 2023 (UTC)

• Oppose. It's a lot of extra policy wording for what is essentially a restatement of WP:WEIGHT. We have determined there is a consensus that a former name is not automatically of encyclopedic interest, and so inclusion of the former name must be justified by analysing and weighing sources. This is surely business as usual for all content? Barnards.tar.gz (talk) 07:46, 13 June 2023 (UTC)

  Having read the other responses, I should clarify two points:

  1) I concur with the in-depth analysis or discussion bar being inappropriate. You could interpret it strictly, in which case it's too high a bar, or you could interpret it broadly, in which case it's no different to the normal process of analysing and weighing sources.

  2) On the question of whether the scope of this RfC should be restricted to finding a result between Option 2 and 3... I can see quite a few people voting in this RfC that didn't vote in the previous one, so although it seems implausible that consensus can change in a matter of weeks, it's quite plausible that consensus can change when the voters are different. If this RfC attracts a substantially larger number of voters than the previous RfC, one could even argue that it has the power to overturn the previous consensus completely. A ratchet effect is probably not healthy. Barnards.tar.gz (talk) 10:45, 24 June 2023 (UTC)

  In theory you're absolutely right, however in practice it is very difficult to reach that consensus about this on any given article. having this guideline that specifically refers to name changes will save a lot of time on those conversations. this change is being proposed because a lot of editors agree that this is a problem, so I don't think it's as redundant as it may seem. I also don't think the fact that it seems redundant is a great reason to oppose it. we have existing policies and guidelines that restate the same concepts in different contexts for similar reasons, I am not privy to the exact reasons why that is the case for other things, but I think it's generally good practice to recognize that redundancies in policy and guidelines were put there as a result of a lot of work for specific reasons. Tekrmn (talk) 19:57, 15 June 2023 (UTC)

• Support The intent is to align Wikipedia's editorial policy with the best practices which the organized LGBT+ community recommends. Wikipedia's style guide should bend, comply, and conform to the wishes of communities who assert wishes for how they want to be represented. There is still debate among LGBT+ commentators about how to do this, and we can tweak the wording, but this proposal is another improvement. Bluerasberry (talk) 11:36, 13 June 2023 (UTC)

  Wikipedia's style guide should bend, comply, and conform to the wishes of communities who assert wishes for how they want to be represented. — No. Following the broad principles of:

  WP:NOTCENSORED, whereby we do not remove information about an organizations (group of people, communities) just because that group does not like it

  MOS:ISLAM, whereby we don't confirm to Islam's rules about using "PBUH" and no images

  ASFAQ 8, ASFAQ 14, whereby Wikipedia is not obliged to remove article contents that the article's subject does not like

  We should not "bend, comply, and conform to the wishes of" the people we are writing about, just because they don't like what we said. Mitch Ames (talk) 11:31, 14 June 2023 (UTC)

  This issue affects more than "a community": more broadly, does Wikipedia not abide by name changes? Then we treat others worse than we treat ourselves. (See also.) – .Raven  .talk 16:00, 14 June 2023 (UTC)

  does Wikipedia not abide by name changes? — Which part of "name change" says that others may never mention the original name?

  Then we treat others worse than we treat ourselves — WP:RENAME explicitly says "Existing ... mentions of the old username in discussions are not affected by a rename. Renames appear in the user rename log ... This is done in the interest of transparency." So RENAME does not deny or hide the past, nor should an encyclopedia article on a person who changed their name. Mitch Ames (talk) 08:45, 15 June 2023 (UTC)

  Renames are logged but are only searchable by the original name. That is, you don't necessarily know an account has been renamed unless you know what the old name was, and global rename requests are not visible to non-administrators. The old system was fairly transparent but the new one, not so much. —Rutebega (talk) 05:55, 16 June 2023 (UTC)

  NOTCENSORED says content will be removed it it is judged to violate wikipedia policies, especially BLP. NOTCENSORED isn’t about disregarding the wishes (and safety) of individuals, it’s about not allowing one social norm to take precedence over a conflicting social norm, because that would be in violation of NPOV, or over the values of wikipedia. that’s why we do not adhere to Islam’s rules- it isn’t neutral to praise one religion's deity on every mention, but that’s a very different situation than using a person's preferred name which is a matter of a lot more than censorship and is on an individual level, which is something NOTCENSORED explicitly prioritizes via BLP. this includes the privacy of names, which GENDERID states is even a lesser concern to protecting deadnames. Tekrmn (talk) 20:02, 15 June 2023 (UTC)

  NOTCENSORED says content will be removed it it is judged to violate wikipedia policies, especially BLP. — But mentioning a person's prior name does not violate policies. And for the purpose of this RFC, BLP is irrelevant because the change is to a guideline about deceased people (and makes no mention of "recent"). Mitch Ames (talk) 00:55, 16 June 2023 (UTC)

  BLP has a lot to say about the privacy of names, and as I said in my above comment the existing MOS states that the concern of deadnames is greater than the concerns in BLP privacy of names. from my perspective this means, among many other things, that using someone's deadname does not inherently become appropriate just because they've died. there was a vague consensus on that in the last RFC as well, which is how we got this proposal in the first place. Tekrmn (talk) 02:07, 16 June 2023 (UTC)

  NOTCENSORED is still subservient to WP:NOTEVERYTHING, and we already have a clear consensus that the former names of deceased trans and non-binary people are not automatically of encyclopaedic interest, and that we should only include them when they are of encyclopaedic interest or necessary to avoid confusion. Sideswipe9th (talk) 01:03, 16 June 2023 (UTC)

  NOTCENSORED is still subservient to WP:NOTEVERYTHING — both are policies, neither is "subservient" to the other. But my original point - disputing Bluerasberry's assertion that "Wikipedia ... should bend, comply, and conform to the wishes of [the article subjects]" - stands. NOTCENSORED explicitly contradicts Bluerasberry's assertion, while NOTEVERYTHING does not explicitly cover that assertion either way. Mitch Ames (talk) 01:19, 16 June 2023 (UTC)

  NOTCENSORED explicitly states that it does not apply to anything that is against wikipedia policies. Tekrmn (talk) 02:08, 16 June 2023 (UTC)

  I second Mitch Ames that Wikipedia shouldn't "bend, comply, and conform to the wishes of communities who assert wishes for how they want to be represented" irrespective of the community in question. —CX Zoom[he/him] ^{(let's talk • {C•X})} 13:57, 18 June 2023 (UTC)

  I'll third that notion. Neutrality demands we follow our sources, not the wishes of the subjects (or representative groups of our subjects) of our articles. —Locke Cole • t • c 18:00, 18 June 2023 (UTC)

• Support: While I have some concerns about the precise wording here (though I couldn't come up with an alternative!), I think this proposal is both (1) superior to the status quo and (2) a reasonable extension of the closer's findings as to the last RFC.--Jerome Frank Disciple 11:41, 13 June 2023 (UTC)
• Support I agree this is a reasonable proposal and works well with the close of the last RFC. Nemov (talk) 14:14, 13 June 2023 (UTC)
• Oppose. I think "in-depth analysis and discussion" is too high a bar, and I don't know what "analysis" of a name would look like. I could support "is established through discussion of the name in high quality sources", which is already a much higher standard for inclusion of a former name than the default of mere verifiability. If a name is not just given but discussed in the best available sources, it would also be discussed in an article reflective of those sources, and a name discussed in the article is clearly of encyclopedic significance.--Trystan (talk) 14:26, 13 June 2023 (UTC)
• Support This is a reasonable proposal and provides better guidance to editors. I could also support the language Trystan suggests above - but in any event, the proposal is better than the status quo. Further refinements are possible in the future. Enos733 (talk) 15:07, 13 June 2023 (UTC)
• Why do we need a separate rule about this?—S Marshall T/C 17:09, 13 June 2023 (UTC)

  We have ~2700 words on which small horizontal line to use despite no readers caring or being able to tell the difference. ^{spoiler: it's probably not the one on your keyboard, for some reason} This doesn't seem like a wild amount of clarification. ScottishFinnishRadish (talk) 17:18, 13 June 2023 (UTC)

  As general info, users of Firefox/Thunderbird may find AddAccent helpful, as it makes very many more characters quickly available via keyboard. I can type hyphen followed by one backslash (\) to get ndash (–); followed by a second backslash to get mdash (—); more backslashes give me super- and subscript characters (⁻₋). – .Raven  .talk 05:31, 14 June 2023 (UTC)

• Oppose more updates right now, seems to be getting in to FLOG territory after just running an RFC on this for a month. — xaosflux ^Talk 17:21, 13 June 2023 (UTC)

  In fairness, as Sideswipe9th noted: the closer of the last RFC suggested this route. In the prior RFC, as to whether Wikipedia articles should include the deadnames of deceased persons who were not notable prior to transitioning, there were multiple options presented. Option 1 said "always". Option 2 effectively said "sometimes", suggesting WP:PUA (and consideration of a majority of reliable sources) as providing the appropriate guidance. And Option 3 said "never". (Option 4 said "no change".) As the closer said: "[I]t is clear that the actual consensus lies somewhere between option 2 and option 3. ... I suggest that some language taking into account the responses and concerns be workshopped, and possibly another RFC be held if the language doesn't get consensus through discussion."--Jerome Frank Disciple 17:37, 13 June 2023 (UTC)

  Sure they can suggest it, but the reason it was able to be suggested was because no consensus emerged. — xaosflux ^Talk 17:58, 13 June 2023 (UTC)

  I mean I don't think that's at all consistent with "the actual consensus lies somewhere between option 2 and option 3", but my larger point is that, regardless, it's hardly FLOGGING in light of that finding.--Jerome Frank Disciple 18:01, 13 June 2023 (UTC)

  To add to this, back in August 2021 there was a similar RfC on the inclusion of former names of deceased trans and non-binary people, who were not notable under that former name. Like the RfC that concluded a week ago, there was a split consensus and a recommendation from the closers that a subsequent RfC was held on a narrow subset of the original question. Neither that RfC, nor any other discussion on that specific point was ever held.

  The reason why I feel this implementation RfC is necessary, is because I don't want a repeat of the August 2021 situation, where there is a clear consensus for change with the recommendation of a subsequent RfC that is ultimately never held. With all due respect to your point on FLOG, because this is an RfC for a proposal that implements the existing consensus, and is not framed in a manner that it re-litigates the pre-existing consensus, this is not the case of myself or others flogging a dead horse. Sideswipe9th (talk) 17:59, 13 June 2023 (UTC)

  Honestly, I think the RFC could be framed in a way that makes it clearer that it implements an existing consensus, seeing as we appear to be getting several questions on that point. Loki (talk) 18:55, 13 June 2023 (UTC)

  Would a background section do? (I think Sides mostly captures that background with her !vote, but maybe people are glossing over that)--Jerome Frank Disciple 18:56, 13 June 2023 (UTC)

  If you think a brief note that this is an implementation RfC of an already existing consensus, and not one that's trying to re-litigate that consensus would be helpful, then feel free to add it above the survey section. Not sure if that'd be a background section or just a note or something though. On the whole though I don't think it needs as much detail as the background section in the last RfC. A couple of sentences to a paragraph at the most would suffice. Sideswipe9th (talk) 19:09, 13 June 2023 (UTC)

• Oppose. Copying some comments from WT:MOSBIO, where, as with the previous RfC on this, agreement wasn't reached on what to ask. "there is a clear consensus that the deadnames of trans and non-binary individuals are not automatically of encyclopaedic interest"... a question about whether birth names or former names are of encyclopedic interest wasn't asked in the RfC referenced, so this assertion (albeit it is in the close) is questionable, making it not a sound basis for significant change in a contentious area. As with others, I struggle to understand what "in-depth analysis or discussion of the name" would be, and see the same problames as Some1 and Only in death mention. And why "high quality sources" instead of standard "reliable sources"? That slants things to academic discourse, where analysing a person's names, to the best of my knowledge, is not common. As such, the proposal is much too restrictive, particularly when we already have a policy stating that verifiability does not guarantee inclusion and another policy against censorship. EddieHugh (talk) 19:27, 13 June 2023 (UTC)

  As I noted there, I'd again note here that merely noting "verifiability does not guarantee inclusion" fails to reflect the closer's finding that consensus was between option 2 and option 3, described above.--Jerome Frank Disciple 19:30, 13 June 2023 (UTC)

  so this assertion (albeit it is in the close) is questionable, making it not a sound basis for significant change in a contentious area If you wish to make a challenge to the closure, then I'd suggest following the guidance at WP:CLOSECHALLENGE. Unless and until there is a successful challenge that overturns the closure of the last RfC, either in whole or in part, then that is the determination of the consensus. Sideswipe9th (talk) 19:33, 13 June 2023 (UTC)

  The close stated, in bold, which I've removed: "there is no consensus to change the current wording of MOS:GENDERID". I don't challenge that. It accurately addressed the question asked. But basing what is intended to be new wording on a conclusion about a question that was not asked is another matter. EddieHugh (talk) 19:46, 13 June 2023 (UTC)

  It also said in bold (I've also removed) there is a consensus against using the former names of transgender or non-binary people, living or dead, except when of encyclopedic interest or when necessary to avoid confusion. and there is clear consensus that a former name is not automatically of encyclopedic interest. If you wish to challenge that part of the closure, then I defer back to the advice at CLOSECHALLENGE. But until there is a successful challenge to it, that part of the closure is every bit as valid as the part you've quoted. Sideswipe9th (talk) 19:52, 13 June 2023 (UTC)

  I have nothing to add to my previous comment, except that, as you know, I have had sufficient drama from this topic to not seek more. EddieHugh (talk) 20:04, 13 June 2023 (UTC)

• Support This wording seems to support current best practices on referring to trans and non-binary people, as I understand them. --SarekOfVulcan (talk) 19:56, 13 June 2023 (UTC)
• Support Per the close of the previous RfC, this wording seems to properly explain a position between options 2 and 3, as stated as the consensus result from said RfC. I hope the closer here will discard any arguments trying to re-litigate the previous RfC, which is not what this discussion is about whatsoever. Silverseren^C 22:39, 13 June 2023 (UTC)
• Oppose in this form, per Some1. There's the germ of a good idea in here, but it needs considerable further wordsmithing before it's guideline-worthy. WP:Writing policy is hard.  — SMcCandlish ☏ ¢ 😼  02:49, 14 June 2023 (UTC)
• Support per my comments above. Points between prior RfC's options 2 & 3 in a manner compatible with the points made there, and with BLP's goals. A short simple "*never* mention deadname" guideline would stumble on exactly the situations where that had already been notable; this longer guideline allows navigating such situations. I would hope that BDP eventually follows the same rule, beyond any time cutoff (such as 2 years), but I think that will need a separate discussion. – .Raven  .talk 05:48, 14 June 2023 (UTC)
• Support As a consequence of the consensus established by the previous RFC. I'm not that fussed over the exact wording here, this is pretty much what we concluded consensus was at during the previous RFC. --Licks-rocks (talk) 09:31, 14 June 2023 (UTC)
• Oppose - We already have multiple policies covering names and privacy (WP:BLPPRIVACY, WP:BLPNAME), the encyclopedic- or not value of facts (WP:NOTEVERYTHING), and a specific policy for the recently dead (WP:BDP). Adding more rules is unnecessary instruction creep. I don't see why we should treat a dead person any differently just because they were trans. In any case, the wording "in-depth analysis or discussion of the name" is problematic. What constitutes "in-depth analysis or discussion"? How much analysis of a person's name is required? Why does a simple fact need to be analysed or discussed to be deemed notable? We don't require "in-depth analysis or discussion" of other facts. If reliable sources think it important enough to simply state the fact (of a person's former name) - without needing to "analyse" it - then we should also treat the fact as notable. Mitch Ames (talk) 13:06, 14 June 2023 (UTC)
• Weak oppose … it’s not the name that needs to be discussed and analyzed, but the subject’s pre-transition life while he/she used that name. Blueboar (talk) 13:56, 14 June 2023 (UTC)

  a person's pretransition life can easily be discussed without mentioning their deadname. Tekrmn (talk) 20:09, 15 June 2023 (UTC)

  This becomes a WP:V issue if the sources cited only use the deadname, which is almost certain to be the case if they were published pre-transition. At least a footnote mentioning this usage needs to be included to avoid rendering such sources unreadable. small jars tc 17:01, 22 June 2023 (UTC)

  If sources using the deadname were published pre-transition, then the subject was notable pre-transition. We already say that we can mention the deadnames of people who are notable pre-transition. This proposal would not affect that. Blueboar (talk) 19:05, 22 June 2023 (UTC)

  I see that I have misread the proposed policy change. I thought it was to remove all deadnames where the deadname itself is not notable. small jars tc 21:57, 22 June 2023 (UTC)

  Sources don't have to contribute to notability to be used in an article. Tons of primary, non-independent, or non-SIGCOV sources could exist on someone pre-transition. And what happens if there's only one piece of IRS SIGCOV pre-transition and one post-transition? Neither alone would be sufficient for notability, and yet we would still be asking for the deadname itself to have just as much coverage as the subject, or even more if the subject's notability is derived through NBASIC. JoelleJay (talk) 23:32, 22 June 2023 (UTC)

  that may be true, but there are many more instances where a source written after someone's transition will discuss their pre-transition life and in those cases there's usually no reason to include their deadname, even if it is included in the source. WP:V is far from the only criterion used to decide what information can be included in an article. Tekrmn (talk) 17:15, 22 June 2023 (UTC)

  But per WP:NNC notability isn't one of those criteria. Huggums537 (talk) 05:11, 25 June 2023 (UTC)

  notability absolutely is one of those criteria as it relates to deadnames for living trans people, and it can be one of those criteria for dead trans people if we codify that. additionally, the only reason this proposal exists is because WP:DUE, which would be one of the criteria I was referring to, is being misconstrued to allow for the inclusion of deadnames where there is no reason to do so. Tekrmn (talk) 06:30, 25 June 2023 (UTC)

  If notability is codified as one of those criteria, then it will have been codified in direct conflict with the notability guidance itself. Huggums537 (talk) 08:18, 25 June 2023 (UTC) Updated on 12:54, 25 June 2023 (UTC)

  Though I have somewhat backed off from my original argument, I should make it clear that my point was not at all that the deadname could be verified, but that it would itself be needed for a reader with access to the source to do the verifying. small jars tc 12:36, 25 June 2023 (UTC)

• Support My !vote's similar to SMcCandlish, but I like the proposal generally, and don't see the need to oppose just because some of the wording isn't perfect, even if the general rule/principle is on point. We can keep tweaking if we need to. SportingFlyer T·C 16:04, 14 June 2023 (UTC)
• Oppose Why would we be excluding previous names of persons which are both public and sourced? This is part of what should be in a useful encyclopedia article. North8000 (talk) 16:22, 14 June 2023 (UTC)

  Respecting off-wiki name changes just as we do ON-wiki name changes. – .Raven  .talk 16:51, 14 June 2023 (UTC)

  ??? North8000 (talk) 17:10, 14 June 2023 (UTC)

  On-wiki, you can change your username, and even dissociate your new name from the old one, for instance as a WP:CLEANSTART, or because of some personal information released about the old one. Showing the very same courtesy to OFF-wiki individuals seems a matter of ethical consistency. We may not be able to, if per RSs the person was notable under the old name, as in the case of Chelsea Manning, but otherwise that should be the default assumption — don't include unless there's "encyclopedic interest", which is "not automatic"... per last week's RfC. – .Raven  .talk 18:22, 14 June 2023 (UTC)

  On-wiki, you can change your username — WP:RENAME explicitly says "Existing ... mentions of the old username in discussions are not affected by a rename. Renames appear in the user rename log ... This is done in the interest of transparency." RENAME does not deny or hide the past, nor should an encyclopedia article on a person who changed their name. Mitch Ames (talk) 08:41, 15 June 2023 (UTC)

  ... dissociate your new name from the old one, for instance as a WP:CLEANSTART — I do not think WP:CLEANSTART is a good analogy - the reasons for a CLEANSTART are (presumably) different to the reasons for a trans person changing their name, but since you raised it, CLEANSTART says: "Be aware that no one can grant permission for a clean start. ... If you attempt a clean start but are recognized, you will be held accountable for your actions under both the old and new accounts." This is stretching the (not-very-good) analogy, but the point is that CLEANSTART does not assure disassociation from your old name, not does it say (for example) "editors are forbidden from mentioning an editor's previous account name". Mitch Ames (talk) 09:00, 15 June 2023 (UTC)

  There's another difference. Our job here is to write articles that cover the article subject. And we don't have that responsibility to cover Wikipedia editors.North8000 (talk) 14:26, 15 June 2023 (UTC)

  "Why" is that just a week ago an RFC on this same page closed as there is a consensus against using the former names of transgender or non-binary people, living or dead, except when of encyclopedic interest or when necessary to avoid confusion and that there is clear consensus that a former name is not automatically of encyclopedic interest. Loki (talk) 17:21, 15 June 2023 (UTC)

• Support. This proposed addition to the rules is, in my view, an important step in implementing the close of the previous RfC. Opposition on the grounds that the RfC technically closed as "no consensus" misses the forest for the trees, in my opinion; the "no consensus" finding did not reflect an overall lack of agreement on how to handle this issue, but instead reflected a general agreement that the ideal result was within the grey area between two of the originally proposed options. Finally, I want to express my particular support for the inclusion of multiple examples in the language; including examples is a helpful eludicating factor for guidance that could be otherwise vague. ModernDayTrilobite (talk • contribs) 17:02, 14 June 2023 (UTC)
• Oppose as currently worded. I don't think "in-depth analysis or discussion of the name" is quite the right bar to set, though I admit that I'm unsure how exactly to improve it. I think this bar is a bit too high; extending this to "extensive use or discussion" may be better, or perhaps it may be a bit too low. Overall, I also wonder if setting a firm guideline is for the best — perhaps it would be better to simply advise against including former names in these situations unless there's an overriding encyclopedic interest, and let individual cases be determined locally. Tol (talk | contribs) @ 21:17, 14 June 2023 (UTC)
• Support, with hope for further refinement. I am convinced by the many helpful and edifying comments above that this new language represents a significant improvement over the status quo. The exact words could benefit from further smithing, but this is an evolving area of usage guidance, and hopefully our own guidance will continue to evolve as well. -- Visviva (talk) 22:50, 14 June 2023 (UTC)
• Oppose. The current wording of "in-depth analysis or discussion of the name" is problematic; except in cases where the name is unusual or follows unusual practices (for example, E. E. Cummings#Name and capitalization) the names of individuals are almost never subject to such analysis or discussion. Its absence is also not a reasonable predictor of encyclopaedic significance; if every reliable source on an individual considers a specific name relevant then that name clearly has encyclopaedic significance, even when there is no in-depth analysis of it.
  This can be seen in the provided example of Gloria Hemingway; while her former name has encyclopaedic significance I have been unable to find any "in-depth analysis or discussion" of the name. It is frequently mentioned in the context of in-depth analysis or discussion of her relationship with her gender identity and gender expression, but that isn't the same thing as the name itself being subject to such coverage.
  This proposal would also conflict with policy; there are many circumstances where it would require us to exclude names that WP:NPOV would require us to include due to their prominence in reliable sources. I suggest that any future proposal simply directs editors to that core policy; it would exclude mention of names that lack encyclopaedic significance and should be an uncontroversial and non-problematic change. BilledMammal (talk) 06:12, 15 June 2023 (UTC)

  > "This proposal would also conflict with policy; there are many circumstances where it would require us to exclude names that WP:NPOV would require us to include due to their prominence in reliable sources."

  The horse already left that barn: WP:BLPPRIVACY has us not report personal information (address, phone#) against the subject's will, even if news sources have done so: "Consensus has indicated that the standard for inclusion of personal information of living persons is higher than mere existence of a reliable source that could be verified." WP:BLPCRIME has us not report the names of unconvicted arrestees even if those names have been prominent in RSs. WP:BLPNAME has us be similarly careful about non-arrested people's names: "When the name of a private individual has not been widely disseminated or has been intentionally concealed, such as in certain court cases or occupations, it is often preferable to omit it, especially when doing so does not result in a significant loss of context." (We couldn't have done so anyway without RS[s], but again the "mere existence" of an RS would not be enough.)

  The previous RfC's closer summarized: "there is a consensus against using the former names of transgender or non-binary people, living or dead, except when of encyclopedic interest or when necessary to avoid confusion. Also, there is clear consensus that a former name is not automatically of encyclopedic interest" – which is entirely compatible in spirit with those BLP sections. – .Raven  .talk 07:29, 15 June 2023 (UTC)

  This argument is completely irrelevant as this isn't a BLP issue. The previous RFC didn't extend all BLP protections to all dead trans people. Iffy★Chat -- 08:45, 15 June 2023 (UTC)

  The previous RfC's closer specifically said, "there is a consensus against using the former names of transgender or non-binary people, living or dead, except when of encyclopedic interest or when necessary to avoid confusion. Also, there is clear consensus that a former name is not automatically of encyclopedic interest." [emphasis added] – .Raven  .talk 01:45, 16 June 2023 (UTC)

  The relevant section would be Wikipedia includes full names and dates of birth that have been widely published by reliable sources; the requirement of being "widely published by reliable sources" is less strict than the requirement proposed here and does not conflict with WP:NPOV.

  Plus, as Iffy points out, we aren't discussing BLP's here. BilledMammal (talk) 12:02, 15 June 2023 (UTC)

  @BilledMammal: This proposal would also conflict with policy; there are many circumstances where it would require us to exclude names that WP:NPOV would require us to include due to their prominence in reliable sources. Actually, if you check the footnote in the proposal, the second wikilink is to the WP:BALASP part of NPOV. We already have a consensus from the previous RfC (see the first wikilink in the footnote) that the former names of deceased trans and non-binary individuals are not automatically considered to be of encyclopaedic interest, which de facto puts us into WP:VNOT, WP:NOTEVERYTHING, and minor aspects territory.

  the requirement of being "widely published by reliable sources" is less strict than the requirement proposed here Yes, but it also conflicts with the close of the previous RfC. To quote from that close, Many responses supporting different options specifically called out the difficulty of dealing with a "majority" of sources, e.g. is 50%+1 sufficient? How does a majority take into account emphasis and source quality? Some of those supporting option 2 suggested a higher bar than majority as well. That tells us that "widely published", which for some editors can be as little as 50%+1, for others is some form of supermajority, and does not always take into account the quality of the sources available, is not only difficult for us to define in a guideline, but also an option that has been rejected to some degree by the community.

  Any proposal to actually implement the consensus of the last RfC has a difficult task, and a very small target to hit. As the side discussion on Barkeep49's talk page alludes to, the consensus that lies between options 2 (sometimes include) and 3 (never include) is considerably closer to option 3 than 2. That means that whatever bar is set, it has provide for not including the name in the majority of articles, while still allowing some wiggle room for inclusion in a minority of articles where it is of encyclopaedic relevance. Sideswipe9th (talk) 19:06, 15 June 2023 (UTC)

  Actually, if you check the footnote in the proposal, the second wikilink is to the WP:BALASP part of NPOV. Linking NPOV doesn't change the fact that the proposed wording would require us to exclude names when NPOV would require us to include them - including, it seems, in the case of the example you provided, Gloria Hemingway. BilledMammal (talk) 20:02, 15 June 2023 (UTC)

• Oppose, I'm not seeing the value of making this addition which is setting a bar too high for verification IMO.--Ortizesp (talk) 06:16, 15 June 2023 (UTC)
• Oppose as too restrictive, and on principle because we can't pick and choose when to ignore hard policy in the MOS. That way lies madness (and WP:NOTANARCHY). —Locke Cole • t • c 06:50, 15 June 2023 (UTC)

  WP:BLP is also policy. See my citation of its sections, above. – .Raven  .talk 07:35, 15 June 2023 (UTC)

  WP:NPOV is the only policy that explicitly states it is non-negotiable. The additional text is also unnecessary instruction creep. —Locke Cole • t • c 15:55, 15 June 2023 (UTC)

  NPOV explicitly allows for the exclusion of content should it be deemed a minor aspect of the subject, see WP:BALASP which is linked in the footnote of the proposal above.

  The additional text is unfortunately necessary for two reasons. We already find ourselves in situations on many articles where the lack of explicit guidance for handling the former names of deceased trans and non-binary individuals forms the focal point of long and occasionally contentious discussions of inclusion or exclusion. This proposal, or any similar one, will go a long way to reducing the number of discussions that are currently necessary, because the lack of guidance currently requires a per-article local consensus to be formed in all cases. Secondly, we already have a consensus from the previous RfC, as well as an older one from August 2021 that we need some form of explicit guidance to handle former names for the majority of cases of deceased trans and non-binary people.

  And in case it comes up, to pre-emptively answer why this proposal is targeted at the most recent RfC and not the August 2021 RfC, it's clear from the more recent RfC that consensus for when to include or exclude a former name has changed in the intervening two years. The current consensus is significantly stricter on inclusion than the consensus from August 2021, and this proposal reflects that stricter criteria for inclusion. Sideswipe9th (talk) 19:20, 15 June 2023 (UTC)

• Support as this seems to reflect best practices and is the logical extension of the consensuses reached in the previous discussion. (Prefer Thryduulf's version but either is good.) Mere passing mentions of a name that the subject was not otherwise notable under should obviously not be enough for inclusion, let alone to mandate it, as some people above have asserted. Some people express concern that discussions could demand an insurmountable bar for inclusion; but there's no real evidence to back that up. Meanwhile it's clear that many people above believe that any handful of mentions, no matter how slight, would be sufficient to literally force inclusion. That is an untenable position to take, and it is clear from the above that it is one that many people will take unless we word the MOS guidance to at least provide some sort of bar beyond that. --Aquillion (talk) 07:30, 15 June 2023 (UTC)

  @Aquillion, opposers aren't arguing that a passing mention of a name someone was not notable under should be mandated. The issue is that someone's name (former name or not, living subject or not) almost never receives in-depth discussion in HQRS, so this proposal is effectively eliminating any mention of a dead trans person's deadname ever, which goes way beyond the close summary that deadnames merely aren't automatically encyclopedic. The proposal would bar including the deadname even in situations where there is already a single SIGCOV IRS source on the subject pre-transition, or where every single post-transition SIGCOV source states the deadname, or even where every source repeatedly mentions the deadname without specifically "discussing it in depth". It would even require a former name to be more notable than the subject themselves in cases where the subject just scrapes by NBASIC without any SIGCOV sourcing. It just doesn't make sense for inclusion of a deadname to go above and beyond WP:DUE and WP:MINORASPECT. JoelleJay (talk) 18:57, 22 June 2023 (UTC)

• Oppose per Some1, Trystan and BilledMammal. Firstly, we should be using our standard editorial practices to decide this issue on a case by case basis. These articles aren't BLPs so I fail to see any reason for a special standard to apply here that we don't even apply to BLPs. Even if there should be some special standard here, the standard proposed doesn't match the examples given. Iffy★Chat -- 09:03, 15 June 2023 (UTC)

  > "Firstly, we should be using our standard editorial practices..."

  The previous RfC's consensus/closure left this one detail (exactly when to include deadnames, between "sometimes" and "never") for another discussion. This is that discussion, obeying that consensus. Judging "Notability" for inclusion is one of the "standard editorial practices" we're used to; this just applies it to deadnames, the same way we already apply it to articles overall.

  "... to decide this issue on a case by case basis."

  The specifics for each article subject (e.g. was the deadname notable before the change?) WILL have to be decided on a case by case basis. But without sitewide guidance on what to look for, what criteria to apply, we'll have a lot of RfC-type argument about that same issue reprised on talkpage after talkpage, resulting in no consistency across the site. – .Raven  .talk 23:33, 15 June 2023 (UTC)

  This has nothing to do with "notability". WP:Notability is a standard for whether a topic can have its own stand-alone article, and is entirely unrelated to what can be mentioned in an article (that's covered by WP:NOTINDISCRIMINATE and WP:UNDUE policies).  — SMcCandlish ☏ ¢ 😼  16:59, 16 June 2023 (UTC)

  We already have MOS:DEADNAME (part of MOS:BIO) saying:

  In the case of a living transgender or non-binary person, their birth name or former name (professional name, stage name, or pseudonym) should be included in the lead sentence of their main biographical article only if they were notable under that name.

  Again, "only if they were notable under that name." [emphasis added]

  And the RfC closed June 7 expects us to cover "living or dead." Why not by the same rule? – .Raven  .talk 09:36, 24 June 2023 (UTC)

  Well, I do think that's a misrepresentation of the RFC. There was a proposal to simply remove living from relevant paragraph, which would apply the same rule to living or dead—that was option 3. There was also a proposal to include per WP:PLA, considering whether the name was used in a majority of reliable sources—that was option 2. The closer found that there wasn't a consensus for either option 2 or 3, but that the consensus was, rather, for a intermediary position.--Jerome Frank Disciple 09:54, 24 June 2023 (UTC)

  I quoted one clause verbatim from the boldfaced portion of the closure. That portion in full, sans bold:

  there is a consensus against using the former names of transgender or non-binary people, living or dead, except when of encyclopedic interest or when necessary to avoid confusion. Also, there is clear consensus that a former name is not automatically of encyclopedic interest.

  Note the clause "living or dead". – .Raven  .talk 19:18, 24 June 2023 (UTC)

  The portion of your comment I'm addressing is "Why not by the same rule?"--Jerome Frank Disciple 19:33, 24 June 2023 (UTC)

  Which does not "misrepresent the RfC" because it's a separate sentence (in my own voice) from the sentence about the previous RfC. As in:

  'Hey, you wanted to go to dinner. Why not this new restaurant I found?'

  'You're misrepresenting me. I said I wanted to go to dinner, but I didn't mention that restaurant.'

  – .Raven  .talk 20:12, 24 June 2023 (UTC)

  I think presenting that as possibly consistent with the RFC expectation is a little rough but yeah okay I guess "And the RfC closed June 7 expects us to cover "living or dead." Why not [in contravention of its expectation/finding] by the same rule?" doesn't misrepresent the RFC. I also have no clue why we're bothering to talk about that as an option, since it's not on the table and, given the last RFC (not to mention this one), isn't likely to be any time soon, but fair enough!--Jerome Frank Disciple 20:17, 24 June 2023 (UTC)

  It would accomplish "sometimes" though not "never"; at least it would reduce the number of inclusions — which I think targets the area in the middle. And it would take an existing rule as guide. Note that simply removing the word "living" from WP:DEADNAME would suffice, no long additional verbage needed. – .Raven  .talk 21:08, 24 June 2023 (UTC)

  That's exactly what option 3 suggested.--Jerome Frank Disciple 21:15, 24 June 2023 (UTC)

  Okay then. – .Raven  .talk 21:30, 24 June 2023 (UTC)

• Oppose. We are first an encyclopedia, and try to preserve and disseminate knowledge. We do have a strong secondary goal of minimizing harm, but where these conflict, "living" is a good place to draw the line. --GRuban (talk) 13:53, 15 June 2023 (UTC)
• Support (and would also support Thryduulf's wording): I do find this somewhat covered already by WP:WEIGHT, but there can be value in specifically mentioning a subcase, especially when that subcase is contentious. Sometimes you just have to spell it out for people. Gnomingstuff (talk) 14:22, 15 June 2023 (UTC)
• Oppose, "in-depth analysis or discussion of the name in high quality sources" is far too restrictive. Omitting birth names can hinder further research (just like omitting date and place of birth would), and the BLP reasons to omit such information although it is available no longer apply after a person has been dead for a few years. I very much agree with GRuban. —Kusma (talk) 14:23, 15 June 2023 (UTC)
• Oppose. I think the "in-depth" qualifications in the proposed wording is way too restrictive, because someone's name is generally not something that's discussed in that manner, whether cis, queer, whatever (per Blueboar.) It also runs into CREEP issues trying to apply a single ruleset to varied circumstances. BLP, WEIGHT, etc. all offer enough guidance for the edge cases to be hashed out. This is starting to run into a solution in search of a problem. Der Wohltemperierte Fuchs ^talk 15:03, 15 June 2023 (UTC)
• Support by arguments in the previous RFC, which already ascertained that the consensus was similar to this wording. Chaotic Enby (talk) 15:05, 15 June 2023 (UTC)
• Oppose:as per Some1 and EddieHugh. This seems like a lot of WP:CREEP and will make more discussions without improving the quality of information in any given article. - AquilaFasciata (talk | contribs) 15:19, 15 June 2023 (UTC)
• Support My thoughts run basically along the lines of Aquillion's comment. The concern about demand[ing] an insurmountable bar for inclusion, as that comment puts it, is understandable but comes across to me as borrowing trouble. I would also agree with Thryduulf's proposed alternate wording. XOR'easter (talk) 15:50, 15 June 2023 (UTC)
• Support – the previous RfC already found consensus for something in this direction. This proposal in particular has the notability bar we apply for living individuals, plus an allowance for discussing names where it really is relevant. I somewhat agree with Thryduulf's concern, and I think "notable prior to discarding that name" is the best solution. -- Maddy from Celeste (WAVEDASH) 15:56, 15 June 2023 (UTC)

  ^ Would second that.--Jerome Frank Disciple 15:58, 15 June 2023 (UTC)

• Support, but I would prefer to add a little more - something clearly needs to be done here, yes, but I don't like the creep issues noted above. I think it would be nice to add some wording to the effect of "this is just WP:DUE restated for emphasis, not a rule" but more formal. (I'm also still dying on the hill of applying the same rules to all people, deceased or living, that I died on in the RfC, but I recognize that's not up for discussion right now.) casualdejekyll 18:53, 15 June 2023 (UTC)
• Support I'm open to refining the wording, but I think the most important thing at this stage is to get the wording close enough to our intent that we can implement the result of the previous RfC, and I feel like this suffices. I'm already dismayed to see people relitigating the original RfC in the opposes here, and the more time we spend debating the wording, the harder it will be to get a consensus to implement something we already decided to implement. TheCatalyst31 ^{Reaction•Creation} 19:13, 15 June 2023 (UTC)
• Support. No bar is too high when it comes to dead names of trans folk. There is no reason to mention it unless the subject was notable under their previous name. Skyerise (talk) 19:26, 15 June 2023 (UTC)
• Support - I think this is a definite step in the right direction. I do agree with many of the other commenters that the wording could be improved but it's difficult to think of how to specifically word this proposal to fall between options 2 and 3 of the previous RFC and I would definitely rather come to a consensus on this and try to tweak it from there. Tekrmn (talk) 20:37, 15 June 2023 (UTC)
• Oppose per Kusma. Ruslik_Zero 20:38, 15 June 2023 (UTC)
• Oppose. “in-depth analysis or discussion of the name in high quality sources” is an absurdly high bar. Or at least it has the massive potential to be used as such a bludgeon that it is effectively the same as saying “prior notable names only”—a standard that has now been rejected. I would probably support the change without that phrase (ie, include names on encyclopaedic merit) , but at this point it feels like a small group are taking every chance to push a higher bar than the community wants. You have had my opinion many times elsewhere, so I won’t go on. — HTGS (talk) 20:42, 15 June 2023 (UTC)
• Oppose as explained before. No other part of a person's biography like their DOB requires "in-depth analysis or discussion of the name in high quality sources" to be included.  Spy-cicle💥  ^Talk? 21:28, 15 June 2023 (UTC)

  Well, regardless, an RFC was just closed saying a dead trans person's name does indeed deserve special protections. This RFC is an implementation of that consensus. It's fine to say you think the bar is too high, but there's already a recent consensus that there should be a bar somewhere. Loki (talk) 02:27, 16 June 2023 (UTC)

  Nothing agreed to here can in any way undermine or change the fact that WP:NPOV is a non-negotiable policy, and that DUE is part of that obligation. It even supersedes BLP, in that regard. We won’t be setting aside our sources just to conform to the whims of a small group of people. —Locke Cole • t • c 02:50, 16 June 2023 (UTC)

  Cool, and the fact that people have arrived at such a consensus also implies a consensus that your interpretation of WP:NPOV is wrong. It's the policy that's non-negotiable, not your idiosyncratic interpretation of it.

  (My personal reading of why you're wrong is that NPOV does not require Wikipedia to include any particular material, even material covered in reliable sources. WP:V is much closer to what you're looking for, but even it doesn't require us to cover anything. What NPOV and V say is that if we want to cover material, it should be in proportion to its weight in reliable sources. But they don't contradict the many policies giving reasons why we might not cover certain material, such as WP:NOT, WP:BLP, WP:GRATUITOUS, and even WP:NPOV itself, among others.) Loki (talk) 03:13, 16 June 2023 (UTC)

Collapse tangential sniping ScottishFinnishRadish (talk) 15:18, 16 June 2023 (UTC)

NPOV was not part of the prior RFC. You’re welcome to start an RFC to change NPOV to state that neutrality is optional for transgender people. I’ll be a hard oppose to such a change, but if that’s what you want to do, go with God. —Locke Cole • t • c 03:54, 16 June 2023 (UTC) "Hey Locke Cole, no one seems to agree with your interpretation of NPOV" "Well until the NPOV is changed, MY INTERPRETATION CONTROLS" ???--Jerome Frank Disciple 13:43, 16 June 2023 (UTC) That's a beautiful strawman you've made. You should really do this sort of thing professionally. —Locke Cole • t • c 15:06, 16 June 2023 (UTC) Oh sorry do you want quotes? Loki: Cool, and the fact that people have arrived at such a consensus also implies a consensus that your interpretation of WP:NPOV is wrong. It's the policy that's non-negotiable, not your idiosyncratic interpretation of it. You: You’re welcome to start an RFC to change NPOV to state that neutrality is optional for transgender people. The fundamental issue is that very few people agree with your claim that not including a non-notable deadname is an NPOV violation. I get that you do consider it that way, as you've said over and over again. (In fact, in the last RFC, you even repeatedly insisted that principally referring to trans people by their chosen name would be an NPOV violation!) But you seem to be among a distinct minority that interprets NPOV that way. So it's not on Loki to suggest a change to the NPOV policy. If you want the community following your interpretation of NPOV policy, you should probably make a proposal. Or you can just deal with having your idiosyncratic NPOV points repeatedly ignored. Either way, go with God.--Jerome Frank Disciple 15:15, 16 June 2023 (UTC)

• Oppose per GRuban, Kusma, and David Fuchs. In this proposal, the bar is being set too high such that it would hinder possible knowledge from being included via research (especially when the former name is the primary name that reliable sources use), when the harm to dead people is non-existent. It is also not apparent what "in-depth analysis" of a deadname is expected, and it is not clear that even the cited example of Gloria Hemingway has that for Gregory Hemingway. starship.paint (exalt) 03:33, 16 June 2023 (UTC)
• Support per ModernDayTrilobyte. We had this discussion already; the consensus was that deadnames should not be used unless they are encyclopedic and that past names are not inherently encyclopedic. The fact that this guideline comports with existing policies indicates that it is supported by broad consensus, which makes it a good rule. The belief that all verifiable deadnames are encyclopedic is not just against community consensus and the principles of the project, it is deeply rooted in ideology. Pretending it has anything to do with neutrality or integrity is nothing more than farce. —Rutebega (talk) 05:45, 16 June 2023 (UTC)

  Consensus across the wiki is that all names used by a notable individual (pseudonyms, married names, various names used in ancient China) are encyclopedic. The proposal seeks to carve out an exception from this for people who have changed gender identity. It seems to be the proposal that is based in ideology. —Kusma (talk) 08:34, 18 June 2023 (UTC)

  > "Consensus across the wiki..." — Link?

  > "... all names used by a notable individual (pseudonyms, married names, various names used in ancient China) are encyclopedic."

  WP:NOTPUBLICFIGURE differs:

  Many Wikipedia articles contain material on people who are not well known, even if they are notable enough for their own article. In such cases, exercise restraint and include only material relevant to the person's notability, focusing on high-quality secondary sources. Material published by the subject may be used, but with caution (see § Using the subject as a self-published source, above). Material that may adversely affect a person's reputation should be treated with special care; in many jurisdictions, repeating a defamatory claim is actionable, and there are additional protections for subjects who are not public figures.

  See Public figure for the latter distinction.

  And once again, the RfC here closed on June 7 has this in the closure statement: "there is a consensus against using the former names of transgender or non-binary people, living or dead, except when of encyclopedic interest or when necessary to avoid confusion. Also, there is clear consensus that a former name is not automatically of encyclopedic interest." – .Raven  .talk 10:20, 18 June 2023 (UTC)

  I have no idea why you mention WP:NOTPUBLICFIGURE, which is about living people, so totally offtopic here. I think it is a bad principle to treat dead transgender people's names different from other dead people's names. Articles about dead people contain all kinds of information that we don't necessarily include in articles about living people. While some living people don't want their birthday to be known, and we sometimes respect that, we should not omit sourced birthdates from articles about dead people, and we should not ask for in-depth discussion of the date in high quality sources. We give former names of dead people if the name was a pseudonym or the name change was by adoption, marriage, or deed poll (just look at almost any article about a dead person who changed their name; that is what I mean by "consensus across the wiki"), but you say we should not do that if the name change was due gender identity? Most of my wiki work is about people who have been dead for a long time. To find out more about these people, it helps immensely to know their birth name and date and place of birth. Deliberately hiding some of these for certain classes of people harms our encyclopaedic mission. Living people is our exception, and that is a sufficient exception. —Kusma (talk) 14:04, 18 June 2023 (UTC)

  Except the June 7 consensus, by saying "living or dead", is suggesting the same standards of what is "encyclopedic interest" be applied to both. In that case, the question of whether the person is-or-was a "public figure" surely applies: movie stars and holders of public office get more coverage, in life and death, than non-public figures. "We give former names of dead people" for people like Joan Crawford and Gerald Ford; for living (and in this case "living or dead") non-public figures such as people notable only for one event (BLP1E, BIO1E), we give less detail, e.g. "In general, creating a pseudo-biography (on an individual who is only notable because of their participation in a single event) will mean that an editor creating the article will try to "pad out" the piece by including extraneous biographical material, e.g. their date and place of birth, family background, hobbies and employment, etc. Such information, in many cases, will fail the inclusion test.... When in doubt, concentrate on the notable event, rather than invading privacy for the sake of padding out an unnecessary biography." – .Raven  .talk 16:15, 18 June 2023 (UTC)

  I very much hope that we use a stricter standards for deadnames of living trans people than for people who have been dead for 200 years, so what you say is the June 7 consensus seems to be a bad idea. WP:DUE always applies, but WP:BLP correctly does not apply to people who have been dead for a while. —Kusma (talk) 17:51, 18 June 2023 (UTC)

  > "what you say is the June 7 consensus" — See the closure full-text.  I quoted from the portion emphasized by boldface in the original. – .Raven  .talk 17:16, 19 June 2023 (UTC)

• Support as a reasonable formalization of WP:UNDUE in this context, and as simply the right thing to do. Hatman31 (talk) 18:08, 17 June 2023 (UTC)
• Oppose as an impossible bar to meet. How many notable people outside royalty have "in-depth analysis and discussion" of any of their names (living or dead) in reliable, independent sources? Most people weren't notable as children, but information about the childhood and origins of notable people is still of encyclopaedic interest: it helps flesh out how they evolved, their context, etc. As others have said, this should be decided on a case by case basis through normal editing and talk page discussion. 𝕱𝖎𝖈𝖆𝖎𝖆 (talk) 07:29, 18 June 2023 (UTC)
• Oppose, it's pretty ridiculous to require that deadnames themselves receive essentially GNG-contributory coverage--especially when there are thousands of subjects who don't meet GNG and just got articles via scraping by BASIC with a handful of non-SIGCOV mentions. We shouldn't have a higher inclusion standard for article content than for an article subject! It would make much more sense for a deadname to be mentioned if it appears within multiple pieces of SIGCOV of the subject. JoelleJay (talk) 21:00, 18 June 2023 (UTC)
• Support previous RFC showed wide support for updating this policy. The proposed wording is in line with existing policy around DUE weight. Rab V (talk) 05:03, 19 June 2023 (UTC)
• Oppose. I strongly support LGBT+ rights, I sympathize with the difficulties they face, and I condemn discrimination. If someone isn't sleeping in my bed I don't care what orientation or identity they have, who they want to marry, whether they want to adopt a child, or whatever else. However I am not on board with attempts to deny, rewrite, exterminate, or censor history. It should not require some onerous criteria for a literal biography to include the most basic and expected biograhical facts. Just about any professional book-biography is going to mention birth name and name changes for any biographical-subject, if such information is available. Our job is to provide readers the information that they'd reasonably expect to find in a biography, and that is pretty universally expected to include birthname. Alsee (talk) 11:25, 19 June 2023 (UTC)
• Oppose: As a genderqueer person, I understand why deadnames are under consideration to be removed, to reduce the harm faced by trans people, which is a fair thing. But then, what harm are already dead people facing? And secondly, an encyclopedia's duty is to disseminate knowledge of interest, not harm reduction. There's a reason why we do not have helpline numbers at the top of suicide methods for example. I agree with Some1, Kusma & Alsee above, and believe that we are building an encyclopedia and (verifiable, true) information matters. Birth name for trans people like birth place or birth date are basic details. If such information is available, it should be on the article. In that regard, it should be no different from name changes on other occasions, like marriage, or stagename, and inclusion or exclusion must be decided accordingly. We should not attempt to censor history. I would have raised this earlier, but I was on a wiki-break for college exams. Assuming that Wikipedia has collectively decided that information must be censored, I still don't even know what "in-depth analysis and discussion" of name is supposed to mean. Unless someone was named Ima Hogg or something, prior to transitioning, I wonder if there would be any "in-depth analysis and discussion" of the name available at all. The proposed wording effectively sets a standard that is near impossible to meet. As far as an inclusion standard is concerned, this is just WP:CREEP when WP:DUE should be sufficient. —CX Zoom[he/him] ^{(let's talk • {C•X})} 17:26, 19 June 2023 (UTC)
• Support per nom and JFD, per Aquillion's counterarguments to concerns raised, and especially per Silverseren. Ideally prefer Thryduulf's proposed wording. I think this is quite a good improvement over the current wording. DFlhb (talk) 03:06, 20 June 2023 (UTC)
• Oppose - Per WP:NPOV and WP:NOTCENSORED, essentially. FOARP (talk) 07:48, 20 June 2023 (UTC)
• Support but add links to WP:WEIGHT and WP:NOTABLE in the first paragraph. The first paragraph feels a bit clunky, but not so much to garner an oppose. The void century 00:12, 21 June 2023 (UTC)

  @The void century, adding a link to Notable is a terrible idea per WP:NNC, and exactly the reason why I am going o oppose this proposal. Huggums537 (talk) 11:39, 24 June 2023 (UTC)

  I think you misunderstood. I meant to link wp:notable where they mention the word "notable" in if they were notable prior to transitioning. That just makes clear what they mean by notable. It has nothing to do with WP:NNC. The void century 12:10, 24 June 2023 (UTC)

  I understood perfectly. What I'm telling you is that nothing in the notability guidance supports governing content within articles. Notability is a factor to determine if a topic warrants having an article or doesn't, not if something (like a deadname) should be mentioned in an article or not. In other words, it doesn't matter if something is (or was) notable just to be mentioned in an article, it only matters if it is notable when you are talking about if it deserves an article. This is per WP:NNC (Which is a section of the notability guidance so it has everything to do with it.) Huggums537 (talk) 12:21, 24 June 2023 (UTC)

  Correction. I said this is per NNC, but it is actually per the whole Notability guideline. It even starts out telling you so directly from the outset in the last sentence of the nutshell: The notability guideline does not determine the content of articles, but only whether the topic may have its own article. Huggums537 (talk) 12:26, 24 June 2023 (UTC)

  I suspected you might show up! Just so everyone is clear (because, speaking from experience and the apparent experience of others, this can be a bit jarring when you first encounter it): User:Huggums537 is philosophically opposed to the use of either WP:NOTABLE or a more general concept of "noteworthiness" as a criterium for content. (See this discussion, for example, or the the current discussion at WT:NOT concerning WP:NOTDIRECTORY, which presently says that disambiguation pages should be restricted to "just the notable" entries.) Chiefly, Huggums cites WP:NNC, which says that the notability guidelines don't apply to content (though I'm not sure the conclusion follows—from my perspective, WP:NOTABLE, by itself, is, as NNC makes clear, meant to apply to article-creation issues, but that doesn't mean that a different policy or guideline can't employ the notability criteria to determine a specific content question, only that application of NOTABLE to content without such a policy or guideline is invalid).

  Now, MOS:GENDERID expressly calls for distinct treatment of living persons who were notable before transitioning, and this proposal would not affect that. The idea that a name is more relevant to a person's Wikipedia article if that person was notable (or at least noteworthy) under that name seems fairly uncontroversial (though I assume Huggums would prefer that we use some kind of proxy measure or other language—Huggums, if you'd like to start an RFC to test whether there's community consensus for your "no consideration of notability in content ever" position, I'd be curious to see it!). Rather, the proposal is meant to bring the treatment of deceased persons closer in line to the treatment of living person. (Of course, I completely understand Huggums voting against the proposal because he doesn't want additional content guidance based on notability.)--Jerome Frank Disciple 12:44, 24 June 2023 (UTC)

  I'm a little weirded out and perplexed by your decision to blast out my opinions here, but thanks for spreading the message at any rate. I really see nothing jarring about doing exactly what the guidance says to do, and I also see absolutely no need whatsoever on wasting time starting any RfC's to test my ideas for consensus when they have already been enshrined as consensus in the guidance for years now. Perhaps you would like to be the one to start an RfC to see if you can have it changed or removed? I'd be curious to see how that goes! Huggums537 (talk) 13:15, 24 June 2023 (UTC) Updated on 13:56, 24 June 2023 (UTC)

  ?? As I said, it's already in the guideline? We don't need to start an RFC to keep it. (Also ... you started an RFC in one of the other discussions I linked ... so this whole "I don't need to start an RFC because it's already my way" seems a little thin, but all good!)--Jerome Frank Disciple 13:41, 24 June 2023 (UTC)

  I've included a link to clarify, but yeah it sure isn't all my way yet. That's one thing we can agree on. Huggums537 (talk) 14:03, 24 June 2023 (UTC)

  I don't know why you've hyper obsessed over this issue or somehow identified with it so strongly as to term it "[your] way", particularly given that your conversations concerning this issue have often been totally unconnected to your mainspace contributions. But your reading of NNC is unique: NNC does not say that no content guideline can incorporate WP:N for any purpose. To quote one editor from one of your prior efforts to push this, I'm now at least the sixth editor "to tell [you] there's no dilemma/conflict" (that editor then said your continued insistence otherwise was "bordering WP:IDHT").

  To be clear, I'm not saying you have to agree. If you're opposing this RFC because you don't think notability should ever be incorporated by a content guideline, that's fine—and if you find it a good use of your time you're of course welcome to continue pushing your general view. But, below, you're proposing that "notable" be removed from the portion of MOS:GENDERID discussing living persons, which isn't being discussed here. You're also saying you have no interest in starting an RFC to propose that. This isn't a forum for you to randomly discuss your philosophy or make idle chatter about what you think Wikipedia guidelines should be. I'm done conversing with you here.--Jerome Frank Disciple 14:18, 24 June 2023 (UTC)

  I'm not so sure what's so hard to grasp about WP:NOTEWORTHY, when it clearly says (in the heading even) Notability guidelines do not apply to content within articles [...]. —Locke Cole • t • c 16:44, 24 June 2023 (UTC)

  If you would like to start an RFC saying that MOS:GENDERID's current guideline as to living persons fail WP:NNC, you're welcome to, but I should warn you that I think you'll end up looking stupid. Your call.--Jerome Frank Disciple 17:11, 24 June 2023 (UTC)

  you'll end up looking stupid Couldn't be any dumber than the idiots who got us to MOS:GENDERID as currently worded when WP:DUE was there the whole time and perfectly covers this from beginning to end. —Locke Cole • t • c 17:53, 24 June 2023 (UTC)

  Says the guy who wouldn't even supporting using a trans person's chosen name. I wonder if it's really just DUE animating your position. Either way, I guess that's a no on the RFC. Well, no further discussion needed then.--Jerome Frank Disciple 17:55, 24 June 2023 (UTC)

  If it's their chosen name, then we would have sources to reflect that and it would be DUE. Anything else stupid to add? —Locke Cole • t • c 18:22, 24 June 2023 (UTC)

  Sorry—"principally referring to a trans person by their chosen name". Locke you're a broken record here—if there's any proposal to protect or further respect trans people, you'll be opposed based on your unique view of NPOV/DUE. I got it.--Jerome Frank Disciple 19:12, 24 June 2023 (UTC)

  Locke you're a broken record here Trying to avoid having this project overrun with people pushing agendas gets me labeled as stupid and a "broken record", I'll take that. This is an encyclopedia, a collection of human knowledge. If your goal is to hide or omit knowledge because it offends a particular group of people, then this isn't the place for you. —Locke Cole • t • c 04:48, 25 June 2023 (UTC)

  "I oppose every proposal meant to protect or show basic respect to trans people. It's my OPPONENTS who have an agenda!"--Jerome Frank Disciple 13:15, 25 June 2023 (UTC)

  Gentlemen please. I think we all have our own "agendas" in our own unique way. Let's be civil with each other if we can. Calling each other stupid and trying to call out or speculate about what the other person might have as their unique agenda isn't helping anything. Huggums537 (talk) 13:37, 25 June 2023 (UTC)

• Oppose. Instruction creep. Also, the proposed criterium is mistaken: detailed coverage in sources is a requirement for article topics, but not for article elements, such as a former name. Such names are often helpful to readers when trying to identify a person they read about under the previous name. Sandstein 15:05, 21 June 2023 (UTC)

  A lot of people are calling this instruction creep, and I'd just like to point out that WP:NOTCREEP says "Additional instruction can be helpful when it succinctly states community consensus regarding a significant point, but it is harmful when the point is trivial, redundant, or unclear." In this case, we already have community consensus that the existing guideline needs to address the topic of deadnames for deceased individuals. additionally, the MOS already references notability as a criteria for the inclusion of deadnames for living people, and we're here to propose a change to a guideline not to go by the status quo, so it's definitely not unreasonable to use that as a criterium. Tekrmn (talk) 15:33, 21 June 2023 (UTC)

  Which is the entire problem with holding an RFC to say "should we do something" without specifying what that thing is: it cannot mandate that the outcome of a later RFC has to endorse its logic. FOARP (talk) 14:24, 22 June 2023 (UTC)

  It seems to me that Topic 1 was rather clear on the thing to be done. Topic 2 was the section that only narrowed the choices down to two, after which the closure left it to another discussion to resolve. – .Raven  .talk 16:58, 22 June 2023 (UTC)

  but it is harmful when the point is trivial, redundant, or unclear (emphasis added) These changes are redundant to WP:DUE (and even if adopted, are subservient to WP:DUE). The previous RFC was also not based at all on discussion that preceded the RFC, and actually ignored proposed questions and language in favor of an RFC crafted in private between two editors pushing this as their agenda. The proposals being pushed are borderline encapsulations of WP:NOTHERE. When you tell us to stop providing knowledge on things that are verifiable and due in an encyclopedia, you've lost the plot and maybe need to go find something else to do with your spare time. —Locke Cole • t • c 15:42, 22 June 2023 (UTC)

  They're not redundant because DUE is not being applied to deadnames in many cases, even when the subject is living, and because DUE does not address deadnames. a lot of wikipedia policies and guidelines have overlaps depending on the contexts they apply to. nobody is telling anyone to stop doing anything, this is a proposal that is seeking consensus, and it is not proposed that you omit the deadname if it's due, it's seeking to define what it means for a deadname to be due in the case of a deceased individual.

  I don't see how the way the proposals for the last RFC came about is relevant. what are you saying, that they should have had an RFC to come up with the proposals for their RFC? I honestly don't know how to respond to the claim that it was tendentious editing because it is so completely unrelated to what that essay discusses. if your point in implying it's tendentious editing is that they're pushing an agenda, this RFC was created because there was a consensus in the previous RFC that the MOS needed to be updated with a change that falls somewhere between two of the options from the last RFC, this RFC was the clear next step.

  I'd appreciate it if you would refrain from telling me what to do and especially telling me that I'm confused. I don't think that's particularly civil. Tekrmn (talk) 16:45, 22 June 2023 (UTC)

  We don't need a policy or guideline on deadnames. WP:DUE is fine here. Now, are you here to build an encyclopedia, or are you here to push an agenda? Because one of those is compatible with continuing on this project, and the other is not. —Locke Cole • t • c 04:45, 25 June 2023 (UTC)

  I find it to be inappropriate to propose that someone with an opposing viewpoint (one that found consensus in the last RFC for that matter) is pushing an agenda, and to imply once again that I am unfit to participate in this discussion. that being said, I'm here to discuss this proposal, so if you don't have anything to add to that conversation then it looks like we're done here. Tekrmn (talk) 06:12, 25 June 2023 (UTC)

• Oppose. Inclusion or removal should follow generally applicable policies, such as WP:WEIGHT, WP:NOTCENSORED, and (for BLPs) WP:BLP, in the same way they apply to any other content. Some editors make a big deal of quoting "not automatically of encyclopedic interest" from the earlier RfC's closer, but there's no surprise there (much less a bombshell). It's just like any normal content, for which the default state of affairs is that policies don't ordinarily make blanket pronouncements that things "automatically" or inherently must be included. I also concur with BilledMammal and others on the problematic nature of "in-depth analysis or discussion of the name". Adumbrativus (talk) 06:44, 22 June 2023 (UTC)
• Oppose as the proposal in opposition to the purpose of an encyclopedia, which is to inform. Others above who oppose have also made arguments I agree with. Graeme Bartlett (talk) 09:04, 22 June 2023 (UTC)

  > "the purpose of an encyclopedia, which is to inform"

  Isn't that an argument against all the WP:BIO protections? And policies like WP:DUE, which also limit what we include? – .Raven  .talk 16:27, 22 June 2023 (UTC)

  One reason I see that supporters are failing here is that the argument has been commonly presented as an issue of respect for transgender people, and a general lack of understanding BLP protections and NOTCENSORED. A non-notable former name is protected as a matter of personal privacy for living people, with fading privacy after death and some other exceptions for the living. The proposal to expand this indefinitely has not been presented with a coherent argument outside of social norms in a gender studies class. Raven's response of, "other things are also censored" holds no weight. Cuñado ☼ - Talk 17:52, 22 June 2023 (UTC)

  But even the privacy protections for living people, if up for a vote now, could be answered "Oppose as the proposal in opposition to the purpose of an encyclopedia, which is to inform." Clearly prior consensus and policy had established that our "purpose to inform" is balanced by other considerations. Denying that balance is not in accord with this. – .Raven  .talk 19:31, 24 June 2023 (UTC)

• Support per Thryduulf and Aquillion. I consider this a reasonable implementation of the preceding RfC. I can understand that some editors have concerns about the exact wording, but in the spirit of not letting perfect be the enemy of good I don't see a problem with having this pass. After all, it can always be tweaked in future. XAM2175 ^(T) 16:09, 22 June 2023 (UTC)
• Support for reasons I gave in the pre-RfC discussion; in brief, I think this is a decent standard and a decent expression of the consensus of the last RfC (which called for this RfC); Wikipedia is not an indiscriminate collection of insignificant or undue information, especially when said information is gratuitous. I won't be surprised if, like everything else on Wikipedia (including other guidelines and policies), this wording can be and is improved upon over time, but aspirations of eventual perfection are not the enemy of getting a good guideline in place now as an improvement upon the current mess where the same general, non-article-specific arguments get hashed out repeatedly on different articles because there is no general guideline. -sche (talk) 17:21, 23 June 2023 (UTC)

  How is requiring that a name essentially meets notability requirements in order to be included in the article of its holder a reasonable reading of the consensus?! A fact about a subject that is repeatedly mentioned in RS about that subject most certainly is DUE even if the fact isn't "discussed in depth". If multiple secondary reliable sources report that a subject attended [university X] without going into any detail on it, we include that info. The prior RfC concluded that dead trans people's deadnames should be of encyclopedic value and also that deadnames are not inherently encyclopedic; that means inclusion requires a higher bar than a former name of a dead person would normally need (a mention in secondary RS). It doesn't mean it must be discussed to such an extent that it would qualify for its own subsection. JoelleJay (talk) 19:31, 23 June 2023 (UTC)

  Based on this comment and your previous comment it seems like you might be familiar with the current guideline, which does use notability as a criteria for the inclusion of dead names for living trans and nonbinary people. it's not unreasonable to use that as a point of reference for this proposal. Tekrmn (talk) 19:55, 23 June 2023 (UTC)

  The person must have been notable before transitioning, not the deadname. The deadnames of the vast majority of people who were notable before transitioning wouldn't even meet this bar! JoelleJay (talk) 02:24, 25 June 2023 (UTC)

  after the proposal says "their former name should only be included if the encyclopaedic significance of the deadname is established through in-depth analysis or discussion of the name in high quality sources" it says "or if they were notable prior to transitioning". the existing guideline reads "If a living transgender or non-binary person was not notable under a former name... it should not be included." in both the proposal and the current guideline notability is applied only to the person themselves. the purpose of this proposal is to codify that the if a deceased person wasn't notable under their deadname then there needs to be a good reason for the name to be included. Tekrmn (talk) 05:25, 25 June 2023 (UTC)

  It is irrelevant either way. If you are using notability as a standard for inclusion within an article either for the person or for the deadname, then you've violated WP:NNC. Huggums537 (talk) 05:30, 25 June 2023 (UTC)

  The current MOS:GENDERID as it is written is in contradictory violation of the general notability guidance which plainly states in the last sentence of the nutshell that it does not apply to content within articles. Huggums537 (talk) 05:34, 25 June 2023 (UTC)

we aren't here to discuss the existing MOS, but I think it's self-evident that notability is the best and easiest benchmark to use for the inclusion of deadnames. Tekrmn (talk) 06:39, 25 June 2023 (UTC)

• I am aware that all trans people who were notable before transitioning would have their deadnames included. What I'm saying is that even they would not meet the deadname notability requirements imposed here, which means the proposed criterion doesn't even correspond to the sourcing status of a deadname in cases where everyone agrees it is DUE under existing guidance. It also means that the proposal is essentially enforcing option 3, which did not receive consensus support. JoelleJay (talk) 17:07, 25 June 2023 (UTC)

  I may be misunderstanding you, but it still seems to me that you're under the impression that this proposal would be more restrictive than the existing guideline for living people, which is not the case. this proposal does not enforce option three because it allows for the inclusion of a deadname for people who were notable under that name (option 3) and people who weren't notable under their deadname, but who's deadnames were relevant in some way. if you feel that's too restrictive you can certainly hold that opinion, but this proposal is less restrictive than both option 3 and the current guideline for living people. Tekrmn (talk) 17:15, 25 June 2023 (UTC)

  Yes, you are misunderstanding me. The proposed criterion is functionally equivalent to option 3 because names do not get SIGCOV. We don't have a single example of a deadname that would qualify under this proposal. The fact that the deadnames of people who were notable under those deadnames don't receive SIGCOV demonstrates that SIGCOV of the name is completely arbitrary and unrelated to whether it is DUE enough for inclusion. JoelleJay (talk) 20:48, 25 June 2023 (UTC)

  Gloria Hemingway has been mentioned as someone who would meet this criteria. Marsha P. Johnson might as well, though her birth name was not a deadname to her as far as we're aware. I'm sure there are other examples. I agree that this proposal could be improved upon and that the criteria are probably too specific, but it's no more arbitrary than any other proposal that could arise from the space between options 2 and 3 of the last RFC and it does not apply SIGCOV to names, it uses similar criteria. even if it did use SIGCOV, we've seen with the current MOS that notability is a very useful tool when discussing deadnames. we aren't barred from including these criteria or even explicit references to WP:N in content policies or guidelines just because WP:N as a standalone policy doesn't apply to content. Tekrmn (talk) 04:01, 26 June 2023 (UTC)

  Several policies forbid guidance conflicts. See WP:POLICYFORK. Huggums537 (talk) 07:26, 26 June 2023 (UTC) Updated on 07:35, 26 June 2023 (UTC)

  Genuinely, it's your interpretation of WP:NNC that's off from everyone else's. (There's also the issue regarding what do about IAR relative to POLICYFORK, but alas.) I realize the language is at least slightly ambiguous, and perhaps NNC should be changed, but virtually everyone reads NNC as saying that WP:N, on its own, isn't meant to apply to content (e.g., just citing WP:N for a purpose content dispute would), not that content guidelines are prohibited from employing WP:N criteria for various determinations. After all, as we've discussed, WP:NOTDIRECTORY, which is also a policy, currently explicitly cites WP:N for content determination.--Jerome Frank Disciple 11:58, 26 June 2023 (UTC)

  If that were true, then the last sentence of the nutshell of WP:N would not say, The notability guideline does not determine the content of articles, but only whether the topic may have its own article. and the last paragraph in the lede would not say, They do not limit the content of an article or list, though notability is commonly used as an inclusion criterion for lists (for example for listing out a school's alumni). Huggums537 (talk) 12:58, 26 June 2023 (UTC)

  "not inherently of encyclopedic value" wasn't the only consensus found by the closer. Importantly, the closer found that the community believes that, for the most part, the prior name [of a deceased trans or non-binary person] should not be used.

  The largest single !vote count in the previous RFC by a substantial margin was option 3, which was that deadnames of non-notable individuals should never be used. The next highest was option 2, which was based on principle of least astonishment, or about where you're arguing for right now. The consensus of the community was that they wanted something between those two options. Loki (talk) 21:49, 23 June 2023 (UTC)

  (summoned by ping) My first impulse is to oppose based on wording. The notes are too long and don't feel altogether relevant, the footnote could be worked into the prose, and in-depth analysis of a name – the topic of that sentence – feels untenable. The wording seems insufficiently workshopped. My second impulse is to support before people spill another half megabyte of text bikeshedding this, knowing full well it will be bikeshedded in the tweaks after adoption.

  For transparency, I share partial blame for the existence of this RFC, since my call for recusals in an arbitration case pulled Barkeep49 away from their close, which would not have called for a follow-up RFC (not feeling diffs right now, but should be easy to track down).

  I think my only prior contribution in these plural RFCs was claiming the idea that we're doing this to respect the privacy of dead people seems misguided. If I see some dead trans person's non-notable pretransition deadname in an article, the impression I get is that Wikipedia does not respect trans people. It's more about making alive trans readers feel respected than it is about the privacy of dead people. I'm sure opinions differ, and I understand this RFC is not about that exacty.

  Folly Mox (talk) 22:25, 23 June 2023 (UTC)

  I think it's both. If we act with disrespect toward dead trans people, why should not living trans people take that as a sign of disrespect toward themselves as well? At the very least, a sign that they too will be treated likewise one day? On the other hand, if we act with respect toward the dead as well as the living, we are being consistent, and can be taken that way. – .Raven  .talk 01:20, 24 June 2023 (UTC)

  > "How is requiring that a name essentially meets notability requirements in order to be included in the article of its holder a reasonable reading of the consensus?!"

  MOS:GENDERID says:

  Refer to any person whose gender might be questioned with the name and gendered words (e.g. pronouns, man/woman/person, waiter/waitress/server) that reflect the person's most recent expressed self-identification as reported in the most recent reliable sources, even if it does not match what is most common in sources. This holds for any phase of the person's life, unless they have indicated a preference otherwise.

  If a living transgender or non-binary person was not notable under a former name (a deadname), it should not be included in any page (including lists, redirects, disambiguation pages, category names, templates, etc.), even in quotations, even if reliable sourcing exists. Treat the pre-notability name as a privacy interest separate from (and often greater than) the person's current name.

  The RfC closed June 7 made the specification "living or dead". – .Raven  .talk 02:24, 24 June 2023 (UTC)

  That guideline says nothing at all about the notability of names. JoelleJay (talk) 02:27, 25 June 2023 (UTC)

• Oppose: For starters, I'm opposed to the conclusion of the prior RfC; a subject's birthname is considered a notable fact that's included in biographical articles as a matter of course, and there is no legitimate reason beyond current gender politics why "deadnames" must be expunged from the record in the case of trans people who badly want to be shot of their previous names, but not in the case (say) of actors who badly want to be shot of their previous names. But to answer Folly Mox above, the mission of Wikipedia is not to respect trans people. It is to respect the facts, and the moment that facts become secondary to political concerns, we're a joke like Conservapedia. Any guideline or policy expunging a birthname that has been established by reliable sources should be opposed. Ravenswing 23:37, 23 June 2023 (UTC)

  > "... the mission of Wikipedia is not to respect trans people. It is to respect the facts...."

  I commend to your attention the Universal Code of Conduct, notably:
  

  2.1 Mutual respect

  ... People may use specific terms to describe themselves. As a sign of respect, use these terms when communicating with or about these people, where linguistically or technically feasible. Examples include: ...

  • People who identify with a certain sexual orientation or gender identity using distinct names or pronouns ....

  3.3 – Content vandalism and abuse of the projects

  Deliberately introducing biased, false, inaccurate or inappropriate content, or hindering, impeding or otherwise hampering the creation (and/or maintenance) of content. This includes but is not limited to: ...

  • Hate speech in any form, or discriminatory language aimed at vilifying, humiliating, inciting hatred against individuals or groups on the basis of who they are or their personal beliefs ....

  It seems to me this indicates that to respect people (trans or otherwise) is part of the mission of the entire Wikimedia project. – .Raven  .talk 01:49, 24 June 2023 (UTC)

  The Code of Conduct says "specific terms to describe themselves. ... use these terms". The RfC say "include" ie "mention". "Using" and "mentioning" are two different things. The Use–mention distinction seems to be lost on many of this discussions' contributors. Mitch Ames (talk) 02:31, 24 June 2023 (UTC)

  If we're going to mention such people, what distinct name do we use to do so? Per UCoC, the one they use. – .Raven  .talk 03:38, 24 June 2023 (UTC)

  Use: "John is a trans man". Mention: "He was previously known as Mary". Analogously to the example in the Use–mention distinction, the first sentence is a statement about the person (it uses the name to refer to the person). The second sentence is a statement about the name (it mentions the name without using it to refer to anything other than itself). Mitch Ames (talk) 04:04, 24 June 2023 (UTC)

  > "He [John] was previously known as Mary" ... mentions the name without using it to refer to anything other than itself.

  Puzzling statement, since the inner quote makes quite clear that name refers (or referred) to John. In fact the two sentences together are logically equivalent to the deprecated form, "Mary changed her name to John when she transitioned to male." — which exchanges the rôles of the two names by your rule. That seems to make this use of the Use-mention distinction a dodge.

  For clarity. That article has the example of cheese (the dairy product) and "cheese" (the word):

  • Use: Cheese is derived from milk.
  • Mention: "Cheese" is derived from (the Anglian variant of) the Old English word ċēse (pronounced [ˈt͡ʃeː.ze]).

  By comparison, mention of the name "Mary" ('not referring to anything other than itself') could say:

  "Mary /ˈmɛəˌri/ is a feminine given name, the English form of the name Maria, which was in turn a Latin form of the Greek name Μαρία, María or Μαριάμ, Mariam, found in the Septuagint and New Testament."

  But it is use of the name "Mary" to say that it refers to John.

  ---

  By the way, I can never watch The Winchesters again without thinking of this, perhaps suggesting that an All You Zombies scenario is due to occur. – .Raven  .talk 04:31, 24 June 2023 (UTC)

  But it is use of the name "Mary" to say that it refers to John. — I disagree. In John is a trans man, The word "John" denotes or refers to a specific person. In He was previously known as Mary, the word "Mary" denotes or refers to a specific name. That name might denote a person is some sentences, (eg As a child, before transitioning, Mary attended an all-girls school) but not in ... was known as Mary. It might be make more sense (or be more obviously words-as-words) with quotation marks: He was previously known as 'Mary' . Perhaps the quotation marks are strictly required, but no reasonable person would misinterpret the meaning of the sentence (in context) without them.

  Note that my argument regarding the use-mention distinction is independent of whether WMF's Universal Code of Conduct applies. Regardless of whether it is WP:GENDERID or UCoC, the general rule is: use a person's current name; but that does not prohibit mentioning a former name. Mitch Ames (talk) 08:38, 24 June 2023 (UTC)

  > "In He was previously known as Mary, the word Mary denotes or refers to a specific name. That name might denote a person i[n] some sentences,... but not in ... was known as Mary."

  You had to remove the "He" and replace it with an ellipsis in order to make that last claim, because in the untruncated sentence "He" (or "John") "was known as Mary", that latter name clearly denotes the same person as "He" (or "John"), in fact that's the point of the sentence.

  In a sentence like "He always thought 'Mary' was a beautiful name", "Mary" does not denote any person, and does refer to nothing but itself.

  See the difference? – .Raven  .talk 09:23, 24 June 2023 (UTC)

  I see the difference, but maintain my position. In He thought 'Mary' a beautiful name, the word "Mary" denotes a name that does not denote any specific person. In John was known as 'Mary' (with or without quotes around Mary), the word "Mary" denotes a name, not the person with the name "Mary" (ie John). We are using the word "Mary" to denote/refer to a name, not to denote the person that the name "Mary" denoted. In the same way that the name is not the person ("the word is not the thing"), a reference to the name (ie "was known as Mary") is not a reference to the person. Mitch Ames (talk) 12:37, 24 June 2023 (UTC)

  But that latter quoted sentence states that the name refers to (denotes) that person.

  As for "the word is not the thing", then the name "John" also isn't the person.

  And "Mark Twain" isn't Mark Twain. "Samuel Clemens" isn't Samuel Clemens. But if I say, Mark Twain was privately known as Samuel Clemens, will you tell me that one name or the other does not refer to (denote) that person? – .Raven  .talk 19:43, 24 June 2023 (UTC)

  will you tell me that one name or the other does not refer to (denote) that person — In the sentence Mark Twain was privately known as Samuel Clemens, the words "Samuel Clemens" denote the name, not the person. I still assert that in your sentence we are using the name "Mark Twain" (the words denote the person) and mentioning the name "Samuel Clemens" (the words denote the name). I suspect that we may simply have to agree to disagree here, but I still think that - regardless of debates about semantics - a sentence such as "John was previously known as Mary" does not contravene a policy that says "Use the person's preferred name". Mitch Ames (talk) 06:28, 25 June 2023 (UTC)

  the use of quotation marks to me indicates a distinction between "use" and "mention" much more clearly than what is used to principally refer to the person (as was discussed in above comments), and we do not do that when we include deadnames in articles. additionally, can we really say we aren't using a name to refer to someone when we are including it for the sole purpose of illustrating that it has been used in the past to refer to someone? I agree that it's not the same as referring to them by that name, but it is at best a gray area and definitely not the same as a mention of a name with no connection to that person.

  I agree that this conversation is largely semantics, but I don't think the takeaway from that should be "we aren't breaking the guideline because using isn't the same as mentioning" it should be "trans people generally don't want their deadname to be used to refer to them or to be public knowledge so we should avoid it when we can." Tekrmn (talk) 14:55, 25 June 2023 (UTC)

  @Mitch Ames I'd strongly recommend going back over the full UCoC, and not engage any argument that relies on a user conduct policy as the basis for a content discussion. You're being misled. —Locke Cole • t • c 05:00, 24 June 2023 (UTC)

  @Mitch Ames: See below (linked). – .Raven  .talk 05:36, 24 June 2023 (UTC)

  It's the USER CONDUCT policy, even the title should be drop dead obvious to anyone that it has nothing to do with editorial or content decisions. Please stop trying to right great wrongs, it's disruptive. —Locke Cole • t • c 05:39, 24 June 2023 (UTC)

  > "Please stop trying to right great wrongs, it's disruptive."

  Citing & quoting our own policies, guidelines, etc., is "trying to right great wrongs"?!

  Citing & quoting our own policies, guidelines, etc., is "disruptive"?!

  When did citing & quoting our own policies, guidelines, etc., become against policies, guidelines, etc.? – .Raven  .talk 05:54, 24 June 2023 (UTC)

  You're deliberately misinterpreting them to fit the great wrong you're trying to right. That's disruptive. Knock it off. —Locke Cole • t • c 05:57, 24 June 2023 (UTC)

  Cite/links with direct verbatim quotes are now misinterpretation? Wow. – .Raven  .talk 06:46, 24 June 2023 (UTC)

  Yes when you're deliberately mischaracterizing the intent to suit your agenda. —Locke Cole • t • c 06:56, 24 June 2023 (UTC)

  And what exactly do you claim is my "agenda"? – .Raven  .talk 07:03, 24 June 2023 (UTC)

  WP:RGW —Locke Cole • t • c 07:08, 24 June 2023 (UTC)

  Addressed above. You've gone in a circle. – .Raven  .talk 09:09, 24 June 2023 (UTC)

  Nope. —Locke Cole • t • c 10:26, 24 June 2023 (UTC)

  The UCoC has nothing whatsoever to do with this. It describes conduct amongst editors of the project, not content decisions. @Ravenswing is correct, respecting trans people is not a mission of the project (either locally, or at a foundational level). And to engage in that will open up the floodgates of other groups wanting our content to conform to their views, all of which would run afoul of WP:NPOV. —Locke Cole • t • c 04:59, 24 June 2023 (UTC)

  > "The UCoC... describes conduct amongst editors of the project, not content decisions."

  Directly above, I quoted a portion of the UCoC's "3.3 – Content vandalism and abuse of the projects":

  Deliberately introducing biased, false, inaccurate or inappropriate content, or hindering, impeding or otherwise hampering the creation (and/or maintenance) of content. This includes but is not limited to: ...

  • Hate speech in any form, or discriminatory language aimed at vilifying, humiliating, inciting hatred against individuals or groups on the basis of who they are or their personal beliefs ....

  To say that this does not describe content decisions seems rather obviously false.

  > "... respecting trans people is not a mission of the project (either locally, or at a foundational level)."

  Locally, WP:DEADNAME's "Refer to any person whose gender might be questioned with the name and gendered words (e.g. pronouns, man/woman/person, waiter/waitress/server) that reflect the person's most recent expressed self-identification...." [emphasis in original]  certainly seems to advocate respecting at least trans people's preferences of name, pronoun, and job description gender.

  So again, well....

  > "And to engage in that will open up the floodgates..."

  Slippery slope fallacy. – .Raven  .talk 05:26, 24 June 2023 (UTC)

  Directly above, I quoted a portion of the UCoC's "3.3 – Content vandalism and abuse of the projects": How nice for you. You quoted part of the USER CONDUCT policy relating to not vandalizing the project. Yet again, nothing to do with making editorial decisions. Following our sources can never be considered "hate speech" or "vilifying" or any other adjective you come up with to describe being accurately described based on reliable sources. To say that this does not describe content decisions seems rather obviously false. It's rather obviously false to suggest this has any bearing whatsoever on editorial decisions. —Locke Cole • t • c 05:35, 24 June 2023 (UTC)

  > "You quoted part of the USER CONDUCT policy relating to not vandalizing the project. Yet again, nothing to do with making editorial decisions."

  It takes being a user to make editorial decisions; here the user conduct being addressed was "Deliberately introducing biased, false, inaccurate or inappropriate content, or hindering, impeding or otherwise hampering the creation (and/or maintenance) of content." Clearly those are editorial decisions and actions — just bad ones.

  Are you perhaps trying to distinguish between the decisions/actions of several users/editors, vs. just one?

  But the UCoC doesn't say anything about approving hate speech, etc., if several editors engage in it. – .Raven  .talk 05:47, 24 June 2023 (UTC)

  Deadnaming trans individuals when our reliable sources do so is not "hate speech". As above, you're trying to twist a completely irrelevant policy to fit a great wrong you're trying to right. —Locke Cole • t • c 05:59, 24 June 2023 (UTC)

  You may be missing the point. I used the UCoC's frowning on hate speech as an example of (a) a statement about content which (b) suggests that respecting people – including trans people – is indeed a mission of the project. Otherwise why have that statement?

  Oh wait, are you still denying that the UCoC discusses content decisions? – .Raven  .talk 06:53, 24 June 2023 (UTC)

  Oh wait, are you still denying that the UCoC discusses content decisions Sure am. Because it doesn't. It's user conduct, as the title explains and that you seem to keep conveniently ignoring. —Locke Cole • t • c 06:57, 24 June 2023 (UTC)

  Addressed above. – .Raven  .talk 07:00, 24 June 2023 (UTC)

  And refuted. Go on. —Locke Cole • t • c 07:08, 24 June 2023 (UTC)

  A cite/link and verbatim quote of the UCoC is not "refuted" by missing the point. – .Raven  .talk 07:10, 24 June 2023 (UTC)

  I do believe you've missed the point of the UCoC. Or you're being willfully disruptive because of WP:RGW, again. —Locke Cole • t • c 07:21, 24 June 2023 (UTC)

  Addressed above. You're going in circles again. – .Raven  .talk 09:10, 24 June 2023 (UTC)

  I see you’re still having problems with words. Hint: you haven’t “addressed” anything. —Locke Cole • t • c 10:26, 24 June 2023 (UTC)

  > "Hint: you haven’t 'addressed' anything."

  Then why have you replied? – .Raven  .talk 19:05, 24 June 2023 (UTC)

  I'll try not to reiterate Locke Cole's points, to which I concur in their entirety. But while you're talking about slippery slope fallacies, you are indulging in one yourself: the notion that "hate speech" is synonymous with "any construction that any one person stridently and vocally dislikes." If what you're indeed arguing is that the use of verified birthnames in articles constitutes "hate speech," to the degree that even advocating doing so is hate speech, then you have gone completely over the deep end. Wikipedia is not censored, even to grant fringe viewpoints "safe spaces," and we are not enjoined to accept your characterizations. Ravenswing 06:03, 24 June 2023 (UTC)

  Oh geez my reply generated a subthread invoking the UCoC, hate speech, and the use–mention distinction? Someone give me an anti-award for unclarity. I'm having difficulty finding where I claimed that being seen as respecting trans people is Wikipedia's mission (other than right here, in this use–mention distinction). I was juxtaposing it with the idea of respecting dead people's privacy, not movement charters or core content policies.

  I was under the impression that the previous RFC closed with consensus that deadnames are not automatically encyclopaedic, and so I didn't bother to mention that. Most of the time they're trivia, like the identities of important animal companions, or reasons for a divorce, or salary. All facts, all parts of people's lives that impact their story, usually trivia.

  What I'm finding myself in strongest support of in this moment is Deadnames of deceased trans people are not automatically encyclopaedic. If insertion or deletion of a deadname is challenged, discuss it on the article talk page. Once consensus is reached, the topic cannot be reopened for 9+12n months, where n is the number of prior discussions on the topic. Folly Mox (talk) 06:38, 24 June 2023 (UTC)

  Why would we do this when it goes against our core, non-negotiable, policy around neutrality? What is the benefit to the project in doing this that isn't just a very well dressed WP:RGW? —Locke Cole • t • c 06:42, 24 June 2023 (UTC)

  Well, my proposed policy wording is not intended to be taken seriously. No one votes for algebra. I'm just tired. Mostly it's a restatement of the bit of the previous close reading the former name of a trans or non-binary person is not automatically of encyclopaedic interest, which I guess in your analogy might be a very confusingly dressed WP:TRIVIA? I was under the impression that the present RFC is a follow up to the preceding one, not a close review, but I readily admit having not read this entire conversation. I guess it will be up to the closer how to deal with positions that reject the prior closure. Folly Mox (talk) 07:14, 24 June 2023 (UTC)

  > "I was under the impression that the present RFC is a follow up to the preceding one, not a close review"

  So was I. The previous RfC's minority appear to have tried to change that. – .Raven  .talk 07:18, 24 June 2023 (UTC)

  In fact, not not only have I not read the full conversation, I've only just now realised this subthread wasn't generated by my initial comment, but by the following one. Oops. Must be bedtime. Folly Mox (talk) 07:21, 24 June 2023 (UTC)

  @Folly Mox, I think our guidance should just stick to what the close said: Deadnames of deceased trans people are not automatically encyclopedic.

  Using the bounds introduced in the prior RfC (not that I necessarily agree with its outcome), this could mean that adding a deadname should be discouraged in general and should require documentation in multiple IRS that provide SIGCOV on the trans person, but the trans person need not have been notable pre-transition. With this construction, we would only be providing the deadnames of people who are/were widely covered (have 3+ pieces of SIGCOV), whose deadnames would therefore be more likely to be "widely known" already. JoelleJay (talk) 02:46, 25 June 2023 (UTC)

  > "the notion that 'hate speech' is synonymous with 'any construction that any one person stridently and vocally dislikes'."

  Except I neither expressed nor held such a position. I cited the UCoC in reply to the claim that ""... the mission of Wikipedia is not to respect trans people. It is to respect the facts...."". As I said then, "It seems to me this indicates that to respect people (trans or otherwise) is part of the mission of the entire Wikimedia project."

  "Hate speech" is an example of the contrary, emphatically disrespecting people... and the Board frowns on it. – .Raven  .talk 07:15, 24 June 2023 (UTC)

  The UCoC does not say what you think it says, and certainly not how you mean it. —Locke Cole • t • c 07:20, 24 June 2023 (UTC)

  I cite/linked it and quoted it verbatim (copy&paste). Sorry if it doesn't say what you wanted it to. – .Raven  .talk 09:12, 24 June 2023 (UTC)

  Same for you. I hope someday you understand what a user conduct policy is. —Locke Cole • t • c 16:45, 24 June 2023 (UTC)

  This one expects users to conduct themselves toward other people with respect. Even in our article edits. – .Raven  .talk 19:49, 24 June 2023 (UTC)

  Even in our article edits. —Locke Cole • t • c 04:42, 25 June 2023 (UTC)

• Weak oppose. The requirement for in-depth analysis or discussion would imply that for historical figures, the name itself must be discussed and analyzed, rather than simply be used. If a historical figure is consistently referred to in the historical record by a deadname rather than a preferred name, said name should be included. Chess (talk) (please mention me on reply) 02:14, 24 June 2023 (UTC)

  If they are consistently referred to by a deadname then they were notable under that name, therefor the deadname would not have to meet the criteria of "discussed and analyzed" to be included. Tekrmn (talk) 08:23, 24 June 2023 (UTC)

• Oppose - largely along the same lines of reasoning as Chess voices immediately above. There may be some permutation of this proposal that I could support, but the proposed language would create substantial issues for constructing functional content in edge cases--and generate no small number of disputes in the process, I dare say. As worded, the proposal would introduce a standard (and a pretty robust one at that) where the original name itself would have to be subject to considerable coverage: if I read the language correctly, mere usage (even massive usage over decades greatly outweighing the usage of the post-transition name) would not be enough to even warrant mention of the former name, if the name itself was not subject to significant coverage--a standard that is almost never going to be met. Now, even if I am reading that language incorrectly and imputing a meaning not intended, or exaggerating the intended proposed burden, it's certainly at least a probable interpretation likely to be embraced by a non-trivial number of editors, giving rise to potential editorial disputes.
  In either event, bluntly, it's not a workable standard and loses sight of our purpose here, which is to construct accessible and informative encyeclopedic prose, not to affirm the individual's rights to self-determination as the primary goal of our prose, in every way and in every instance. Don't get me wrong, to the extent we can accomplish the latter without compromising the former, there is no excuse not to. Unfortunately, this is one of those cases where I think the proposed approach would create singificant possibility in favouring the latter over the former quite regularly in the case of relevant articles. Putting aside for the moment the abstractions involved in trying to determine whether a deadname is valuable encyclopedic content as an 'a priori' matter, there's this simple detail alone that makes its inclusion of paramount utility to our readers: many of our readers will not, in the case of a particular subject, want to make Wikipedia the last stop for their research about a given biographical subject. If we make a knowing, purposeful decision to hide from them a key piece of context for that would aid them in further research, even in cases where we know the single most central search term they should be using to find the vast majority of sources pertaining to that subject, we have simply lost sight of our priorities as authors of the world's most turned-to encyclopedia.
  Now, let me qualify further, that I do think this comes down to an issue of WP:WEIGHT. I can well see a vast number of cases where the deadname is simply not WP:DUE, and not only can I imagine myself !voting as such in a large number of cases, I'd go further to saying I hope we see more discussions making that argument: there are probably lots of articles already that could benefit from it. However, that's actually just additonal argument for why this change is not advisable: the benefit it would confer in unambigous cases is already to be found in other policies, whereas this proposal only brings not just potential for excising content highly useful to the reader, but introduces additional ambiguity/weighing of competing factors into the editorial process, and would be a lightning rod for further disputes in an area already highly prone to them. Again, there's probably a version of this I can get behind, but the proposal here is so overbroad and inartfully constructed that I can't say that I find it advisable, even as someone who could most assuredly stand to see deadnames in a fewer number of articles where they serve little purpose. SnowRise ^{let's rap} 05:15, 24 June 2023 (UTC)
• Oppose per @Only in death, BilledMammal, and JoelleJay: because this is too restrictive to make any allowance for the mention of content in articles, and per WP:NNC notability should not be a factor for content within articles anyway. Huggums537 (talk) 11:55, 24 June 2023 (UTC)
• Oppose per Huggers537 and Some1, among others. While neutrally phrased, in practice it's an impossible bar to meet. Encyclopedic value of a fact is something to be worked out on individual article talk pages.--Wehwalt (talk) 17:26, 24 June 2023 (UTC)
• One problem is that I don’t think we CAN split the difference between option 2 (“Sometimes”) and option 3 (“Never”) - because anything more than “Never” IS “Sometimes”. Even “rarely” is “sometimes”. Blueboar (talk) 21:29, 24 June 2023 (UTC)

  But +5 times splits the difference between +0 times and +10 times. In other words, reduces how often is "sometimes". – .Raven  .talk 21:43, 24 June 2023 (UTC)

  Option 2 wasn't just "sometimes" though, it was a fairly permissive sometimes based on principle of least astonishment. This is a more restrictive sometimes, and as you can see it's getting about 50% support. Hopefully we can find a Goldilocks wording at some point. Loki (talk) 01:08, 25 June 2023 (UTC)

  I think we probably can, but nothing that's going to sail through. There are members of the opposition who are going to oppose any additional restriction, so the question will be whether we can find a version that satisfies the remaining, I'd estimate, 65-75% of editors. I think the next thin we'll have to seriously gauge is the community's appetite for another RFC ... though, of course, if nothing is discovered, it'll just come down to relatively repetitive article-by-article discussions that will likely entail RFCs. If that ends up being the case, I'll sort of regret that option 2 wasn't adopted as a clear consensus over the options for no change / always, because I think "consideration of the majority of reliable sources" provides at least some guidance that's both (1) not nothing and (2) workable.)--Jerome Frank Disciple 22:13, 25 June 2023 (UTC)

• As discussed in #Thinking through the difficulties, I think a version which includes the mention of the deadname further down the article as an example, or some wording which makes it clearer that the deadname's preferred position is not always the lede would be better. Otherwise, I'm neutral on the proposal – "in-depth analysis" feels like too strong of wording to me. Skarmory (talk • contribs) 05:06, 26 June 2023 (UTC)

Discussion (GENDERID addition)

• Notified WikiProjects LGBT Studies, and Biography. Notified WT:MOSBIO. Sideswipe9th (talk) 22:11, 12 June 2023 (UTC)

  Any thought about pinging people who participated in the last RFC? Or posting to WP:CENT like the last one? Since this RFC is clearly a continuation of that one I feel like it'd be appropriate. Loki (talk) 04:23, 13 June 2023 (UTC)

  I think posting to CENT is a good idea, and I have no objections to pinging people (although preferably only those who haven't yet commented in this RFC). Thryduulf (talk) 10:41, 13 June 2023 (UTC)

  Posted to CENT. Pinging prior optionTypo fixed—I did not just ping the option 2 supporters; sorry for the miscommunication! topic 2 !voters who have not !voted here (trying not to ping those who have already participated, apologies if I fail on that front) @Skyerise, Bilorv, Starship.paint, Ineffablebookkeeper, Tekrmn, DanielRigal, RoxySaunders, Yasslaywikia, HTGS, Stwalkerster, BilledMammal, Hatman31, 3mi1y, Mitch Ames, Jayron32, Trovatore, ModernDayTrilobite, Springee, Voorts, Spy-cicle, Ficaia, Stifle, MJL, MarijnFlorence, A Tree In A Box, Anomie, WhatamIdoing, CoffeeCrumbs, Nosebagbear, SmallJarsWithGreenLabels, Chaotic Enby, Why? I Ask, Ser!, Thesavagenorwegian, XOR'easter, RAN1, Rutebega, GRuban, Casualdejekyll, and TheCatalyst31:@Herostratus, Locke Cole, Adumbrativus, Rab V, CandyScythe, Lights and freedom, Sceptre, Gnomingstuff, Ad Orientem, -sche, LilianaUwU, Jc3s5h, Brainulator9, Blindlynx, Gobonobo, Tryptofish, Bastun, XAM2175, Shibbolethink, Jamesday, Funcrunch, Horse Eye's Back, Cambial Yellowing, Tol, Nerd1a4i, SWinxy, AquilaFasciata, Aquillion, Licks-rocks, EddieHugh, GreenComputer, SportingFlyer, and Patar knight:--Jerome Frank Disciple 18:50, 13 June 2023 (UTC)

  Do you mean question 2 rather than option 2? Loki (talk) 18:53, 13 June 2023 (UTC)

  Yes, absolutely—sorry about that.--Jerome Frank Disciple 18:55, 13 June 2023 (UTC)

  FWIW, I didn't receive a ping from this; IIRC there is a limit to how many users can be pinged at once, so that may be why. -sche (talk) 04:05, 15 June 2023 (UTC)

  Yeah. The message that Jerome typed had 73 usernames in it. According to WP:MENTION the limit is 50 per edit. Sideswipe9th (talk) 04:14, 15 June 2023 (UTC)

  Per edit, not per ping template... as Jerome carefully used two ping templates, one with 40 names, one with 33 (note the :@ before Herostratus, which was at the break).
  Corrective ping: @LilianaUwU, Jc3s5h, Brainulator9, Blindlynx, Gobonobo, Tryptofish, Bastun, XAM2175, Shibbolethink, Jamesday, Funcrunch, Horse Eye's Back, Cambial Yellowing, Tol, Nerd1a4i, SWinxy, AquilaFasciata, Aquillion, Licks-rocks, EddieHugh, GreenComputer, SportingFlyer, and Patar knight: Please see Jerome's comment above. – .Raven  .talk 04:20, 15 June 2023 (UTC)

  Unfortunately, it isn't that simple to correct; it doesn't send the ping to the first fifty names listed in the post - -sche was #50 and I was #11, and neither of us received the initial ping. BilledMammal (talk) 05:12, 15 June 2023 (UTC)

  Here comes another try: @Skyerise, Bilorv, Starship.paint, Ineffablebookkeeper, Tekrmn, DanielRigal, RoxySaunders, Yasslaywikia, HTGS, Stwalkerster, BilledMammal, Hatman31, 3mi1y, Mitch Ames, Jayron32, Trovatore, ModernDayTrilobite, Springee, Voorts, Spy-cicle, Ficaia, Stifle, MJL, MarijnFlorence, A Tree In A Box, Anomie, WhatamIdoing, CoffeeCrumbs, Nosebagbear, SmallJarsWithGreenLabels, Chaotic Enby, Why? I Ask, Ser!, Thesavagenorwegian, XOR'easter, RAN1, Rutebega, GRuban, Casualdejekyll, and TheCatalyst31: Please see Jerome's comment upthread. – .Raven  .talk 06:40, 15 June 2023 (UTC)

  @Herostratus, Locke Cole, Adumbrativus, Rab V, CandyScythe, Lights and freedom, Sceptre, Gnomingstuff, Ad Orientem, and -sche: Please see Jerome's comment upthread. – .Raven  .talk 06:42, 15 June 2023 (UTC)

  Alright. Now what do I do? Herostratus (talk) 01:46, 16 June 2023 (UTC)

  @Herostratus: There's an ongoing RfC here, following up the grey area left by the prior RfC. We just wanted to notify that RfC's participants (like you), so you can – if you wish – participate. – .Raven  .talk 01:51, 16 June 2023 (UTC)

  @BilledMammal and -sche: I apologize to both of you and all users who didn't get a ping—after all that work, nothing! @.Raven correctly clocked it: I mistakenly thought the 50-cap was related to the ping template, not the alert-system generally, so I thought I was safe using two ping templates. (Also thanks to .Raven for fixing my error!)--Jerome Frank Disciple 13:01, 15 June 2023 (UTC)

  Got this, I also did not get the original ping. Gnomingstuff (talk) 14:12, 15 June 2023 (UTC)

  I don't recall getting any pings here, either. -BRAINULATOR9 (TALK) 01:50, 16 June 2023 (UTC)

  Is there a reason not to notify all the participants of the first RfC? I count around 20 people who participated in other RfC 1 proposals or who commented but didn't !vote in proposal 2. @Alaexis, Aza24, BrxBrx, Chess, Cwater1, Folly Mox, Indy beetle, Kurtis, Lee Vilenski, NatGertler, Ravenswing, Shells-shells, Skarmory, Snow Rise, TrangaBellam, TulsaPoliticsFan, and UndercoverClassicist:. JoelleJay (talk) 21:29, 23 June 2023 (UTC)

  i am too tired, and too bound up by the reality that the trans individuals I know have widely different relationships to the names that they used pre-public transition to wade through all the text that's here now and try to nuance it out. But thanks for thinking of me. -- Nat Gertler (talk) 22:58, 23 June 2023 (UTC)

• Question… wouldn’t having “in-depth analysis or discussion of the name in high quality sources” be (itself) an indication that the person was considered “notable prior to transitioning”? Why else would the source discuss it? Blueboar (talk) 11:20, 13 June 2023 (UTC)

  Off the top of my head, in good faith it could be discussed in the context of names, or of name changes (e.g. an in-depth article about people called "Monica" and why they chose or didn't choose to change their name to or from that). There are also several ways it could be used in bad faith to out and/or attack someone. There are probably other ways too. Thryduulf (talk) 16:10, 13 June 2023 (UTC)

  So the consensus of the just closed RfC is that the former names of trans and non-binary individuals are not considered to be automatically of encyclopaedic interest. There has to be something about the name change that raises it above being a minor aspect of the person's fuller life story. For example, is there a reason why the person picked the name? Was it in honour of or to remember a friend or relative? Is there a deeper meaning behind the name that links in to other aspects of the person's life? Does it tie into their spirituality, religion, or cultural background in some meaningful way?

  As for why the bar is high (and this is as much a reply to Trystan as Blueboar), I'd like to draw attention to a side discussion on Barkeep49's talk page, from just after the close of the last RfC. Barkeep49 said The way I was going to handle the near, but not quite reached, consensus for option 3 (what SFR is calling 2.8) was by saying that 3 had consensus, but by footnote or other mitigating language the not completely absolute nature of that consensus should be noted. By my reading, and that of the RfC's closer, that is setting the bar higher than just discussion of the name in high quality sources. There needs to be a depth to the discussion, in order to adequately reflect just how high a bar for inclusion the current consensus is. Sideswipe9th (talk) 16:33, 13 June 2023 (UTC) Note, I got this for example bit backwards. We're discussing why we should include the old name, not the new one. Sorry. Sideswipe9th (talk) 17:18, 14 June 2023 (UTC)

  While I definitely said what is quoted here, I'm having trouble parsing that is setting the bar higher than just discussion of the name in high quality sources. Namely whether my comment is being used to support Sideswipe or whether Sideswip is criticizing my comment. Barkeep49 (talk) 17:06, 13 June 2023 (UTC)

  For clarity, I'm not criticising your comment. I think it's a good and fair reading of the consensus that exists from the previous RfC. I'm simply using an interpretation of your comment to explain why the proposal's barrier for inclusion is set high. Sideswipe9th (talk) 17:29, 13 June 2023 (UTC)

  If indeed the individual had been notable under the prior name (before or after physically transitioning), surely that could be established by usual measures of notability, without our needing to state more? LOW-quality sources (e.g. yellow-sheet journalism, "scandal rags") are generally not accepted as RS for that, are they? – .Raven  .talk 07:21, 14 June 2023 (UTC)

  > "There has to be something about the name change that raises it above being a minor aspect of the person's fuller life story." – Umm, that would be a matter of the new name, not the old one, so not affect notability of the old name. Just as, if there's nothing about the name change that raises it, etc., it still won't affect the old name's notability at all.
  Chelsea Manning had... notoriety?... under her old name; it was in worldwide news, it will always be notable. Why she chose "Chelsea" doesn't matter, even if she earns fame for a different reason under that name. But (to use the Sandman character) a non-notable "Alvin Mann" who transitions to the chosen name "Wanda" and only then becomes notable should be discussed here only as "Wanda"... again no matter what her reason for picking that name. – .Raven  .talk 07:36, 14 June 2023 (UTC)

  You're looking at it from the wrong perspective. The question is not what makes the new name of encyclopaedic interest, it's what makes the old name of interest. From the last RfC we already have a clear consensus that a former name is not automatically of encyclopedic interest, so there has to be something about the former name that makes it of interest.

  Manning isn't a great example here, because she's alive and so subject to the guidance in the second and third paragraph of GENDERID. However as a thought experiment, if Manning was decased, the incident that lead to her notability happened prior to her transition. So she's covered under the if they were notable prior to transitioning clause.

  So for Wanda (and thanks for using that example cause Sandman is one of my favourite graphic novel series), we in all likelihood would not include her former name. That she changed it from Alvin as part of her transition doesn't raise above the minor aspect threshold for us as an encyclopaedia, though obviously it is hugely important to her own sense of self and personal life. We also don't need to state her former name in order to record that her parents deadnamed her at her funeral and on her tombstone. Sideswipe9th (talk) 16:36, 14 June 2023 (UTC)

  > "... so there has to be something about the former name that makes it of interest." – This is what I thought I just supported, as with Manning and Mann. Meanwhile, asking about the name change – "... is there a reason why the person picked the name? Was it in honour of or to remember a friend or relative? Is there a deeper meaning behind the name that links in to other aspects of the person's life? Does it tie into their spirituality, religion, or cultural background in some meaningful way?" – only concerns the new name, and doesn't affect the notability of the old name, i.e. doesn't give a reason why that too should be in the article. – .Raven  .talk 16:44, 14 June 2023 (UTC)

  Re: ... only concerns the new name, and doesn't affect the notability of the old name .... — well, only if the only old name is the birth name. Theoretically a person could change names before transitioning and then switch to their current name.

  I think, as I currently understand the policy, that it would be most likely to capture persons who have either wavered (or been thought to waver) on their trans identity after becoming notable or embraced multiple names/identities (like Hemingway and Izzard).--Jerome Frank Disciple 16:56, 14 June 2023 (UTC)

  > "or embraced multiple names/identities" – We report on all of David Bowie's names, including David Robert Jones and Ziggy Stardust, but then he never attempted to hide any of them, and no physical transition was involved. (This may not even be a fair example to use, as "stage names" are involved.) People who change names (and genders) before becoming notable may prefer a complete separation, the equivalent of WP:CLEANSTART... and I'm suggesting that we extend the same courtesy to them as to each other here. – .Raven  .talk 20:48, 14 June 2023 (UTC)

  Oh I think I misunderstood. You're saying you'd prefer Option 3 in the last RFC to this proposal. I think that's fair (IIRC, I went with option 2, but that was because my experience in a prior RFC had lead me to think that option 3 didn't have a chance, and I figured some increased restriction was better than no change. (I have no idea why I believed this ... but I for some reason assumed that if there was a consensus to change the current guideline, the closer would pick the compromise option. To be clear that's not a critique of the closer ... I'm baffled that I just assumed that ... even then, I knew better, and if someone had asked "What are you talking about?" I would've immediately been like "oh wait. no." ... but there multiple instances of me being like "yup; here's what I'm planning" in various comments before the RFC.) Anyways ...--Jerome Frank Disciple 20:55, 14 June 2023 (UTC)

  Well, #3 ("never") would be simpler, but as I said above, not well cover situations where the old name was already notable. This proposal (between #2 "sometimes" and #3 "never") helps navigate that situation, making the exception only for names notable before the change – again, as with Chelsea Manning. I think that threads the gap between the two options. – .Raven  .talk 22:12, 14 June 2023 (UTC)

  only concerns the new name, and doesn't affect the notability of the old name You're absolutely right. I made that comment in error and will be striking it in a moment, as I got it the wrong way around (I blame the summer heat, it's too warm where I am!). Sideswipe9th (talk) 17:16, 14 June 2023 (UTC)

  Summer heat is indeed distracting!   😅💦   – .Raven  .talk 18:06, 14 June 2023 (UTC)

• The above background section is, inevitably, a partial description of the previous RfC. I encourage people to read the original questions, options and closes. To be clear, the question that was asked was "If a deceased trans or nonbinary person was not notable prior to transitioning, when should an article mentioning that person include their deadname?" and the closer stated that "For the specific proposals of the RFC, there is no consensus to change the current wording of MOS:GENDERID". EddieHugh (talk) 19:35, 13 June 2023 (UTC)

  I'm unclear what that adds. Yes, "for the specific proposals" that were previously advanced, there was no consensus, because the censuses was between two of those proposals. And how did I not capture the question asked in my first sentence? Oh well.--Jerome Frank Disciple 19:38, 13 June 2023 (UTC)

  Note, I've moved these two comments from the #Background section above. If you want to discuss changing the wording of that section, do it here please, not up there. Sideswipe9th (talk) 19:42, 13 June 2023 (UTC)

  ok. Please state clearly in that section what the question and main finding were. EddieHugh (talk) 19:50, 13 June 2023 (UTC)

  Question is already stated (see first sentence). Will add the "for the specific proposals" line.--Jerome Frank Disciple 20:00, 13 June 2023 (UTC)

  Honestly I would just reword that section into something much simpler. Something like A recent RfC closed with the consensus that the community "believes that, for the most part, the prior name [of a deceased trans or non-binary person] should not be used". However the community fell short of finding a consensus for a specific barrier for inclusion based on the options presented. The purpose of this RfC is not to re-litigate the previous RfC, but to find consensus for a barrier for inclusion that reflects the closure of the previous RfC. This summarises the relevant part of the closure of the last RfC, and states clearly that the purpose of this RfC is to fulfil the consensus that was already established by it. Sideswipe9th (talk) 20:05, 13 June 2023 (UTC)

  Your RFC! Feel free to change. I personally think mentioning the baseline, at the very least, might be helpful, but if you disagree that's totally okay.--Jerome Frank Disciple 20:07, 13 June 2023 (UTC)

  I don't really care enough to change it either way. I just prefer simplicity over verbosity on something like this. Sideswipe9th (talk) 20:15, 13 June 2023 (UTC)

  I've changed it. I agree the new phrasing is clearer. Loki (talk) 23:10, 13 June 2023 (UTC)

• SMcCandlish: Above, you say the proposal has "the gem of a good idea" but that it needs "considerable further wordsmithing before it's guideline-worthy". Would you mind elaborating on which parts you think are good versus which parts you think need more work? Loki (talk) 03:41, 14 June 2023 (UTC)

  @LokiTheLiar: As I indicated, I agree with Some1's reasoning why "established through in-depth analysis or discussion of the name in high quality sources" is problematic (Only_in_death_does_duty_end also gets into it). I'm not really certain yet of alternative better wording. (There's a reason why major change proposals for P&G pages are often workshopped for some time in advance of being proposed in RfC; P&G writing is challenging and often requires a lot of head-scratching to get right.) Edit: Trystan's "is established through discussion of the name in high quality sources" might work, though some may object that it still is creating a "special class". 'Introduce the former name with either "born" or "formerly"' is probably unnecessarily prescriptive, and even if we did prescribe so narrowly, it would be in the material above that, on how to write about TG/NB people at all (remember this proposed material is only about the deceased). The example material to me seems a bit tumid; while the explanations are probably needed, they could be done as {{efn}} footnotes. Or the two long ones could just be made more concise, e.g. by eliminating the redundant "Note:" introductions, and by compressing things like "While Alcorn's gender identity is discussed in significant detail in high quality sources about her, her former name is not." to something more like "Alcorn's former name is not covered in high-quality sources.". The really blathery "Hemingway's struggles with her gender dysphoria, and relationship with her gender identity, gender expression, and name are discussed in significant detail in sources about her life." can be reduced to "Hemingway's former name is covered in high-quality sources." Even leave out "in significant detail", which really doesn't make sense in this context (a name is a name not a novel; once you've given the full name what more "significant detail" could there be?)  — SMcCandlish ☏ ¢ 😼  04:15, 14 June 2023 (UTC); rev'd. 04:31, 14 June 2023 (UTC)

  I think a questions here are a) is the proposal closer to community consensus than the existing policies and b) does the proposal contain language (from the onset) that is problematic and should not be adopted (even if it does better reflect community consensus)? I do agree that writing policy is hard - my question is do these concerns rise to a level that requires more perfection rather than the normal process of word smithing (that can be completed on the MOS talk page)? - Enos733 (talk) 04:32, 14 June 2023 (UTC)

  I might agree with you if I even slightly trusted the idea that various participants here would not editwar against textual and wiki-logical improvements, on the bogus basis that the wording was what was "approved" in this RfC (witness already the attempts to have the closer discount comments, on the basis that they don't agree with what was "approved" in the last RfC!). There has been a palpable WP:BATTLEGROUND mentality surrounding this entire subject at Wikipedia since at least the mid-2010s, and it has gotten worse not better. So, no, I expect the wordsmithing to happen before the guideline is substantively changed. And this is not a strange expectation, but pretty much SOP when it comes to major P&G changes.  — SMcCandlish ☏ ¢ 😼  05:33, 14 June 2023 (UTC) PS: I think EddieHugh's [2] concern that the previous, vague RfC was a "priming question" has proved correct.  — SMcCandlish ☏ ¢ 😼  17:28, 16 June 2023 (UTC)

  I'm not getting into this discussion too much, but I do think what you're saying here is probably a fair assessment of the situation. Any future change will likely lead to another RFC, where it will probably be argued that the new RFC shouldn't be happening at all because "the consensus was already established in this RFC". Now, whether those arguments will hold merit is another question. --Licks-rocks (talk) 09:38, 14 June 2023 (UTC)

  The priming question is interesting. So his idea was that I deliberately (update!) or accidentally asked a noncontroversial question first to make the controversial questions seem ... less controversial participants more amenable to the subsequent more controversial proposals? Sounds pretty devious! Since I am the person who set up the RFC, I do want to defend myself a bit here, both because that subjectively wasn't my intent and because I think your analysis has some objective flaws. (I also dispute Eddie claim that I didn't spend enough time considering the RFCBEFORE; in reality, I spent quite a bit of time there and examining other RFCs in order to craft the options. Finally, I'd note that, contrary to the implication, no "priming effects" concern was raised at the RFCBEFORE when topic 1 was brought up by Trystan.)

  We have a proposal that has a higher standard than option 2 but a lower standard than option 3 at the last RFC. You're suggesting that the last RFC was shaded by priming effects which aren't present in this RFC. Well, what's the basis for that? I assume what you mean to say is that, if there were no priming effects, you would expect this proposal to be more popular. In the last RFC, 53% of users said they'd support Option 3 either uniquely or among other options; 29% said the same about Option 2. Perhaps you're thinking, "well if we've split the difference, then half of the option 2 supporters and all of the option 3 supporters should support this proposal!"

  But I think that makes two big, unsupported assumptions about both the supporters of option 2 and this proposal. Consider, for example, that more option 2 supporters also supported option 4 than supported option 3. And I personally think this proposal leans more towards option 3 than splitting the difference between the two options, but, regardless of whether you agree, my point is that it's hard to measure.(Notably, Trystan, who supported option 2 alone in the last RFC, has said this standard is too high for him.) (Also: notably, about one-fourth of the users in this RFC weren't in the last RFC, so whether you can reliably compare these two body of users is itself questionable.)--Jerome Frank Disciple 18:00, 16 June 2023 (UTC)

  I really don't like writing "That's not what I said!", as in my experience it is a sign that people are talking past each other and that such a pattern will continue, but... "So his idea was that I deliberately asked a noncontroversial question first to make the controversial questions seem ... less controversial?" That is very much not what I wrote; it included "unintentional or not" (contrast with "deliberately") and examples of the possible effects of priming questions (contrast them with "seem ... less controversial"). EddieHugh (talk) 16:34, 17 June 2023 (UTC)

  Apologies for the deliberate comment! Will strike. I can also change that the questions would seem less controversial to "make them more amenable to the other more controversial suggestions", though I'm not sure there's a huge distinction there.

  I'd stand by that there's no evidence of priming effects, and I was always a bit dubious as to the possibility: It actually seemed a little funny for someone who opposed the proposal to be simultaneously calling it on that "looks unlikely to be disagreed with". I'd also still strongly disagree with your comment that This procedural problem could have been avoided if the lengthy discussions at Wikipedia talk:Manual of Style/Biography#Remove the "living" qualifier in MOS:DEADNAME had not been ignored—for one, because I did not ignore that RFCBEFORE (which I also participated in), and, for two, because the idea that there was wide concern about priming effects in the RFCBEFORE is just not at all borne out by the comments there (see section on "small proposal" by Trystan).--Jerome Frank Disciple 16:51, 17 June 2023 (UTC)

Procedural issue: excluding dissenting views

The suggestion of excluding views that don't fit within the bounds of the previous RFC's close keeps getting suggested. That would be the wrong approach for a closer to take.

As an overarching principle, our guidelines reflect consensus. Practically, they require actual the consensus of the community behind them to function. This is a centrally located, well-advertised RFC, and if the proposed change reflects community consensus, that will be shown in the result, without the need to artificially exclude any dissenting views from consideration.

The suggestion that editors are free to challenge the previous close has been made. In my view, that would be unproductive. The close of question 2 found no consensus for change, suggested that a consensus could be found between options 2 and 3, and contemplated a further discussion or RFC would be "likely to result in consensus language". All of which is quite reasonable. I'm somewhat skeptical on how likely a compromise option will be to actually attract enough support to establish a consensus, but the current RFC will answer that exact question, provided it is run in a fair and open manner.--Trystan (talk) 23:58, 13 June 2023 (UTC)

Those who didn't get the outcome they desired are more motivated to try to continue pushing over and over to overturn a result through decreased participation of the community versus the group trying to reverse a decision. Hence those trying to overturn will show up more readily in a secondary discussion than the much larger group of people that were involved in the original community decision because the latter community group will more generally feel like a decision was made and implemented. I contend that re-litigation of RfCs, particularly in discussions that aren't on the original questions, with much smaller turnout is an attempt to use local consensus to reverse an actual community decision. If re-litigation of an RfC is desired, then those desiring that should re-start their own RfC on the original topic and specific questions, not try to bog down other RfCs that are about implementation of the community decision. Silverseren^C 00:09, 14 June 2023 (UTC)

I do think this is a tricky issue: on the one hand, we wouldn't be having this RFC if it weren't for the prior one indicating that a consensus existed between two options. The prior close indicated that option 2 was the baseline, and it does seem like a waste of time too, effectively do the prior RFC over—it only closed a week ago! Per WP:CCC, "Editors may propose a change to current consensus, especially to raise previously unconsidered arguments or circumstances. On the other hand, proposing to change a recently established consensus can be disruptive."

On the other hand, I think it will be difficult to accurately distinguish between comments that say "this particular bar is too high" or "too ambiguous" or whatever ... and comments that are asking for a lower bar than option 2 / trying to re-litigate the first RFC. And, at some point, we're just encouraging gamesmanship by trying to enforce that line—it's pretty easy to craft a "this bar is too high" !vote even if your real goal is "let's make sure the consensus from the prior RFC is never realized". Hopefully, of course, the eventual closer won't have to consider any of this, but I don't envy whoever tries to take it on.--Jerome Frank Disciple 00:18, 14 June 2023 (UTC)

Those who didn't get the outcome they desired are more motivated to try to continue pushing over and over to overturn a result through decreased participation of the community versus the group trying to reverse a decision. I note that the warring over these issues has been going on for long enough that participation bias may already have applied to the original RFC that this RFC is following up on. And even several RFCs before it. Anomie⚔ 11:55, 14 June 2023 (UTC)

At the time of writing this reply, there are two !votes above that I would consider to be re-litigating part of the just closed RfC. Specifically the text there is a consensus against using the former names of transgender or non-binary people, living or dead, except when of encyclopedic interest or when necessary to avoid confusion. Also, there is clear consensus that a former name is not automatically of encyclopedic interest. (emphasis original) Had there been more time between this RfC and the close of the previous one, say six months to a year, I think an argument could be made that potentially consensus on this had changed. However for this particular topic, I don't think that it's plausible that consensus has changed so radically that those points I've quoted no longer apply.

With regards to relevant guidance for closures, a closer discounting certain contributions based on a number of criteria is covered in both the information page on closing discussions, and the advice essay on closing discussions. Asking that a closer discount those !votes is within the spirit and letter of that guidance. Of course ultimately it is up to the closer whether or not they do this, and whether or not they fully discount or otherwise reduce the weight of those contributions.

I have to agree with what Silver Seren has said just above. If re-litigation of the previous RfC is desired, then those desiring it should start their own RfC on this. And I'd also like to repeat what I've said above to another editor, if editors feel as though the close of the previous RfC is not an accurate reading of the consensus, whether in part or in whole, then their only reasonable recourse would be to request a closure review at the appropriate venue. Stating that you feel that part of the close should not apply is re-litigating the consensus from that RfC by another name, and I believe is out of scope of this RfC. Sideswipe9th (talk) 00:50, 14 June 2023 (UTC)

Agreed with Sideswipe. In any other situation, trying to start an RFC to undo a consensus that was reached literally under a week ago would be so disruptive you'd plausibly be brought to ANI for it.

The only possible reason to do so would be gaming the system by hoping that a less representative chunk of the community shows up to this RFC than the previous one. Loki (talk) 02:44, 14 June 2023 (UTC)

Concur with Trystan at the top of this subsection. If the proponents' ideas are solid and have consensus, there would be no need to try to exclude opposing viewpoints. They are also forgetting that WP:CONSENSUSCANCHANGE, sometimes quickly. We have that policy for a reason, and closers are not magically empowered to pretend it does not exist. (That said, I don't think the consensus in the former RfC is wrong or will change; I object to trying to whitewash away other editors' entire comments by ignoring most of what they say, focusing on their alleged disagreement with the old RfC, and trying to suppress their entire message. It's a classic logic fallcy, the fallacy of division, in which if one element of an argument is wrong everything the argument presents must also be wrong.)  — SMcCandlish ☏ ¢ 😼  03:03, 14 June 2023 (UTC)

Of the two !votes that I consider to be re-litigating part of the last RfC, only one has made a partial contribution that is not re-litigating the prior RfC, and which largely amounts to a "per X" !vote. The other makes absolutely no substantive arguments that are not re-litigation of topics that were already discussed during the previous RfC. Sideswipe9th (talk) 03:14, 14 June 2023 (UTC)

And you have no right to suppress the "per X", even if closers do not always give such !votes as much weight. I consider my point made. Doubling-down on censorious antics is not a good look.  — SMcCandlish ☏ ¢ 😼  04:15, 14 June 2023 (UTC)

I think perhaps you have misunderstood what has been said. No one here has called for a "per X" contribution to be discounted, either in whole or in part. Only those arguments, or parts of arguments which amount to re-litigation. If a comment contains arguments other than rehashes of what was discussed in the previous RfC, then naturally those would not be discarded. Sideswipe9th (talk) 04:23, 14 June 2023 (UTC)

Whatever you say.  — SMcCandlish ☏ ¢ 😼  04:31, 14 June 2023 (UTC)

Some of the above points are getting dangerously close to saying that some people should not participate in an RfC. In abstract terms: if the spectrum of possible wording on a guidline or policy is from 1 to 9 and a proposal is made to change it from its current 5 to 2, then someone who prefers 1 is entitled to support while arguing that 1 would be better, even if 1 or anything else was rejected previously. Similarly, someone who prefers 9 is entitled to oppose while arguing that 9 would be better, even if 5 or anything else was rejected previously. Someone who doesn't like spicy food but who is given the choice between adding more spice to the spicy food pot or leaving it as it is has a valid argument when saying "It's too spicy already, so I oppose adding more spice". EddieHugh (talk) 18:44, 14 June 2023 (UTC)

Those numbers have thrown me a bit. I think the arguments aren't directed at who should participate in the RFC but what the RFC should discuss. A prior RFC considered Option 1, Option 2, Option 3, Option 4. The closer said the consensus was between Option 2 and Option 3. Now, imagine the closer had said we should have a runoff: asking the community to pick between 2 and 3. Obviously, it wouldn't be productive to consider voters saying "1!!" and "4!!". Instead, though, the closer said we should try to find a compromise between options 2 and 3. And I think the editors who are saying some points should be discarded are saying that, just as in the runoff, the "1!!" and "4!!" comments (or their equivalents) aren't relevant.

That said, as I said, I do think it'd be very tricky—except in the most egregious situations—to distinguish between comments that, in effect, say, "I think this proposal trends too close to option 3 and it should trend closer to option 2" and the comments that, in effect, say, "I support option 1 or option 4" (since obviously people don't—and shouldn't) phrase their !votes in that format.--Jerome Frank Disciple 18:51, 14 June 2023 (UTC)

I agree with Jerome on this one, It's not about who participates, it's about how. I think there's a solid argument that the consensus on this is already established, and that we need to be working within those bounds. Any argument that doesn't contribute that would be wasted space, in this view. I'm personally inclined to agree. --Licks-rocks (talk) 20:13, 14 June 2023 (UTC)

I'm not sure if it's likely to be a major issue here, but I agree that excluding viewpoints in this way would be a problematic thing for the closer to do. To say that project-wide consensus has been established seems to me to be saying that we should be following a waterfall-type decisionmaking process, where we lock in the answer to question A before proceeding to question B. I understand why that would seem like a good idea, but I don't think that kind of structured decisionmaking is really compatible with making good global decisions on a vast open wiki (and one in which any given RFC's sample of opinion is unlikely to be representative). Moreover, leaving out step-1 dissenters in the evaluation of step-2 consensus creates a lot of opportunities for "majority of the majority" (or "consensus of the consenters") process-gaming that tends to lead to poor decisions. Although consensus is of course not purely numeric, purely for purposes of illustration: if we model the consensus threshold as 2/3 then this approach would lead to a step-2 "consensus" supported by less than half (4/9) of all participants. As pointed out above this approach would lead to unworkable outcomes, because any decision can only be implemented if there is an actual consensus of the community in support. Again, I don't see this as an overwhelming concern here. But IMO the closer we keep our understanding of "consensus" to the ordinary meaning of the word, the better our decisions are going to be. And that means excluding as few viewpoints as possible from the determination of whether a consensus exists. -- Visviva (talk) 22:41, 14 June 2023 (UTC)

Any such closure would be invalid under present policy, end of story. AndyTheGrump (talk) 22:44, 14 June 2023 (UTC)

Once again, to echo Jerome and Licks-rocks, "It's not about who participates, it's about how": 9/9 of prior RfC participants can participate here, no matter whether they were in the majority or minority before; but only comments/!votes within the parameters of the prior RfC's closure should be accepted – because this RfC is for discussion of what the prior RfC left open, between options 2 and 3. As that RfC's closer put it, "Where, exactly, the lines of encyclopedic interest and avoiding confusion are is not simple or clear and will likely need discussion...." This does not invite revisiting options already declined there. – .Raven  .talk 23:18, 14 June 2023 (UTC)

Just to reiterate, I don't think that's a viable way of doing policy on an open wiki. If you don't like the vote-counting illustration, let's take WP:DETCON at its word: let's call A the best (and therefore "consensus") argument made in RFC1, and A' the best argument made in RFC2. Hypothetically, if A′ were actually a better argument than A (A′ >> A), then (a) we would be doing the project a great disservice by rejecting A′ merely because it was not raised in RFC1, and (b) we would also be violating the letter of DETCON, according to which the superior argument is automatically the consensus argument. A path-dependent model of consensus is going to yield a suboptimal outcome here, regardless of the closer's preferred understanding of consensus. (Off-topic but obligatory note that DETCON is arrant nonsense that nobody actually believes, and if it did accurately describe policy it would immediately cease to be policy, because nobody could ever seriously entertain the idea that arguments have an objective level of "quality" independent of the observer's own preferences.) -- Visviva (talk) 23:40, 14 June 2023 (UTC)

1) "by rejecting A′ merely because it was not raised in RFC1" – Except in this case A′ was already raised in RFC1, and expressly rejected... just a week ago.

2) "let's take WP:DETCON at its word.... DETCON is arrant nonsense that nobody actually believes" – You just rejected the premise of your own comment's preceding text. Why bother posting it?

3) Except that "objective level of 'quality'" argues against a seemingly vague contextless word... which in the original text has a specific context: "quality... as viewed through the lens of Wikipedia policy" — in other words, whether arguments are in accord with policy, or not. This is neither "arrant nonsense that nobody actually believes" nor ultimately indeterminable. – .Raven  .talk 02:17, 15 June 2023 (UTC)

Also to reiterate, .Raven is ignoring the unignorable fact that WP:CONSENSUSCANCHANGE is hard policy. It really doesn't matter what consensus came to in an old RfC; if current consensus doesn't exactly comport with it, then current consensus overrides. That is how all decision-making on WP works, since the project began.  — SMcCandlish ☏ ¢ 😼  01:03, 15 June 2023 (UTC)

Let's see the first paragraph of WP:CONSENSUSCANCHANGE: "Editors may propose a change to current consensus, especially to raise previously unconsidered arguments or circumstances. On the other hand, proposing to change a recently established consensus can be disruptive." [emphasis added] – In this case the argument was "previously considered", and consensus established a week ago, not very "old". – .Raven  .talk 02:22, 15 June 2023 (UTC)

That doesn't mean that previously considered arguments become invalid arguments - it just means you shouldn't open a new RfC based on those arguments. If an RfC is opened then editors are free to make them again and if they are policy-compliant then they should be taken into account by the closer; to do otherwise could result in a close that doesn't reflect the consensus of the broader community - Visviva gives a good example of how this could happen. BilledMammal (talk) 05:30, 15 June 2023 (UTC)

Except in this case this RfC was opened specifically to follow up (not overturn) the prior RfC by working out the details of the... compromise?... midpoint?... resolution?... of the two options, #2 and #3, singled out by that prior RfC's consensus. To say that prior consensus got it wrong is not on the agenda. – .Raven  .talk 06:51, 15 June 2023 (UTC)

And to determine that midpoint you need a consensus from the broader community, not just the subset that supported some indeterminate point between #2 and #3.

What you need is a proposal that can win the support of enough editors who supported that indeterminate point to overcome the general objections. If your proposal can't do that then it isn't the midpoint. BilledMammal (talk) 11:56, 15 June 2023 (UTC)

Yes. This is a keenly analytical way of getting at what I was trying to point out more vaguely.  — SMcCandlish ☏ ¢ 😼  16:54, 16 June 2023 (UTC)

Lol @ CONSENSUSCANCHANGE. If someone opened a new RFC to relitigate a heavily-attended RFC that closed less than a week earlier [that one closed on the 7th, this one started on the 12th], citing CONSENSUSCANCHANGE, they would (as someone noted above) probably get taken to ANI for disruptive editing, if not (more likely IMO) simply shot down on the spot. -sche (talk) 03:34, 15 June 2023 (UTC)

Non sequitur and red herring; no one "opened a new RfC to relitigate"; this is about suppression of an editor's entire input into an implementation RfC based on a perception that one point they raise may be relitigation. Not the same thing. There's also a strong element of fait accompli running through this discussion. If people think that an RfC with limited input cannot be overturned by a later RfC with broader input they are sadly mistaken. (I can even remember another MoS case in which exactly that happened, after only about a week.) I don't think that should happen in this case, mind you, I'm just pointing out that all of this "the previous RfC already set this in stone" argumentation is bogus, as is the illiberal censoriousness being brought to bear against editors who raise concerns (it's cancel-culture nonsense).  — SMcCandlish ☏ ¢ 😼  17:12, 16 June 2023 (UTC)

if we're going to be pointing out fallacies, your first argument here is a strawman. Nobody said the entire comment should be thrown out either. Just the parts that ignore prior consensus. Aditionally, I wouldn't say the last rfc had "limited input". --Licks-rocks (talk) 17:14, 16 June 2023 (UTC)

See !vote by Cuñado and responses to it. The tag-team attempt to suppress that editor's entire input on the basis that part of it was allegedly relitigating is the entire reason I brought this up in the first place. People can try to backpedal all they want, but they said what they said. As for input levels, this follow-on RfC is attracting input from editors who did not participate in the last one and it's likely to exceed it in input level (I would bet both in quantity and quality) before it closes.  — SMcCandlish ☏ ¢ 😼  17:35, 16 June 2023 (UTC)

I'm with SMc on this. I was going to respond to the suppression against that editor, but decided against it. I did see it though... Huggums537 (talk) 05:50, 25 June 2023 (UTC)

Discussion (alternatives)

Replies moved here from from above to keep the discussion on topic; initially made in reply to this comment BilledMammal (talk) 17:21, 16 June 2023 (UTC)

I don’t think “in-depth discussion of the name should be the bar… but rather in-depth discussion of the subject by sources using the name. Blueboar (talk) 16:42, 16 June 2023 (UTC)

I think established through discussion of the name in high quality sources has much of the same issues as the current proposal; Hemingway's former name is included in almost all high quality sources covering her, but the name itself isn't discussed. I would mostly agree with Blueboar, although I would prefer "including" rather than "using" the name.

Perhaps something like "widely included by reliable and secondary sources that contain significant coverage of the subject"? I think it would also be useful to include a line like "Multiple publications from the same author or organization are usually regarded as a single source for the purposes of determing whether a name has been commonly included", to avoid us including names just because one prolific author always includes it while half a dozen less prolific ones do not.

However, I think further discussion of alternatives should be done elsewhere, to keep this discussion on topic. BilledMammal (talk) 17:00, 16 June 2023 (UTC)

I think "multiple" is too low a standard. The standard that you and Blueboar are describing sounds very similar to the option 2 in the last RFC: "if such inclusion would satisfy the principle of least astonishment, particularly considering the majority of reliable sources discussing said person."

Given that we are trying to split the needle between option 2 and 3, I do think we need to aim a bit higher than that. Can I ask what your thoughts are on my proposal here (just the text within the {{ctop}})?--Jerome Frank Disciple 17:06, 16 June 2023 (UTC)

I think you misread my proposal; I'm not suggesting "multiple", I'm suggesting "widely" which I consider to be a higher standard than that.

Regarding that proposal, my overall position is that if a proposal would prevent us from including a name even if every reliable source on the subject included it, then the bar the proposal sets is far too high. Your proposal would prevent us from including those names under circumstances where the subject's gender ID is neither contested nor conflicted, and other circumstances exist where it is relevant. BilledMammal (talk) 17:28, 16 June 2023 (UTC)

Ah, so for you it's about a percentage. Is "widely" higher than "majority"? (from the last option 2.) Idk I think if 40% of sources said X, then it'd be fair to describe that as "widely said", so I have trouble seeing how your proposal would be a higher bar than the last option 2.--Jerome Frank Disciple 17:41, 16 June 2023 (UTC)

It would be flexible to allow us to adjust to the circumstances. For example, if someone is covered by just three suitable sources and two mention the former name then we should probably exclude it, even though it is mentioned in a majority of sources. Alternatively, if someone is covered by one hundred suitable sources and forty-five include it then we should probably include it, even though it isn't mentioned in a majority of sources. The flexibility also saves us from having to gather a complete collection of sources and carefully counting which include and which exclude it, an exercise that would be extremely impractical for more notable individuals. BilledMammal (talk) 17:51, 16 June 2023 (UTC)

Okay, so it's not really a higher bar ... it's just a different bar. But I still don't know if that is actually splitting the difference between option 2 and option 3, which said the name should never be used. (I'm also not sure, in practice, how often a "well this person is only covered by 3 sources, 2 of which use their deadname" scenario would come up). To be clear: I'm not saying I'd certainly oppose your proposal—in practice I think it would operate, essentially, exactly the same as option 2 from the last RFC, which I supported (along with option 3)--Jerome Frank Disciple 18:04, 16 June 2023 (UTC)

It probably would operate similarly; the differences I see are that it addresses the concerns about not considering quality of sources, and it addresses the concerns about the complexity of determining a majority. BilledMammal (talk) 18:08, 16 June 2023 (UTC)

So I've got two issues with "widely included..." Even with the "significant coverage" qualifier, that's an argument for inclusion based on volume alone. That's contraindicated by the just closed RfC which states Many responses supporting different options specifically called out the difficulty of dealing with a "majority" of sources, e.g. is 50%+1 sufficient? How does a majority take into account emphasis and source quality? Some of those supporting option 2 suggested a higher bar than majority as well. To fulfil the existing consensus, any proposed barrier has to be higher than something based on mere volume of sources.

Secondly, significant coverage is part of WP:N, and N pretty explicitly states The criteria applied to the creation or retention of an article are not the same as those applied to the content inside it. The notability guideline does not apply to the contents of articles. During the drafting I considered whether linking in with N, or something that derives from N, would be appropriate, but because of NNC I quickly came to the obvious conclusion that we can't apply notability criteria to article content in that manner. That's ultimately why I settled on BALASP, which is applicable to content and about inclusion versus exclusion of minor aspects of a subject.

However, I think further discussion of alternatives should be done elsewhere We could move this comment chain, in part or in whole, to a subsection below the survey. Sideswipe9th (talk) 17:15, 16 June 2023 (UTC)

For your first point, how about "widely included by reliable, secondary, and high quality sources that contain significant coverage of the subject"?

For your second point, we already directly apply notability in this area with If a living transgender or non-binary person was not notable under a former name (a deadname), it should not be included in any page (including lists, redirects, disambiguation pages, category names, templates, etc.), even in quotations, even if reliable sourcing exists. Given that I don't believe there is any issue with applying criteria derived from WP:GNG if it would be appropriate. BilledMammal (talk) 17:32, 16 June 2023 (UTC)

This version of "widely included" is a bit better, but it still has the volume issue. How widely are we talking about? 50%+1? One of the common supermajority thresholds? It also doesn't help us with assessing encyclopaedic significance, which is part of the threshold per there is a consensus against using the former names of transgender or non-binary people, living or dead, except when of encyclopedic interest or when necessary to avoid confusion.

On the second point, this is actually an interesting thing about that criteria. It's not directly applying N to the content, it's using the point at which an article's subject meets N as an convenient and easily stated cut-off date for inclusion versus exclusion. In effect, what it means is that we would only include the former names of living trans or non-binary individuals if they change their name after the point at which we created an article about them. Hence why we include Elliot Page's former name, but not Laverne Cox. Sideswipe9th (talk) 17:50, 16 June 2023 (UTC)

Widely would be flexible, as I discuss in my reply to Jerome Frank Disciple. I don't think we want a clearly defined percentage, both because determining whether someone passes that percentage would be impractical, and because it could result in us including the name when we should exclude it and the reverse. I also think it helps with assessing encyclopaedic significance because it assesses whether reliable sources consider it relevant - a key metric of encyclopaedic significance.

In effect, what it means is that we would only include the former names of living trans or non-binary individuals if they change their name after the point at which we created an article about them. That isn't quite accurate; it is saying we only include the former names of living trans or non-binary individuals if they change their name after the point at which we could have created an article about them. Personally, I don't think that is the ideal metric - it requires us to include the former name of people who barely passed WP:NACTOR or another of the more inclusive SNG's prior to transitioning but then became significantly more notable later, and it requires us to exclude the former name of people who became notable after transitioning but who have their former name included in every reliable source on the subject - but that is a different discussion.

I'll add that the benefit of this proposal is that it would be almost certain to get a consensus; we can then see how it works in practice and adjust it later if we encounter issues. BilledMammal (talk) 17:57, 16 June 2023 (UTC)

I agree with Sideswipe that the close of the previous RFC indicates we should be using a more contextual approach rather than a volume of sources approach- what makes sense to me would be to have the guideline be that there must be a clear/specific reason to include the deadname of the person in question if they were not notable before adopting their new name, and that verifiability alone is not enough to warrant inclusion. I'm not sure how we would word that or whether other people would agree with that assessment, but I do think that that seems to be essentially what was agreed upon in the close of the last RFC and it does essentially allow for the decision to be made on a case by case basis. this would explicitly allow for the inclusion of the deadname of the nashville shooter, which a lot of people seem concerned about even though it's an extremely rare case. I'd be curious to hear what other people think about this. Tekrmn (talk) 18:32, 16 June 2023 (UTC)

That's a decent point. I think, alone, there must be a reason to include the deadname beyond the mere fact that the person was once known by that name would be a bit too low a bar and not provide quite enough guidance. I tried to use WP:PLA in the last RFC to provide some guidance in option 2 (with one factor to be considered being the majority of reliable sources), but obviously that got, at best, a mixed response. (I also don't know that PLA would cover examples like Gloria Hemingway, who's been mentioned a few times here.)--Jerome Frank Disciple 18:38, 16 June 2023 (UTC)

I do personally agree that this would be too low of a bar but it seems like a fair number of editors feel that the current proposal is too high a bar (and while I was in favor of option 3 I also think that the language of this proposal would really only apply to very specific cases like Gloria Hemingway or arguably Marsha P Johnson) and I would like to come to a consensus on something. the more leeway there is in the guideline, of course, the easier it will be for people to misuse it, but I also do think that edge cases like Gloria Hemingway and the Nashville shooting are being taken into account, and while I don't think we should make decisions based on cases like that we may have to acknowledge that people are taking them into account. I definitely agree that what I wrote would need to at the very least be word-smithed and I do think it could be written in a way that implies more restriction, however I would be thrilled if the current proposal is something we can get a consensus for.

I definitely think PLA would be a useful metric, but I also think that without having a guidance on where we can use deadnames PLA has already led to overemphasis and alone might be even more open to interpretation than what I wrote in some ways. Tekrmn (talk) 19:35, 16 June 2023 (UTC)

It would be flexible, but that flexibility has the same endless discussion trap that our current lack of guidance has. In this case, because everyone defines widely differently, there will be a lot of discussion (and a corresponding lack of consistency) on just what widely means per article subject. The most viable solution is one that is not based on source volume, or if it is then we should set a minimum floor above which inclusion can be considered but not mandated, as that would allow for consensus to form around exclusion.

On notability being a convenient cut-off date, I would refer back to this discussion from November 2020, which eventually lead us to more or less the current phrasing of the guideline. The comment chain starting from SMcCandlish's comment at 06:00, 15 November 2020, is the most relevant part for this. The intention, at least for the last three years, has always been that if the person changed names prior to meeting WP:GNG or a relevant SNG, then we would not include the name. This is best summarised in SMcCandlish's comment If consensus is and remains that a name of TG/NB person that pre-dates that subject's notability (or an old name of a TG/NB person who is not notable at all) should not be used in mainspace, such an old name can simply be replaced with the current one. from 05:14, 17 November 2020.

it requires us to include the former name of people who barely passed WP:NACTOR or another of the more inclusive SNG's prior to transitioning but then became significantly more notable later I'm curious if you have an example in mind for this.

Honestly, I think Trystan's proposal of replacing is established through in-depth analysis or discussion of the name in high quality sources with is established through discussion of the name in high quality sources is a more workable option here. It lowers the barrier somewhat from "in-depth analysis" to just "discussion of the name", while still keeping it restricted to higher quality sources. It sidesteps the volume threshold problem entirely, and because of this meets the consensus from the last RfC quite well. Though we (BilledMammal and I) disagree on whether my original proposal as written would allow for Gloria Hemingway or the Public Universal Friend's name, I think Trystan's proposal would definitely support both. It would still leave Aiden Hale's former name for the application of IAR, but as I've said previously (to some support) trying to make this guideline apply to Hale would result in too low a threshold of inclusion for the vast majority of applicable articles. Sideswipe9th (talk) 18:42, 16 June 2023 (UTC)

It would be flexible, but that flexibility has the same endless discussion trap that our current lack of guidance has. It might, but I'm not convinced it will - most of our policies are flexible, and all of the best ones are. I don't see any harm in trying; it prevents us from always including the name, and if it proves problematic in practice we can return here with a new proposal seeking to adjust it with clear examples of where the issues are.

I'm curious if you have an example in mind for this. No, I don't edit in this area, but I would expect such examples to exist. The real issue is the SNG's being overly inclusive (although marginally meeting GNG prior to transition is another example of when we probably shouldn't include the name), but again a different discussion.

Though we (BilledMammal and I) disagree on whether my original proposal as written would allow for Gloria Hemingway or the Public Universal Friend's name, I think Trystan's proposal would definitely support both. Can you provide examples of sources that you believe would demonstrate that their former names meet the requirements of this proposal (or if you are unable to, Trystan's)? Our disagreement could simply be because I haven't seen the sources you have. BilledMammal (talk) 19:14, 16 June 2023 (UTC)

No, I don't edit in this area Ah ha! Ok, as an editor who does edit in this area, I'm telling you straight up that the flexibility in your proposal coming from a floating definition of widely will be a problem because of the issues alluded to in my last reply.

For Trystan's proposal, on Hemingway, I think Paul Hendrickson's Hemingway's boat, on pages 567, 586, and 590, would fit. There's text about the fluidity of how Hemingway presented, and used different names based on that. There was another source I had open last night that would have fit my proposal, but I'll be damned if I can find it now, sorry.

For the Public Universal Friend, sources are a little harder to find due to the various spellings of the Friend's names. But I think Herbert Wisbey's Pioneer prophetess: Jemima Wilkinson, the Publick Universal Friend. There's too much to pick out specific pages I'm afraid, but there's a lot in it about the Friend and why they discarded their former name and how that was reflected in later life. From memory Paul Moyer's The Public Universal Friend: Jemima Wilkinson and religious enthusiasm in revolutionary America also has a fair bit of detail on the name change.

I would however hesitate to use the Friend as one of our examples, if nothing else because it's very unclear as to whether they would be what we now consider to be non-binary or not. The same sort of issue crops up with other historical figures like James Barry, due to a mixture of available sources and societal attitudes to non-cishet identities at the time. Sideswipe9th (talk) 20:31, 16 June 2023 (UTC)

Ok, as an editor who does edit in this area, I'm telling you straight up that the flexibility in your proposal coming from a floating definition of widely will be a problem because of the issues alluded to in my last reply. People in every area (including occasionally myself) say flexibility is a problem in guidelines and policies dealing with their area. They're usually wrong; I think it is better to start with more flexibility (although any of these proposals, including mine, will reduce considerably the flexibility from the status quo) and tighten the specific aspects that are problematic, rather than starting with an extremely inflexible guideline that could be used to exclude names from articles that should include them.

I don't have immediate access to Hemingway's Boat; I'll try to get a look at it soon.

Quickly reading the first chapter of "The Public Universal Friend: Jemima Wilkinson and religious enthusiasm in revolutionary America" which deals with their transition from Jemima Wilkinson to the Public Universal Friend I see some discussion of the name "Public Universal Friend" (for example, "That the Public Universal Friend thought of his turn to prophecy in terms that were roughly compatible with Quaker precedents is evident in the fact that his moniker was a modification of the title, “Public Friend,” the Quakers gave to their itinerant preachers") but I'm not seeing any discussion of the name "Jemima Wilkinson".

Doing the same with "Pioneer prophetess: Jemima Wilkinson, the Publick Universal Friend", I also cannot find any discussion of the name "Jemima Wilkinson"; can you provide quotes of the discussion you see? BilledMammal (talk) 21:16, 16 June 2023 (UTC)

@BilledMammal: apologies, I only just noticed that you had replied here. Sorry for the delay.

I can't really give you quotations, because this isn't something that's easily quoted as a lot of it is spread throughout the book. Instead I can give you pages and chapters of interest. Plus even with the age of some of these texts, I don't want to run afoul of a copyvio.

So chapter 1 of Wisbey's book has a brief mention of the biblical connotations of the Friend's birth name, at the end of page 3 and start of page 4. Chapter 7 discusses how a trustee was necessary as the Friend refused to hold property in their former name (pages 121-123), and later gives an account for someone who tried to get the Friend to use their former name (page 133). It's Chapter 9 however that goes into the most depth, with discussion on why the Friend had to finally recognise their former name on their deathbed, as otherwise their will would not have been recognised. Despite having to recognise the name however, the Friend still refused to actually sign with it and instead opted for an X (pages 165-168). There is also discussion in chapter 10, for how post-death the Friend's former name became synonymous with fraud and delusion (pages 173-175, and throughout the rest of the chapter how the former name and seemingly not the chosen name became associated with a story of walking on water.

In Moyer's book, chapter 5 makes brief mention of how the Friend needed a trustee to conduct legal affairs due to not recognising their former name (page 135). Chapter 7 discusses some legal issues the Friend had, where a Sheriff attempted to serve legal papers upon the Friend, but because the papers used the Friend's former name they refused to accept them. It required negotiation for the writ to be amended to mention the Friend's chosen name before they accepted them (pages 168-169). There's similar legal difficulties mentioned later in the chapter on pages 182-184. Finally chapter 8/the epilogue also discusses the Friend's will, and circumstances that require the will to contain their former name, and refusal to sign it with anything other than an X (pages 193-194).

If that's not sufficient for you, Scott Larson's "Indescribable Being": Theological Performances of Genderlessness in the Society of the Publick Universal Friend, 1776–1819 goes into a fair amount of depth on the Friend's transition (or perhaps transformation might be more terminologically appropriate, pages 577-578). It also discusses the duality of the names were a reflection on the perspective of the beholder, with those sympathetic to the Friend seeing them as the Friend, whereas those who were opposed saw the Friend as Wilkinson (pages 579-581). Pages 593-595 further reinforce this distinction between the names, with an interesting note on page 595 where the diaries of a former follower of the Friend change from using genderless language and "The Friend", to using gendered language and the Friend's former name after her published denunciation. Page 595 also discusses the same legal issues encountered by the Friend with respect to their will.

There's an fascinating note from Larson on page 583, on the difficulties in using genderless language as preferred by the Friend and their followers, and how despite this because of the age in which the Friend lived, Larson had to preform many searches using their former name. That actually has some parallels to some of the discussion in the survey above, where some are remarking that the former name is necessary to allow for research on the person. While that is certainly true for historical figures like the Friend, for modern trans and non-binary individuals (ie those born after the early 20th century) this is less of an issue because often one of the earliest steps in transitioning is getting early life documentation, like birth certificates, school and court records, and medical records, to retrospectively recognise the changed name. All but three US states allow for retrospective changes to a trans or non-binary person's birth certificate to reflect their gender identity, and many European countries have equivalencies in place through gender recognition certificates. For a modern trans or non-binary person, I would strongly suspect that this belief that not including the former name will hinder future research is not representative of the time in which we actually find ourselves living. Sideswipe9th (talk) 22:59, 25 June 2023 (UTC)

Also just incase it's not clear as I don't think I explicitly stated it, I believe Larson's paper would fully meet the test in my proposal. As would the totality of content spread throughout Wisbey and Moyer, though reasonable minds may differ on that. With Wisbey and Moyer it's a little more difficult though because the relevant discussion is spread across multiple chapters.

That said, all three would also in my opinion easily meet the barrier set by Trystan's proposal. Sideswipe9th (talk) 23:03, 25 June 2023 (UTC)

Correct me if I am wrong, but I believe the following quotes are what you are referring to:

1. The eighth child, her fourth daughter, was born on November 29, 1752, and was given the biblical name Jemima, after one of the daughters of Job.
2. This arrangement was necessary because Jemima Wilkinson, from the beginning of her ministry, refused to own any real property in her own name. Her attitude was explained in a petition, stating that she, "being wholly devoted to her Religious Duties & deeming it inconsistent therewith & unbecoming her character to have any personal concern or agency in pecuniary or temporal concerns constituted Sarah Richards, one of her most Trustworthy Followers & Friends, Trustee of the lands."
3. A story that is perhaps apocryphal, but not at all improbable, relates her answer to a man named Day, who was trying to induce her to admit to the name Jemima Wilkinson instead of the Universal Friend.
4. This woman, who had recognized no other name than the Publick Universal Friend for more than four decades, was compelled by fear of a legal disadvantage to admit that she was the one "who in the year one thousand seven hundred and seventy six was called Jemima Wilkinson and ever since that time the Universal Friend a new name which the mouth of the Lord Hath named.
5. A codicil further identifying the Universal Friend as Jemima Wilkinson was added on July 7, 1818, and signed with an X. This was witnessed by Gold, John Briggs, and James Brown, Jr. The fact that this resolute woman refused to sign the name Jemima Wilkinson, yet, when forced by legal necessity to make a signature, signed an X as "her cross or mark" has misled some writers to con- clude that she could not read or write
6. In her native New England, however, the name of Jemima Wilkinson was synonymous with fraud and delusion.
7. As early as July 1791, the Friend, with Sarah Richards acting as his agent and trustee (the prophet refused to use his legal name in order to conduct business or to sully himself with such worldly matters), began to make payments to Robinson and Hathaway for land in the town.
8. William Savery mentioned the episode in his journal, writing that “Sheriff Norton informed us he had lately attempted to Serve a Writ on Jemima Wilkinson at the Suit of Judge Potter’s son Thomas.” The Friend initially refused to recognize the writ, which was addressed to Jemima Wilkinson. Only after some negotiation did the prophet agree to accept the warrant and post bail “under the name of ye Universal Friend commonly calld Jemima Wilkinson.”
9. Thomas Gold, one of the lawyers employed by Malin, asked, “Does she [Wilkinson] not sense that everything is at stake, the roof over her head” and advised, “the Friends name must be used, to wit, Jemima Wilkinson, as Complainant with you.”
10. It is also worth noting that the will’s opening paragraph and codicil each specify that the Universal Friend and Jemima Wilkinson were the same person. The document’s first sentence denotes it as “the Last will and Testament of the Person Called the Universal Friend . . . who in the year one thousand seven hundred and seventy six was called Jemima Wilkinson and ever since that time the Universal Friend.” In a similar vein, the codicil states, “Be it remembered that in order to remove all doubts of the due execution of the foregoing Last will & testament I being the person who before the year one thousand seven hundred & seventy seven was known & called by the name of Jemima Wilkinson but since that time as the Universal Friend.” Yet even after taking such pains, the Friend signed the will with an “X” so that he could avoid writing his original name.
11. The society of followers also used linguistic gender performances to separate themselves from the "wicked world"; they marked themselves as believers by refusing to use gendered pronouns or the name "Jemima Wilkinson" for the being known as the "Publick Universal Friend," "a newname which the mouth of the Lord hath named."
12. For those who believed the Friend divine, and for those who damned Jemima Wilkinson as a devil, radical religious experience provided a key site for reimagining and critiquing gender constructs in the years following the American Revolution.
13. Language choices could also mark points of entering and exiting the community, as the apostate and denouncer Abner Brownell refers to "The Friend" in diary entries written during the time of his membership in the Friend's community but then calls "her" "Jemima Wilkinson" in his later published denunciation, Enthusiastical Errors, Described and Decried.
14. Only after the community's lawyer insisted that the law would not recognize the community's legal rights to the land unless they made use of the name Jemima Wilkinson did the Friend grudgingly allow it to be used—by signing an X to a document bearing the name.
15. Conventions of historical scholarship also enforce given names, since though I can use "the Friend" in my text, I still must search for and cite archives bearing the name Jemima Wilkinson

These don't appear to meet the standard set forward either by this proposal or by Trystan's alternative (and I would note I see the proposals as functionally indistinguishable; Trystan's requires discussion, yours requires discussion or in-depth analysis.

For example, #2 discusses how they refused to own property under the name "Jemima Wilkinson"; while it uses the name as part of the discussion that is not the same as discussing the same. #3 discusses how an individual tried to compel them to use their former name; again, it uses the name but doesn't discuss it. This is the case for almost every section you referenced.

The two exceptions are #1 and #6 which could be argued to be discussion of the name, but I feel it would be a very weak argument; the first only says she was named after a biblical figure, while the second is a discussion about the perception of her in New England and how their preferred name for her became "synonymous with fraud and delusion" - it is not a discussion about the name itself.

I think the issues with this proposal are obvious, given your difficulties in finding discussion of the name even for this figure whose era and relationship with her former self makes the former name central to any discussion of them. BilledMammal (talk) 00:20, 26 June 2023 (UTC)

If you're seeing Trystan and my proposals as functionally indistinguishable, then I may not ever be able to convince you with any amount of evidence. And that's fine, reasonable minds can disagree on this.

However with the examples that you've picked out, 2 and 3, I believe you're failing to recognise that a discussion on the Friend refusing to own property because they would have to use their former name in order to purchase the deed, or that an individual attempting to compel the Friend to use their former name is de facto a discussion about the former name and its use.

I also think that by distilling this to mere quotations, and leaving out the context of the preceding and following sentences and paragraphs, you may be seeing less than what is actually present in the totality of the text.

given your difficulties in finding discussion of the name I would not say I had any difficulties finding discussion of the name. While we clearly disagree on whether or not this meets either of the thresholds set out, please do not speak for me, and state that I have encountered difficulties where I clearly believe otherwise. I would like to ask that you strike that. Sideswipe9th (talk) 00:37, 26 June 2023 (UTC)

If you're seeing Trystan and my proposals as functionally indistinguishable, then I may not ever be able to convince you with any amount of evidence. Your proposal says X or Y is required, Trystan's says X is required. In theory, yours is less restrictive than Trystan's, but as Y is effectively a subset of X they are equivalent. Why do you see Trystan's as less restrictive?

Can you explain why you see a discussion of their refusal to identify with their former self as a discussion of their former name? The two are not obviously equivalent. Similarly, if you feel I am missing context by providing quotations could you expand on what that context is and how it changes these quotations from using the name in the context of discussions of other matters into discussions of the name itself? BilledMammal (talk) 00:44, 26 June 2023 (UTC)

Can you explain why you see a discussion of their refusal to identify with their former self as a discussion of their former name? I was somewhat in the process of writing something akin to this before your reply, as I realised I should have added it in my second paragraph.

To answer this, lets look at your distillation of Larson's paper into quotations 13 and 14. Quotation 13 is on page 594, and quotation 14 on page 595. By presenting it in this manner, you have skipped over a significant amount of content on pages 594, 595 and the start of 597. Note, page 596 is an photo excerpt from one of the paper's primary sources.

On page 594 you have skipped over an entire paragraph on how the use of a specific name to refer to the Friend indicated whether one was part of the community of the saved or part of the "wicked world". That content contextualises what you've quoted in 13, and also includes a demonstrative example from the memoirs of a child whose parents were followers of the Friend.

Next on page 595, you seem to have skipped over context both before and after the quotation. There are two lengthy sentences prior to the quotation that contextualise it within the legal issues that the Friend both during the time where the Friend required a trustee for land ownership, and later when notarising their will. After the quotation, you have skipped over the remainder of the paragraph on how the Friend's use of their former name in the will, while intended as legal manoeuvring, was later used to contest it as fraudulent over ten years after their death.

You've also skipped over a lengthy paragraph that takes up the remainder of page 595 and spills over to the start of 597, which has discussion on how the deliberate use of the Friend's former name was an attempt at denying who they were within their religious ministry. Religiosity aside, this has obvious parallels to what many trans and non-binary people face today, as despite the passage of some 220+ years, many still use the former name of a trans or non-binary person to deny them agency over their own personhood.

Now I could do the same for all of your quotations. However if I did so, we would be here all evening, and this already lengthy discussion would be even longer. Regardless I have to ask, when you are reading the pages I have listed above and selecting quotations from them, why have you skipped over the surrounding context and not made any reference to it or summary of it?

In theory, yours is less restrictive than Trystan's, but as Y is effectively a subset of X they are equivalent. Respectfully, I think you've misunderstood both mine and Trystan's proposal. For the sake of convenience my proposal is through in-depth analysis or discussion of the name in high quality sources, and Trystan's proposal is is established through discussion of the name in high quality sources. Breaking this down, both proposals restrict the inclusion criteria to content present in high quality sources. My proposal then puts a further restriction on it by requiring either in-depth analysis or in-depth discussion of the name to be present in those sources. The in-depth qualifier applies to both discussion or analysis of the name. That's a very high bar, and I acknowledged it as such in my !vote above. Trystan's proposal however removes the in-depth qualifier and requires only discussion of the name in high quality sources. This is a lower barrier to inclusion than my proposal, because it just requires the presence of a discussion, regardless of the depth of that discussion, to be present in the relevant sources. It is still however still a higher barrier than mere verifiability. Trystan acknowledged that this is a lower barrier when proposing it, as he opposed my proposal as too high of a barrier. Sideswipe9th (talk) 01:30, 26 June 2023 (UTC)

On page 594 you have skipped over an entire paragraph on how the use of a specific name to refer to the Friend "indicated whether one was part of the community of the saved or part of the "wicked world"". That content contextualises what you've quoted in 13, and also includes a demonstrative example from the memoirs of a child whose parents were followers of the Friend.

Focusing on just one example to simplify the discussion, can you explain how this context involves discussion of the name? My reading is that it is a discussion of how language divided the "saved" from the "wicked", and as part of that discussed how the "saved" used their preferred name and the "wicked" used their former name, but that isn't discussion of name itself - no more than an article mentioning how a trans persons sibling continued to use their birth name would be discussion of the name.

Regardless I have to ask, when you are reading the pages I have listed above and selecting quotations from them, why have you skipped over the surrounding context and not made any reference to it or summary of it? Because I didn't consider the context to change whether the sections I believed you were referring to involved discussion of the name? If you did, it would have been better for you to provide the quotations and summaries rather than relying on me to do so.

The in-depth qualifier applies to both discussion or analysis of the name. I interpreted it as applying only to the analysis, but I see now how you interpreted it to apply to both. BilledMammal (talk) 01:48, 26 June 2023 (UTC)

can you explain how this context involves discussion of the name? Put succinctly, the context is discussing how different groups of people used the name. It is there to establish understanding, so that when Larson notes the accounting of Huldah Davis, the reader can contextualise which group Davis and her parents belonged to (ie, followers of the Friend). Discussion on the use of a name is discussion of an aspect of the name.

If you did, it would have been better for you to provide the quotations and summaries I've already said why I did not wish to quote from the source materials in a manner such as you did, as to provide the full context it would amount to a copyvio from the more recently published sources. I thought I had adequately summarised however, especially as I gave the page numbers where the entirety of the content appeared.

Because I didn't consider the context to change whether the sections I believed you were referring to involved discussion of the name? The context is part of the discussion. It's present to help readers understand the fullness of the text. To go back to accounting of Huldah Davis mentioned above and on page 594, if I had just quoted In her recollections, Davis refers to Jemima Wilkinson but is careful to note that her parents, followers of the Friend, always referred to "the Friend," and Davis uses the community's language through most of her account. would you have understood that Davis' use of the community's language implied a sense of belonging that significantly outlasted the existence of that community, but despite the sense of belonging her use of the Friend's former name indicated that Davis was not a follower of the Friend's ministry? Sideswipe9th (talk) 02:06, 26 June 2023 (UTC)

Discussion on the use of a name is discussion of an aspect of the name. In practice, I don't believe that discussion of the use of the name will be interpreted as discussion of the name, and I think that if you intended to propose that such discussion would be sufficient for inclusion your proposal should read established through in-depth analysis or discussion of the use of the name in high quality sources/established through discussion of the use of the name in high quality sources

I also think that such an interpretation would make the proposal far more inclusive than you intended it to be. For example, an article mentioning how a trans persons sibling continued to use their birth name is discussion of the use of a name, as is an article mentioning that prior to transitioning the subject was called their birth name.

BilledMammal (talk) 02:24, 26 June 2023 (UTC)

I think that if you intended to propose that such discussion would be sufficient for inclusion your proposal should read ... If I wanted to limit my proposal to high quality sources that contain in-depth discussion on the use of the former name, then I would have done so. However that would arguably be an even higher standard than what I proposed, because that sort of discussion is exceedingly rare. My proposal is broader than that, as it allows for other types of in-depth discussion or analysis of the former name.

For example, an article mentioning how a trans persons sibling continued to use their birth name is discussion of the use of a name I feel like this is somewhat of a strawman. While it is a sad fact that many trans and non-binary people have transphobic family members who refuse to use that person's chosen name and pronouns, if a high quality source was to include this it would be something in the form of something like X's sibling(s) were not supportive of their transition, and in the case of a modern high quality source (something written in the last ten or so years) would very likely exclude the former name when doing so. Such a mention would certainly not be in-depth enough to meet my proposal, nor would it even meet the lower threshold from Trystan's proposal.

as is an article mentioning that prior to transitioning the subject was called their birth name Hard disagree. In either Trystan's or my threshold there has to be at minimum a discussion or analysis of the name. Simply mentioning it once, or even using it throughout as the primary name when referring to the subject would not be a discussion or analysis of the name. Sideswipe9th (talk) 02:53, 26 June 2023 (UTC)

If I wanted to limit my proposal to high quality sources that contain in-depth discussion on the use of the former name, then I would have done so. Then it should have read established through in-depth analysis or discussion of the name or use of the name in high quality sources/established through discussion of the name or use of the name in high quality sources. It doesn't change my point, which is that you are expecting people to interpret "discussion of the name" far more broadly than the wording would suggest it be interpreted.

Simply mentioning it once, or even using it throughout as the primary name when referring to the subject would not be a discussion or analysis of the name. I agree, but that wasn't my hypothetical and your interpretation of discussion of the name includes discussion of the use of the name. BilledMammal (talk) 03:23, 26 June 2023 (UTC)

It doesn't change my point, which is that you are expecting people to interpret "discussion of the name" far more broadly than the wording would suggest it be interpreted. I could just as easily turn that back, and say that you're interpreting it in a much narrower manner than many of the RfC's participants. I would also posit that your wording is unclear, because in-depth use of the name is somewhat of a nonsensical phrase. But it seems to stem from that you perhaps consider that a discussion or analysis on the use of the name is a distinct topic from discussion or analysis of the name? Whereas I see it as a subtype of a discussion or analysis of the name?

I agree, but that wasn't my hypothetical Unless I missed a step (it is late and I really should go to sleep), it certainly wasn't my hypothetical either. The first time I see it appearing in this discussion is your comment at 01:48, 26 June 2023. If it's not your hypothetical, and if it's not mine, then whose hypothetical is this? Sideswipe9th (talk) 03:36, 26 June 2023 (UTC)

I could just as easily turn that back, and say that you're interpreting it in a much narrower manner than many of the RfC's participants. Of the editors who have provided information on how they interpret it, most have interpreted it in a narrower fashion than you have - and even if all those editors are interpreting it "incorrectly" the fact that so many have done so demonstrates that the wording is flawed.

I would also posit that your wording is unclear, because "in-depth use of the name" is somewhat of a nonsensical phrase. It would be intended to be read as in-depth discussion of use of the name/discussion of use of the name, but I don't think the specifics of how it would need to be worded are relevant - the point is that the current wording is flawed.

Regarding the hypothetical, my hypothetical was a discussion of the use of the former name. However, I don't think it will be productive to discuss that further; your interpretation of the proposal differs significantly from my interpretation or the interpretation of many other editors, and that is where many - though not all - of the issues with the proposal originate from. BilledMammal (talk) 04:44, 26 June 2023 (UTC)

If that's all that takes for the "name" to be "discussed in depth", then there could very easily be situations in which the former name isn't even stated and yet would have sufficient coverage. Those passages are talking about the existence of a former name, not about the specific name itself. JoelleJay (talk) 00:47, 26 June 2023 (UTC)

Can I ask, with respect to "all it takes", did you read the pages from the sources I listed, or was it BilledMammal's quotations? If it's the later, then I would refer you to my reply above with respect to significant amount of context that is missing from the quotations. If it's the former, then I would respectfully disagree. Those paragraphs are discussing the former name, the legal and social challenges that arose from the Friend's discarding of the former name, and how during the Friend's lifetime and for a period after the use of one name or the other denoted whether someone was a follower of the Friend's ministry, or someone who was seemingly opposed to it. Sideswipe9th (talk) 01:40, 26 June 2023 (UTC)

Comment/alt - Should the proposal specify this policy applies to the lede sentence? That's how I initially read it when I voted support because of the focus on born as, which usually happens in the lede. That's more an alt topic name than "content". Per WP:NNC, other content in the article body should probably just be decided case by case based on whether the information is WP:DUE. The void century 12:37, 24 June 2023 (UTC)

So, this particular interoperation of NNC—as not just saying that WP:NOTABLE, by itself, does not apply to content ... but as saying that any policy or guideline that does employ the notability criteria in relation to a content issue is invalid ... is a pretty extreme one. I've only seen it suggested by one other editor. As it stands, MOS:GENDERID calls for different treatment between living trans persons who were notable under their prior name and who were not notable under that name: and it's very clear that it applies beyond the lead. "If a living transgender or non-binary person was not notable under a former name (a deadname), it should not be included in any page (including lists, redirects, disambiguation pages, category names, templates, etc.), even in quotations, even if reliable sourcing exists. Treat the pre-notability name as a privacy interest separate from (and often greater than) the person's current name." As I understand the proposal, and based on the last RFC, no this proposal would not just apply to the lead.--Jerome Frank Disciple 12:49, 24 June 2023 (UTC)

Thanks for explaining. I wonder if there would be consensus to update MOS:GENDERID to remove the word living so it applies to all trans people, living and deceased (as an alternative to this proposal)? It seems like the current guideline addresses many scenarios that this proposal doesn't. The void century 13:10, 24 June 2023 (UTC)

I think it should be even further modified to remove the word "notable" since it is in direct conflict and a violation of the notability guidance. Huggums537 (talk) 13:20, 24 June 2023 (UTC)

@Huggums537 I think this is more related to WP:OTHERNAMES, which relates to the notability guideline. The new guideline would ask-- is the subject still WP:NOTABLE if the article only covered pre-transition (when the deadname was used)? If the answer is yes, then the deadname is a valid alternate name, and would meet WP:POFR as well. This is a narrower interpretation of alt names than usual, but I think it makes sense in this context. The void century 16:26, 24 June 2023 (UTC)

The problem isn't that we are asking if a subject is notable or not, (because asking if a subject is notable is perfectly fine) it's that we are asking if the subject should be included within an article based on this notability. Notability is reserved for determining if a subject should have an article, not be included within one. In other words, if the answer is yes the subject is notable, then it deserves to have an article. That is what notability is for - to figure out if subjects are worthy of articles, not if a person, place, thing, or a name can be mentioned in an article. Huggums537 (talk) 07:37, 25 June 2023 (UTC)

It's a huge problem that not only do we have a bunch of people who don't understand this, but we also have [some] deletionists who understand it perfectly fine, but have no issue with propagating the misunderstanding since it favors their cause. As a result of this, we have people either intentionally or mistakenly inserting incorrect or conflicting information in our guidance such as the incorrect mention of notability in the OTHERNAMES link you provided. It's a perfect example of why WP:IAR is probably one of the best of our WP:5 Pillars. Huggums537 (talk) 07:50, 25 June 2023 (UTC) Updated on 14:05, 25 June 2023 (UTC)

I'm ignoring the Huggums bait. I'm pretty sure he's the only user who interprets WP:NNC the way he does, and it's not worth diverting this discussion. I asked if he wanted to start a RFC to remove "notable", above, and he said no ... so that's all there is to discuss.

As to your comment re: "living"‚ funny you should mention that! We just recently had an RFC where that was proposed, along with a few other options. (In short, as to the question of "When should the deadname of a deceased person who was not notable prior to transitioning be mentioned?", the options were "Always / Sometimes / Never". The "Never" option just removed "living" from the current guideline. When that discussion closed, however, the closer found that there was no consensus for any of the options presented—rather, he found, there was a consensus for some alternative approach that would split the difference between Option 2 ("Sometimes") and Option 3 ("Never"). This RFC was started to try to find that split approach.--Jerome Frank Disciple 13:45, 24 June 2023 (UTC)

My view is not as extreme or as rare as JFD is making it out to be. JoelleJay essentially argued the same thing by making the point that this proposal is trying to apply the same notability criteria to a mere piece of content that it does an entire article. The current MOS:GENDERID does the same thing against WP:NNC. Huggums537 (talk) 13:49, 24 June 2023 (UTC)

I'm also going to add to this that SMcCandlish made almost exactly the same point before I even entered into this conversation, and they have had knowledge of the concept before I even became a regular editor so this concept isn't unusual or rare by any means. It is just misunderstood by those who are not fully familiar with the guidelines, and that is to be expected since there is so much WP:CREEP you can't possibly know them all. Huggums537 (talk) 07:12, 25 June 2023 (UTC)

> The current MOS:GENDERID does the same thing
So the proposal follows an already existing example in the current MOS. Excellent! – .Raven  .talk 19:56, 24 June 2023 (UTC)

No, it means we have a WP:POLICYFORK which is not permissible and must be fixed. Guidelines don't get to override policies, and guidelines even conflicting with other guidelines have to be repaired.  — SMcCandlish ☏ ¢ 😼  09:02, 25 June 2023 (UTC)

While I don't agree that we have a POLICYFORK issue here, if we do have one, we've had it since July 2015. The first time anything remotely like the current version of GENDERID was added to MOS:BIO it read In the case of transgender and non-binary people, birth names should only be included in the lead sentence if the person was notable prior to coming out. One can introduce the name with either "born" or "formerly". In the intervening 8 years, despite many discussions and RfCs on the guideline, many of which focused on whether to include or exclude a deadname, prior to this RfC NNC had been mentioned three times; by Godsy in June 2016, by Rabbitflyer in August 2021, and by Iamreallygoodatcheckers in August 2021. In all three instances the concerns were either dismissed by other argumentation, or not otherwise remarked upon by discussion participants.

However, I said I don't agree that we have a POLICYFORK issue, and that is because I believe there is a misunderstanding here of what the current version of GENDERID (or my proposal) means when it says If a living transgender or non-binary person was not notable under a former name (a deadname), it should not be included in any page. The guideline does not apply WP:N to content, instead the guideline is using N as a shorthand way of saying something akin to If a living transgender or non-binary person changed their name prior to an article about them being created, it should not be included in any page. In this instance, N is effectively an easy to define cut-off date for when a former name can be included for a living trans or non-binary person. It is a date and time. If a living person has an article about them, and transitions after that article was written, then we likely include their former name as they are very likely a public figure and WP:BLPNAME would not apply. If instead that person transitioned prior to us writing an article about them, then we likely will not include their former name, because at that point their former name is a privacy issue and BLPNAME applies in part. Sideswipe9th (talk) 00:05, 26 June 2023 (UTC)

Thank you -- I read it the same way, and I'm very confused on why some people think there's a conflict. The void century 02:47, 26 June 2023 (UTC)

If a living transgender or non-binary person changed their name prior to an article about them being created, it should not be included in any page. The problem here is that you are trying to shift the focus on a date and time, but the date and time doesn't matter. Neither does "living" or "dead". What matters is that whatever the time and date might be, you are wanting to use notability as the criteria to include content "in a page". That is the conflict. The before or after is completely irrelevant because you can't use notability as a criteria to include content "in a page" either way so date and time means nothing. There is no "cutoff date" for this rule. If you are saying the inclusion of content within a page depends on whether a previous article existed or not, then it is even worse than using notability as a criteria because you would actually be using notability of something else as a criteria which is like off the charts nuts. Huggums537 (talk) 07:10, 26 June 2023 (UTC)

@The void century: I wonder if there would be consensus to update MOS:GENDERID to remove the word living so it applies to all trans people, living and deceased (as an alternative to this proposal)? That was topic 2, option 3 in the RfC that was held earlier this month. While it had the highest level of support of any of the options, it did not have enough support on its own to form a consensus. Sideswipe9th (talk) 00:12, 26 June 2023 (UTC)

I suggested this above, but one alternative that might be more palatable is to require deadnames be documented in multiple HQRS that provide SIGCOV of the person. This is a lower bar than requiring the person be notable pre-transition, but higher than just being mentioned in RS. It also restricts deadname inclusion to only those subjects whose deadnames are likely to be more widely known already (by virtue of appearing in several pieces of SIGCOV of the individual).

Another alternative, or addition to the above, would be to require the deadnames appear across WP:SUSTAINED coverage. JoelleJay (talk) 03:00, 25 June 2023 (UTC)

Yes, this kind of smart compromise thinking is where this discussion should be going, instead of polarized entrenchment.  — SMcCandlish ☏ ¢ 😼  09:05, 25 June 2023 (UTC)

If you add WP:HQRS should be secondary sources, this is essentially WP:GNG. That seems like more of a fork than just using the word "notability", but if it raises less alarms for others, then it's fine with me. The void century 14:08, 25 June 2023 (UTC)

Yes, this has always been my argument. That it is just notability without the name... Huggums537 (talk) 14:13, 25 June 2023 (UTC)

I would prefer if they used a valid WP:Content policy for governing stuff within articles such as WP:NPOV, WP:DUE or WP:V. Huggums537 (talk) 21:22, 25 June 2023 (UTC)

@The void century, I don't follow? Yes if the sources were also independent and secondary they would contribute to GNG, which the article subject should usually be meeting anyway. If multiple post-transition sources that provide SIGCOV of the subject also happen to mention the deadname, then the deadname would qualify for inclusion, even if it itself is not discussed in depth. JoelleJay (talk) 00:51, 26 June 2023 (UTC)

• Your proposal: require deadnames be documented in multiple HQRS that provide SIGCOV of the person
• WP:GNG: has received significant coverage in reliable sources that are independent of the subject.

I don't follow how these are different. Is the distinction you're making that the deadname itself is documented in the sources? Presumably, if a person was notable prior to transition, both the person and the deadname would be documented in the sources.

I understand now. Your proposal lowers the bar to say that in-depth analysis or discussion of the name are not required, nor notability pre-transition. Instead, all that's required is multiple reliable sources mention the deadname, as long as the subject itself receives SIGCOV. The void century 02:56, 26 June 2023 (UTC)

Thinking through the difficulties

Even under this proposal, if the deadname is included, it's included immediately. This leads to issues such as Wendy Carlos - universally known as that name for the last fourty years - being deadnamed in the first sentence.

If we look beyond trans individuals, it's pretty normal in articles on actors or singers, where a person is basically only known by one name throughout their life - say, Tina Turner or W. H. Kendal to include their birth name, even when it's of very limited notability. But those names have no capacity for harm. And note that Kendal's birthname isn't mentioned until the second paragraph, which is honestly more respect than we show the average trans person, when there's not even an indication Kendal disliked his birthname.

I'm rather against this proposal, as it all but codifies deadnaming people in the first sentence. There's going to be cases where people came out as trans long after their career was all-but over. Dee Palmer, say, might need to do that just so you know who she is. But can't we state that the more of their career, the more of their notability is seperated from their transness, the further into their article the appearance of their deadname should be, bottoming out at simple non-inclusion?

It's weird to have this binary form where we either show all possible respect and care as regards deadnaming, or absolutely zero respect, policy all but requires we out them in the first few words. The examples given are probably justified - known most of their lives under the deadname, and much of their notability predates it - but that's not going to always be the case. Wendy Carlos is a good example where the deadname probably needs a brief mention somewhere, but almost all commentary on her for decades has used her preferred name, so including it right at the start isn't justifiable. Adam Cuerden ^(talk)_{Has about 8.4% of all FPs.} 08:53, 15 June 2023 (UTC)

I agree with all of this, and would like to add that I feel like we've in general been assigning too much encyclopedic value to previous names.

One specific bad example is Tokugawa Ieyasu, a man who changed his name several times throughout his lifetime. We go into a level of detail about this and commitment to swapping the names we use as he changes them that almost no other source would, because it's frankly very confusing. (It's also a little bit ahistorical? Very few people at the time would have been calling this man by his personal name, so the really important name change is Matsudaira to Tokugawa, and it's weird that the article emphasizes the change in personal name instead.) Loki (talk) 17:31, 15 June 2023 (UTC)

I also agree with Adam Cuerden; I made much the same point earlier. And yes, there's too much foregrounding of former/formal/full names generally. Sandro Botticelli begins "Alessandro di Mariano di Vanni Filipepi (c. 1445 – May 17, 1510)", which is excessive for the opening. But that's probably a separate discussion. EddieHugh (talk) 17:55, 15 June 2023 (UTC)

While I agree that we shouldn't be deadnaming in the first sentence, though it seems to be standard practice across many trans and non-binary biographies, I'm not sure where the idea that this proposal is codifying it comes from. While the examples all come from their respective article's first sentences, the same is true for the second set of examples that are currently present in MOS:GENDERID. The only specific guidance on how to introduce the former name, with the use of "born" or "formerly" as contextually relevant, also mirrors the exact same guidance that is already present in GENDERID's third paragraph.

If there's a consensus that this is a problem due to giving undue prominence to the former name(s), it has already has a wider effect than what would be covered under this proposal, as the exact same implication already exists for living trans and non-binary individuals who were notable under their former name(s). That suggests to me that if we need to resolve this, then we need to resolve it in a manner that would have effect on both paragraphs (the already existing, and proposed one). Sideswipe9th (talk) 18:16, 15 June 2023 (UTC)

@Sideswipe9th: Put simply, if both examples given show it being done in the first sentence, no text in the proposal discusses alternatives to it being in the first sentence or when it should be, then it's a de facto codification. Examples serve as a template for how things should be implemented, after all; that's the point of them.

Add to this that we know it's already a trend that happens, so the examples are reinforcing the trend. If any example was included that showed a deadname being included further into the article, it'd avoid setting a standard; this could also be done by simply saying that other options exist, and that how prominent a deadname should be can vary. Adam Cuerden ^(talk)_{Has about 8.4% of all FPs.} 02:18, 24 June 2023 (UTC)

@Adam Cuerden: Unfortunately I'm not sure this is something we can solve, at least not without re-writing some articles. When compared against cisgender biographies, we don't have that many trans and non-binary biographies to begin with. When we're already limiting the pool to find examples that sufficiently illustrate specific criteria from the proposed guideline, to then add the further restriction that it also has to be a biography where the name is not mentioned in the lead sentence, you're asking us to find a needle in a small haystack. Short of re-writing a relevant article to meet this extra request, this is I think something where seeking perfection is the enemy of the good. Sideswipe9th (talk) 21:28, 25 June 2023 (UTC)

I agree that "if included, the deadname must be in the first five words (Current Name, biologically Old Name,...)", like some people treat the rule as being [although it is not that], is not a one-size-fits-all approach; I support putting once-notable deadnames that have long been unused by anyone where they're more relevant. I've seen articles mention marginally notable, long-unused deadnames (of e.g. actors who did one minor film pre-transition, and many major films post-transition) in ==Early career==, which seems more sensible than putting it in the first five words. (I've seen editors remove the name entirely from such articles, too, which also seems reasonable.)
In the past, some people argued "what if I'm reading a decades-old news story from before Wendy Carlos transitioned, it mentions her under her former name, I look that up but only read the first five words, decide not to read anything else, decline to contemplate why my search for a male name got redirected to Wendy Carlos, and as a result of these decisions would be left confused if the name weren't mentioned in those first few words?!"; if that's a problem, we could make the deadname redirect to the part of the article where it's mentioned rather than just the article overall. But we already redirect a lot of e.g. placenames in one language to another language, without always mentioning the redirect in the lead — sometimes it's only lower in a section on Names, or even absent.
But since this RfC is to pin down when to mention a deadname of a dead person, where to mention the deadname of even a living person seems like a separate issue, no? I also don't see anything in this RfC that says the name must be in the lead. Elsewhere, the guideline says it can be in the lead only if it's notable, but as discussed on the guideline's talk page, even that is not "it must be in the lead if...". I think we could start to article-talk-page discussion about repositioning Wendy's deadname even under the current guidelines, and certainly independent of this RfC about dead people. -sche (talk) 20:43, 15 June 2023 (UTC)

Biologically? -- Maddy from Celeste (WAVEDASH) 20:49, 15 June 2023 (UTC)

I think that's a joke intended to poke fun at editors who insist on this. Loki (talk) 00:48, 16 June 2023 (UTC)

Genetically. Which I think means that all valid names must be composed of the letters A, C, G, and T. – .Raven  .talk 19:59, 24 June 2023 (UTC)

The problem I see with redirecting to a section of the article is that people searching for a deadname likely are looking for information about the person rather than the name, so sending them to information about the name isn't that helpful. -- Maddy from Celeste (WAVEDASH) 20:51, 15 June 2023 (UTC)

I could see it depending on the context. If it's likely someone coming through an old redirect isn't aware of the new name, it could be helpful to plop them in the section where the transition is explained so it's clear why they're here. I don't think that necessarily fits all situations like this cleanly though. Loki (talk) 03:15, 16 June 2023 (UTC)

Every redirect should lead to the portion of the article that is most likely to be helpful to the majority of people using that redirect. Where in the article that is can only be determined in the context of both article and redirect. Thryduulf (talk) 13:37, 16 June 2023 (UTC)

• I would also note that all our other alternative name info is included at the start, so if someone with any experience of reading wikipedia articles (that is, almost everyone) is looking for that information and it's not at the start - they'll probably assume it just doesn't exist. Adam's assumption of what will happen is almost certainly correct, but I stand in the side that thinks that will normally be a net benefit. Nosebagbear (talk) 13:20, 17 June 2023 (UTC)

  That's a lot of assumptions. Bastun^{Ėġáḍβáś₮ŭŃ!} 16:55, 17 June 2023 (UTC)

• More guidance on where to mention a deadname in an article would be helpful. But here too, one-size-fits-all is the wrong approach. For someone like Caitlin Jenner, she was notable enough as “Bruce” that we should mention that name in the first sentence. However, that is not going to be the case for others. In many cases it would be more appropriate to place the mention in its historical context - ie in an “Early life” section or Similar. There is no need to put everything in the first sentence. Blueboar (talk) 19:34, 22 June 2023 (UTC)
• I agree about the issues with the current way deadnames are included. I'm starting to like the idea of putting deadnames in a footnote to the lede sentence in general. This would put them in a predictable location for readers, but also avoid giving too much emphasis and prevent them from being snippeted onto the front page google results for the article subject. small jars tc 13:30, 23 June 2023 (UTC)

  But please keep in mind of pre-notability deadnames, per MOS:GENDERID:

  If a living transgender or non-binary person was not notable under a former name (a deadname), it should not be included in any page (including lists, redirects, disambiguation pages, category names, templates, etc.), even in quotations, even if reliable sourcing exists. Treat the pre-notability name as a privacy interest separate from (and often greater than) the person's current name.

  – .Raven  .talk 02:28, 24 June 2023 (UTC)

• Not sure where best to put this observation, but should we have an RFC at some point on non-trans related personal name changes and whether those are necessarily encyclopedically significant either? I've seen that comparison come up in this RFC and it feels like a good idea to clear up that area; do we really need to mention the old name of a non-trans person who changed their name and then became notable, with whom sources do not typically mention the old name? Skarmory (talk • contribs) 05:15, 26 June 2023 (UTC)

Deadnames & dead people - an idea

• Ok, I have been thinking about this a bit and would like to propose something… when determining whether to mention a deadname for LIVING trans people we say to give significantly more weight sources written AFTER transition.
  So… when determining whether to mention the deadname of a DECEASED trans person, shouldn’t we (similarly) give significantly more weight to sources written AFTER the person’s death?
  This would (I think) help to resolve at least some of the issues discussed above. Blueboar (talk) 13:16, 25 June 2023 (UTC)

  That's a really intriguing thought! It's definitely interesting, although I'm not sure MOS:GENDERID currently says to give more weight to post-transition resources as to whether or not to include a deadname of a living trans person ("when determining whether to mention a deadname for LIVING trans people we say to give significantly more weight sources written AFTER transition"). I think the idea is that someone who is not notable pre-transition won't have that many pre-transition sources, not that post-transition sources are given more weight. That said, whether or not that's what we do it for living trans persons, I'm intrigued about whether a post-death sources rule could work for deceased trans persons. Would love to hear more thoughts--Jerome Frank Disciple 13:22, 25 June 2023 (UTC)

  Hmm...I don't know that I follow the logic...? when we're determining what name(s) to use or mention, the difference between pre- and post-transition sources that makes it more useful to look at one of those than the other is that sources from before a transition simply didn't have the option of using the post-transition name, so we can't tell whether they would've chosen to exclusively include the post-transition name, or to use the post-transition name while mentioning the former name, or what. But what difference do we expect to exist between (post-transition) sources from before vs after someone died, as far as how they cover transition? I guess I'd like if we could get data on whether post-death sources actually tend to do anything different with the names than pre-death sources, to be able to determine whether this would even change anything (in any direction).
  I also want to note the difficulties this might run into with people who are notable when they're young (e.g. musicians or athletes) and then fade into obscurity. If twenty sources about someone are from when they were making headlines at age 20-30, three are from when they wrote a memoir and got some press at age 80, and one is an obituary after they die at age 91, I don't know that it'd make any sense to say "well, the other sources (do/don't) mention the deadname, but the one post-death source does the opposite, let's weigh it more heavily" (regardless of whether that one source is including or excluding a name!). (Perhaps we could say, OK, only weight post-death sources more heavily if there are N of them, or they constitute N percent of available sources, but again, I guess I'd just like data on whether this would actually have any effect, or whether most post-death sources do the same thing as pre-death sources when it comes to deadnames.) -sche (talk) 22:19, 25 June 2023 (UTC)

  Wow—great points, particularly regarding persons who fade into obscurity (but are still notable).--Jerome Frank Disciple 22:51, 25 June 2023 (UTC)

I haven't read the full discussion above, but what cases exactly are we covering here? The living trans people we cover right now will die in the future, are we suddenly switching from post-transition sources to post-death sources for the name (though I doubt this actually would have an affect on anything)? Is this for cases where there's little to no coverage of the person after transition but before death? Skarmory (talk • contribs) 05:09, 26 June 2023 (UTC)

What license applies to versions of documents prior to May 31, 2023?

Wikipedia's license changed to CC BY-SA 4.0 after June 1, 2023.

So, what license applies to versions of documents prior to May 31, 2023?

CC BY-SA 3.0 or CC BY-SA 4.0? Ox1997cow (talk) 18:14, 14 June 2023 (UTC)

Obviously the old content will remain licensed under CC BY-SA 3.0 but later derivatives (adaptations) will be licensed under CC BY-SA 4.0. Ruslik_Zero 20:30, 14 June 2023 (UTC)

Can somebody ELI5 what changed? Reading https://creativecommons.org/licenses/by-sa/3.0/ and https://creativecommons.org/licenses/by-sa/4.0/ they look identical to me. -- RoySmith (talk) 20:43, 14 June 2023 (UTC)

https://creativecommons.org/Version4 may be helpful, as well as some of the other links at https://wiki.creativecommons.org/wiki/License%20Versions#License_Versioning_History . isaacl (talk) 21:56, 14 June 2023 (UTC)

Thanks. Ox1997cow (talk) 15:33, 15 June 2023 (UTC)

The permissibility of large tables of primary-sourced technical information, and other similar content

I've noticed two hotly-contested articles where people have been arguing bitterly about whether or not to keep large tables of information on computer hardware sourced from the manufacturer, Exmor and iOS version history. I've also noticed more nascent or potential conflict in this vein brewing on some other similar hardware article talk pages, such as List of Nvidia graphics processing units and ISOCELL, and I wouldn't be surprised if there's more elsewhere. It seems to have started sometime around last November, and it may just continue to grow, because the arguments many people have made in favor of removing the tables could apply to similar tables and lists on many articles. Those arguments, which in policy terms rest more-or-less on a combination of WP:NOTCATALOG and WP:PRIMARY I think, do not seem to convince many other editors who are attached to the tables (as well as many readers who jump in as IPs or make an account just to argue for the tables being kept). The editors in favor of the tables don't seem to make policy-based arguments like that for their side as much, but they don't at all seem convinced that policy is on the side of their opponents.

I'm not really invested in either side. Rather, I just think it would be nicer for everyone involved if the policy was more clear, so it's not such a potent source of conflict. Many of those tables have been on Wikipedia and continuously maintained for over a decade; if we're going to start saying that their contents absolutely need to be sourced from secondary sources and well-integrated into the flow of the article text and so on, and otherwise they need to go, that does seem sort of like a new status quo in practical terms that could upend many articles, and it would be worth establishing that unambiguously if that is really what people want.

As things currently stand, the main argument I could really see against the tables from WP:NOTCATALOG is the "simple listing" clause, and it strikes me as very much a matter of opinion what constitutes proper "contextual information" that would justify the presence of one of those tables. You could maybe also argue from its WP:NOTPRICE clause but these kinds of tables don't include price information and aren't necessarily for conducting business per se. So, I think if people want to use WP:NOTCATALOG as a basis to remove the tables, it should probably be worded less ambiguously to that effect—perhaps removing them is in the spirit of WP:NOTCATALOG(?) but the language leaves plenty of room for counterargument. As far as WP:PRIMARY goes, I think you could make the argument that as long as the article the table is embedded within is based mainly on secondary sources and passes the notability threshold, WP:NLIST could possibly give the table a pass. So, overall, it doesn't exactly seem to me like an open-and-shut case in policy terms that the tables just don't belong, at least in terms of existing policy. That's not to say that I think the arguments against them are wrong necessarily, just that I don't think existing policy is so clear as to leave no room for doubt—in trying to figure it out I've just been left feeling kind of confused.

(Of course, people also make lots of arguments on both sides that aren't really based in policy—often that the tables take up too much space in page layout or data terms, aren't encyclopedic, and could go elsewhere on the Web on the one hand, and that the tables are useful, unique, and the product of years of work on the other hand. I'm not sure if there's any good way to weigh these sorts of arguments against each other as they're rather at cross-purposes.)

So, if there's an article that is well-sourced and clearly notable and so on, and it has a large table based on primary sources like manufacturer documentation, assuming the overall subject of the table is covered in secondary sources and its contents aren't copyvio, should it stay or go, if it's possible to state a general guideline? Does it matter if the table stands apart from the rest of the article? Does anything change if the table is so huge that half the bytes of the article are just given over to the table, or if the article has little text and consists mostly of giant tables? All of these things and more have been the subject of controversy and it doesn't seem like either side really has a devastating argument to make right now that the other side will accept, so I worry that if we can't clarify the policy somehow overall, every large primary-sourced table across the encyclopedia will be fought over one-by-one in the months and years to come. Mesocarp (talk) 22:08, 15 June 2023 (UTC)

Thats a rather long text to read. But I also noticed that tables were and are an issue lately. Specially if tables should be sourced or not was the issue there. Eventually the party who demanded a sourced table won, but there was a discussion about if tables should be sourced or not. Also in the recent ITN discussion on the posting of the Stanley Cup Finals this was an isssue. The it was sourced with NHL, but I saw the source as used in good faith and the article had a lot of prose as well. Paradise Chronicle (talk) 22:36, 15 June 2023 (UTC)

You may be interested also in WP:NOTSTATS and WP:NOTCHANGELOG. If there is no context in prose, tables should not be on wikipedia is what I understand from WP:NOTSTATS. In the finals article was a lot of prose to provide context, in the Exmor was a reasonable text, but the list seemed also to me excessive. The views

(over 7000) seem ok. The NVIDIA one is really boring to me as almost no prose but this seems to be a personal preference, the views (over 75'000) give reason to believe there is some interest in such tables. Paradise Chronicle (talk) 23:05, 15 June 2023 (UTC)

Yeah, sorry for the length! I'm trying to get better about writing long passages like that—I did actually edit it down some before posting, believe it or not, but I'll be more aggressive next time. It's interesting to know that the issue extends as far as tables like this on sport articles. I guess WP:NOTSTATS could also be used to build an argument against these sorts of tables, although at least in the context of computer hardware it semes kind of hard to say how much the information qualifies as "statistics" or not. WP:NOTCHANGELOG seems more precise and I think did actually make for some strong arguments in part of the iOS version history discussion, but of course that only extends as far as changelogs. I think the level of precision in WP:NOTCHANGELOG is nice, and it would be nice to be able to answer some of these other table questions that precisely, alhough I don't know if that's practical or not. The idea that the tables shouldn't be there without prose context seems hard to pin down, on the other hand—I'm not really sure how people who disagree could answer the question of how much context is enough. A lot of these hardware-related tables have at least some amount of surrounding article where the topic of the table is mentioned. Mesocarp (talk) 01:19, 16 June 2023 (UTC)

This is basically the tip of an iceberg of dreck; it is not limited to just those pages. There were recently several very high-profile deletion discussions along the same lines (Firefox version history (2nd nomination), IOS version history (2nd nomination), and Google Chrome version history (2nd nomination)). These spurred a huge discussion at WT:NOT about the changelog thing (which mostly did not go anywhere). jp×g 17:07, 16 June 2023 (UTC)

Yeesh. Yeah, as I said, I get the impression that this is a wide-ranging issue that has probably touched many articles and will touch many more if things go on this way. I didn't realize that even WP:NOTCHANGELOG itself is part of the controversy, although I guess I'm not surprised. It is kind of strange to me how little WP:NLIST seems to be getting brought up in these discussions, since it explicitly says that each item in a list or table doesn't need to be notable as long as the whole topic of the table or list is. I think the vague wiggle room given there, though—"editors...may choose to limit large lists by only including entries for individually notable items"—is rather unfortunate and a huge source for the current conflict, though. Many people seem to be running straight to "everything in the table must be sourced from secondary sources or it goes," for basically any of these tables, which doesn't quite seem in the spirit of the existing policy to me but is technically allowed for by that kind of language. You can always say "it's too big"—it's really a matter of opinion. I don't think the ambiguity would matter as much except that it seems to be fuelling so much conflict. Mesocarp (talk) 23:07, 16 June 2023 (UTC)

Wikipedia decisions are made based on weighing multiple considerations. This area is a particular blank spot in policies and guidelines and so relies on such to an unusual degree. I think that wp:lists needs to be strengthened so that it provides more input for such discussions and in particular, to strengthen the consideration for "how likely is this to be useful for an encyclopedia reader?" For the examples given, IMO these factors/questions weigh in:

• How enclyclopedic is it? E.G. degree of compliance with wp:not. The example articles get minus points in this area. Product details on products.
• Degree of real world notability, and degree of wp:notability. Besides a basic screening function this also affects "how likely is this to be useful for an encyclopedia reader?" A software family line with a billion users would rate highly here. An obscure one far less so and the main beneficiary would probably the people owning/promoting it getting Wikipedia publicity.
• Scale/prominence of the info in the individual entries. For example tiny details that are excluded by not-a-changelog vs. listing of versions with high public visibility / identity.

Sincerely, North8000 (talk) 17:40, 16 June 2023 (UTC)

I agree that it would really help to clarify the list criteria, but it seems like a big puzzle to me at this point what should actually be done. I think any changes that would be made should be to the effect of making the list/table policies more precise, so that it's easier to settle disagreements around them. The trouble with criteria like encyclopedicity, notability, usefulness, etc. is that they're so in the eye of the beholder when it comes to these kinds of tables, and that leaves all kinds of room for very motivated reasoning. There seem to be editors out there right now who basically don't like these kinds of tables period, and for every table they want to remove, there is another group of editors equally passionate that nothing be done to it no matter what. Both groups will resort to anything they can muster to make their case, so when the policy is vague and open to wide interpretation, it becomes almost impossible to settle the debate to anyone's satisfaction. Mesocarp (talk) 23:26, 16 June 2023 (UTC)

User talk page blanking

Hi, I’ve come across a few users who like to blank their own user talk pages rather than archiving them. I know it’s not an official policy or anything, and merely just a guideline, but one of these blanked pages had a lot of discussions, and if any of these discussions were linked to elsewhere, it would be nice to have them still around as reference. Thoughts about possibly changing this guideline/policy? Or possibly a bot that could monitor page blanking, and automatically archiving these discussions? Fork99 (talk) 23:52, 16 June 2023 (UTC)

Example: User talk:MetroManMelbourne. Fork99 (talk) 23:54, 16 June 2023 (UTC)

All the discussions are still there, just in history rather than in archive. A bot that moves things to archives would be breaking any wikilinks that were to the talk page anyway. The idea that people cannot actually blank their own talk page, that we have to keep every drive-by insult to them in an archive page, is a bit of a problem. -- Nat Gertler (talk) 01:14, 17 June 2023 (UTC)

Fair enough, I meant things other than warnings and notices though. Or instead of automatically archiving, a bot could just suggest doing so? Fork99 (talk) 01:18, 17 June 2023 (UTC)

It probably could end up being a strain on the Wikipedia servers and possibly an eyesore on user pages, I do understand. Possible exclusion criteria for a bot not to add a notice would be IP user talk pages, and/or pages without many discussions. Maybe a cut off at say x number of bytes or depending on how old the talk page is. I don’t know, just some thoughts. Fork99 (talk) 01:23, 17 June 2023 (UTC)

I am one of those who routinely blank my talk page. I think of it like I do voicemail on my phone. Once I have read a message, I rarely need to keep it… and if I (or someone else) needs to refer to it in the future - it’s in the page history. By routinely blanking old messages, new messages are highlighted and I will respond to them quickly. Blueboar (talk) 11:19, 17 June 2023 (UTC)

Yes, there are some things that are more convenient for others if they are left on the talk page or archived, but creating rules around them, and especially any automated procedures, would be overkill. It's better just to say that anyone can manage their userspace as they see fit and to get on with creating an encyclopedia. Phil Bridger (talk) 11:38, 17 June 2023 (UTC)

I too am someone who feels disappointed by the choice to blank user talk pages. If I were to view a user's talk page, it would provide helpful insights into their style. However, the deletion of talk pages remains a personal decision within their realm of freedom. The idea of automatically archiving valuable discussions is excellent, but it may be challenging to implement realistically, as it is unlikely to be widely embraced by many individuals. Meloncookie (talk) 07:50, 19 June 2023 (UTC)

My only comment is about obligations to check if an editor is CT aware and whether they have simple deleted a notice without otherwise acknowledging they are CT aware for a particular topic. Cinderella157 (talk) 10:55, 19 June 2023 (UTC)

Cinderella157, there is an edit filter, 602, that can see if/when a user was given a DS/CT notification, so that makes it fairly simple to check even if the notification was not archived. Curbon7 (talk) 20:20, 21 June 2023 (UTC)

Nope, if you need to link to a discussion for some sort of documentation somewhere else, use a diff or permalink. — xaosflux ^Talk 18:18, 19 June 2023 (UTC)

My problem is that s blanked talk page looks like a new user’s talk page which is confusing.Doug Weller talk 20:43, 21 June 2023 (UTC)

A blanked page has a page there. A new user has no page there and asks you if you want to create a page. Unless the user is forced to include an archive indexing on his talk page, an archived talk page would look like a blanked page as well. -- Nat Gertler (talk) 21:15, 21 June 2023 (UTC)

I've certainly seen new accounts given several first-level warnings by vandal fighters who might have acted more strongly had they noticed that the editor had already removed previous warnings. Certes (talk) 21:27, 21 June 2023 (UTC)

I always check the page history… just for that reason. Blueboar (talk) 21:46, 21 June 2023 (UTC)

RfC regarding individual area codes

You are invited to the discussion at Wikipedia:WikiProject Telecommunications/Area codes RfC regarding the notability of articles about individual area codes. Thryduulf (talk) 18:44, 17 June 2023 (UTC)

Relist Template talk:Infobox military conflict#RfC on "supported by" being used with the belligerent parameter

Relisting for further input. Cinderella157 (talk) 11:57, 22 June 2023 (UTC)

RFC because we really need to relook WP:NEVENTS

[Note: I'm not sure if i'm at the right place to ask this or if i'm asking this correctly so please]

So i've noticed some issues of the community's usage of WP:NEVENTS and especially WP:EVENTCRIT. Specifically that no one even remembers these policies exist and how no knows how to interpret these rules.

Firstly, no one really uses NEVENTS at all and especially EVENTCRIT. While i have seen lots of uses of WP:ROUTINE rarely is EVENTCRIT ever even used. The only person i've seen that ever uses these is @Thebiguglyalien: and when looking at their WP:AFD nominations you can see the issues. when you look at this nom and this nom and this nom and this non you see that basically no one uses WP:NEVENTS to make their argument (though that last nom does have just one person making an argument with NEVENTS). Now, does this automatically make alien correct in their nominations, no, does this make the people voting in alien's nominations wrong, no, but does this mean that people rarely ever use NEVENTS in afd nomination about events, the very thing NEVENTS is about, yes. The collective amnesia this community seems to have when it comes to WP:NEVENTS is astonishing as no one seems to base anything on this.

But then there's the issue of how we even interpret WP:NEVENTS. There are multiple different ways people interpret NEVENTS. take a look at the ITN nom for the 2023 Yinchuan gas explosion and you can see that people have very different ideas on whether or not the article is actually notable enough to exist. Something that i've especially noticed is that interpretations of WP:PERSISTENCE is very different as well. People disagree on whether we need days, weeks, months, or even years of coverage to meet PERSISTENCE and WP:LASTING. This all results in confusion as everyone just has their own interpretations of the rules.

Because of all of this, I think Wikipedia needs to have a discussion about NEVENTS and EVENTCRIT because no one remembers these guidelines, no one agrees on how to use these, and it's just become a giant mess. Especially when so many wikipedians use WP:MINIMUMDEATHS in many of their arguments when it doesn't exist as a guideline. Onegreatjoke (talk) 20:02, 22 June 2023 (UTC)

Regardless of what conclusion is reached, this is a discussion that needs to be had (I gave up after trying to start it here and here). This huge discrepancy between notability guidelines and AfD/ITN !votes just makes things more difficult for everyone. Either we need to get rid of these notability requirements, or we need to start enforcing them. My understanding of these is that it has nothing to do with days/weeks/months/years.

Sustained coverage, as I understand it, means that the subject has received coverage after it is no longer a developing news story. For example, news reports of a disaster and subsequent updates about damage and casualties would not count toward notability, because that's coverage as it's happening (which also makes it a WP:PRIMARY source according to academic consensus, see WP:PRIMARYNEWS for explanation). But if outlets are publishing retrospective articles after all of the updates have been reported on, then that demonstrates WP:GNG/WP:SUSTAINED/WP:PERSISTENCE. Likewise, WP:LASTING isn't about whether things are happening after a certain amount of time. It's about whether another notable event happened because of it. I'll use the example on the guideline page: For example, the murder of Adam Walsh ultimately led to the Adam Walsh Child Protection and Safety Act.

I also have a solution that I think would work: these event articles don't need to be deleted. Instead, events that can't demonstrate sustained coverage or WP:EVENTCRIT should be merged into "List of X events" type articles, where each one can be briefly expanded upon without having to worry about notability. Thebiguglyalien (talk) 20:37, 22 June 2023 (UTC)

Some people have made similar arguments regarding articles on alleged UFO sightings, e.g. here. There seems to be a strong consensus at AfD that three reliable sources mean notability and that reports in quality media count even if they merely state that something happened. And there seems to be little interest in changing that.

Then, shalt thou count to three. No more. No less. Three shalt be the number thou shalt count, and the number of the counting shall be three. Four shalt thou not count, nor either count thou two, excepting that thou then proceed to three. Five is right out. (Monty Python and the Holy Grail) -- Random person no 362478479 (talk) 09:26, 25 June 2023 (UTC)

Except that 1) we never spell out how many sources are needed to demonstrate notability via WP:N - it could take one, it could take ten. It is all about the significant coverage provided by the sources, so source counting is not an appropriate solution at AFD. and 2) WP:N and NEVENTS stress the need for both secondary sources and more than a burst of coverage. Normal every day news coverage, particularly in the immediate wake of an event, is primary, and thus while reasonable to document the event in one that is provide notable, cannot count towards notability.

AFD and in general, the creation of "news events" article, is very much broken in this area, and needs to be culled back. We have Wikinews for those editors that want to focus on news events, and should the event prove notable, we can transclude the content back into en.wiki. Masem (t) 22:35, 25 June 2023 (UTC)

If no one really uses NEVENTS at all and especially EVENTCRIT then the guidance does not properly describe the consensus of the community and so it should probably be removed. Thincat (talk) 18:47, 25 June 2023 (UTC)

Indeed - a more practical, if unlikely to be accepted, descriptive reading of the PAG is more something like "for an event to be notable either needs: lasting effects; ongoing coverage after the event has concluded; or a broad range of sourcing well in excess of GNG over at least 1 week" Nosebagbear (talk) 08:55, 26 June 2023 (UTC)