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, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191

WP:MASSCREATE and WP:MEATBOT

Both shortcuts are within the bot policy and suggest that they apply for permission for their edits here. I suggest that the top 20 of the article creators are included in the denomination of masscreating editors and they should apply for permission there. In a RFC of 2009, (also at the village pump (policy)), the article number that classifies for masscreation was not really defined, but 25-50 was not opposed. Yet also the ones who created more than 25-50 didn't apply for permission, with one of the prominent cases being Lugnuts, which in my opinion is a deplorable loss, because his investment of time to wikipedia was huge. If his and also of others energy could have been guided to a calmer area, they'd likely still edit (under their original accounts).

They could anyway have been requested to apply for permission per WP:MEATBOT (about bot-like editing), but that policy doesn't seem to have been observed or enforced when the several discussions on masscreation began. Many of the masscreating editors are lost to Wikipedia, and I'd say it is not only their fault, but in part also our fault because we were not able not guide them to a more cooperative way of editing.

In order to prevent further very long discussions, I believe it would be good to just enforce WP:MEATBOT and amend WP:MASSCREATE to the top 20 article creators of the month. If one enters the top 20, they must apply per MASSCREATE, if one edits bot-like and is able to create several articles within a few minutes or two hours they shall apply per MEATBOT.Paradise Chronicle (talk) 09:08, 21 March 2023 (UTC)

You are conflicting a few things here. WP:MEATBOT doesn't mean we treat all fast edits and lots of changes as being a bot. It talks of disruptive editing, and if it's done quickly, it makes no difference if done by a bot or by hand, and WP:MASSCREATE is talking about specifically using automated or semi-automated tools. If someone is making lots of articles with the use of tools, then they need to fill out at BRFA. If they are creating poor or disruptive articles, then they need to be raised at ANI or another noticeboard. We don't simply create policy to penalise good faith article creation, see WP:NOTBURO Lee Vilenski ^{(talk • contribs)} 09:29, 21 March 2023 (UTC)

What do @you think of amending MASSCREATE to top 20 article creators instead of only the ones who create 25 - 50 a day? Paradise Chronicle (talk) 10:40, 21 March 2023 (UTC)

What would be the point of that? Thryduulf (talk) 13:58, 21 March 2023 (UTC)

To prevent long discussions as we had with Carlossuarez and Lugnuts? Future examples might become Adamtt9 or Pvmoutside, both editors who are in the top 20. Adamtt9 creates articles contrary to

WP:NOTDATABASE, WP:NOSTATS or WP:NOTMIRROR, are poorly sourced with databases not independent to the subject. See here, sourced with that mirror/database, here sourced to that mirror/database, and here sourced to that mirror/database, all in the general references and not as inline citation. There is probably also no inline citation, I am not sure if a game between ATP number 180 with 150 is notable enough for any WP:RS. Pvmoutside creates technical micro stubs on species in danger, withholding the info that they are species in danger, see here, here and here. Nirmaljoshi is number 3 and created 19 stubs on dams in Japan within 2 and half hours after they were told to stop to create them here. Sakiv is another one, they create articles on football seasons usually full of tables contrary to WP:NOTDATABASE and WP:NOSTATS, see here, here and here. Why start an ANI discussion for each of them

?(talk) 19:12, 22 March 2023 (UTC)

? We could just formalize MASSCREATION and then there would be less discussions.16:21, 21 March 2023 (UTC) Paradise Chronicle (talk) 16:21, 21 March 2023 (UTC)

Courtesy pings to Adamtt9, Nirmaljoshi, Pvmoutside and Sakiv. Paradise Chronicle (talk) 16:26, 21 March 2023 (UTC)

Regarding the species in danger comment, I reviewed the three articles referenced. The first two are referenced properly and according to the IUCN are categorized as least concern, so I'm not sure what the editor is trying to say, the third article I did not create...Pvmoutside

You sure also created the third one, just check here. And least concern... ok and? they are still on the red list and the infobox should be a summary of the article in which you usually do not mention the red list as far as I have noticed.Paradise Chronicle (talk) 21:49, 22 March 2023 (UTC)

The reference point has been corrected...Pvmoutside (talk) 01:26, 23 March 2023 (UTC).

Uhhh, I want to correct myself. I didn't know that least concern means no concern as I figured that if they are included in the red list for threatened species they are in danger. Apparently it's not like that and I apologize. I still see those articles as taggable, let's say for too technical as they are full of latin names and acronyms and would support the removal of autopatrolled from Pvmoutside. Paradise Chronicle (talk) 07:47, 23 March 2023 (UTC)

No? Where do we state a figure for how much one can create? MASSCREATE talks about using tools. If someone wants to create hundreds of articles that are all well cited, there is no issue. Lee Vilenski ^{(talk • contribs)} 14:23, 21 March 2023 (UTC)

Tools for semi-automation would include things like boilerplate text - a necessity for anyone who is creating dozens of articles per day. WP:MEATBOT would also apply, which doesn't require any tools to have been used.

However, I agree that this proposal isn't the route forward; defining mass creation solely in terms of the most prolific editors is too inflexible and will likely exclude many mass creators, and may include a couple of editors who don't engage in mass creation. BilledMammal (talk) 15:35, 21 March 2023 (UTC)

At Masscreate it says any large-scale automated or semi-automated content page creation task must be approved by the BRFA. It is the first phrase. Since no-one seems to have been approved, no-one seems to have applied for the rights even though they surpassed the mentioned unopposed threshold and we are having very long discussions on stub creations, I thought it might help narrowing it down to the 20 most prolific ones. But if not even they can be included, who will, and then also what's the sense of having such a policy? To be included in the top 20, doesn't have to be seen as a punishment, and it is also not meant as a punishment, the amendment is meant to regulate the masscreation of articles, so the ones that are good at it, can be shown as the examples to follow to the ones who are not yet so good at it, and this before having created hundreds or even thousands of articles. Paradise Chronicle (talk) 20:10, 21 March 2023 (UTC)

What are the actual problems with the individual articles that these editors are creating (ignoring how, when and by whom they were created)? If you cannot identify any specific problems that apply to at least the majority of the articles created, and explain how classifying them as mass-created would address those problems, then all this is a waste of time.

Looking at a random recent creation (Charles Connor (actor)) by the editor at the head of that list (Lord Cornwallis) I can't see any issues. Thryduulf (talk) 22:03, 21 March 2023 (UTC)

It specifically says "automated". You are trying to make any user who creates a lot of articles need to fill out a BRFA, giving examples of people who create poor articles. All this policy is designed to do is make more work for someone actually making non-automated articles - and if they are making them badly, they'd hardly put in enough time to do a bot request form. Lee Vilenski ^{(talk • contribs)} 22:15, 21 March 2023 (UTC)

@Lee Vilenski. It says semi-automated and underneath comes

WP:MEATBOT which includes semi-automated bot-like editing. You are not fit for crat-ship if you can't properly cite policy. Paradise Chronicle (talk) 23:33, 21 March 2023 (UTC)

That simply isn't true. MEATBOT talks about disruptive bot like editing. It DOES NOT suggest that all edits that are done quickly are bot edits, nor that they are disruptive However, merely editing quickly, particularly for a short time, is not by itself disruptive. That is the bit where this falls down. This proposal suggests that all users who create lots of articles (regardless of quality) should in fact be treated like a bot, and made to fill in a form.

This is also something that is already easy to deal with with existing policy. Is the user using tools? Yes - get them to fill out the form. No? Well, are the articles disruptive, or of poor quality? Yes - report to ANI, other noticeboard, or their talk. They'll soon stop, or gain a block. No? Well, I don't really see the issue. If I wanted to create 30 articles tomorrow that were all well sourced? I don't really see what the issue is, nor would I expect someone to come along and tell me that I need to put in paperwork and become a bot.

Thank you for the personal attack, please refrain from doing these in future. Lee Vilenski ^{(talk • contribs)} 07:09, 22 March 2023 (UTC)

Yeah I am not sure if that was a personal attack or a personal point of view. I'd be glad to learn what was you see as a personal attack. You are an admin and like a politician public figure you should be receptive to criticism.

Anyway, while you are right that it is mentioned that for a short while it is not disruptive some of the Masscreators edit high speed on long term. Some like Pvmoutside are editing high speed since years. And if the short term is the one where my suggestion fails, the opposite which would be long term is where I should have your support.

Then I'll also copy paste this part of WP:MEATBOT and then all can decide for themselves.

Editors who choose to use semi-automated tools to assist their editing should be aware that processes which operate at higher speeds, with a higher volume of edits, or with less human involvement are more likely to be treated as bots. If there is any doubt, you should make a bot approval request. In such cases, the Bot Approvals Group will determine whether the full approval process and a separate bot account are necessary.

It doesn't say the edits have to be disruptive in order to apply, just that they have to be high speed enough and their edits can be treated as bot-like editing which applies to several of the top 20 article creators. The title of the shortcut MEATBOT is Bot-like editing and that it is mainly focused on disruptive editing can be a point of view, but one I do not share.

And I don't believe to start an ANI discussion for each masscreating editor I do not agree with is a good idea,Paradise Chronicle (talk) 22:42, 22 March 2023 (UTC)

You may want to peruse the recent WP:ACAS. Yes, our current rules don't address mass creation without problems and without the use of tools, and that's not ideal. A big problem seems to be some fundamental disagreements about what, exactly, the problems are when it comes to mass creation and how to define it... — Rhododendrites ^talk \\ 16:48, 21 March 2023 (UTC)

@Rhododendrites I took part in that WP:ACAS discussion, which was one of the many discussions on masscreation and no satisfying solution came out of it. Discussions go on.Paradise Chronicle (talk) 19:41, 21 March 2023 (UTC)

That was pointed out on my talk page, yes. I assumed you didn't see it because you referenced a 2009 RfC but not the one we just had on this topic (a long one that took a lot of time with, as you point out, no real solution). Not saying that should be the end of it -- it just seemed worth mentioning is all. NBD. — Rhododendrites ^talk \\ 22:16, 21 March 2023 (UTC)

@Rhododendrites Why does creation (mass or otherwise) without problems need addressing? Thryduulf (talk) 22:04, 21 March 2023 (UTC)

I don't know that it does, except insofar as there have been a lot of people who claim the existing guidance does apply, should apply in spirit, or otherwise operate as though we have rules that we do not have. My "not ideal" is just about clarity/common understanding. — Rhododendrites ^talk \\ 22:16, 21 March 2023 (UTC)

The number one editor on this list produced an average of just over four articles per day. Any of us could sit down and spend 15-20 minutes sketching out a reasonable rudimentary article on a missing notable figure, and thereby create four articles in a day, with nothing even close to resembling mass-editing. BD2412 T 22:53, 21 March 2023 (UTC)

Then if the two admins here stonewall my suggestions, how can we apply those policies? If it's not the top 20 or editors who perform semiautomated edits, then who? You are the admins, you should know. Or are you all hoping to block the next one instead of finding solution for them? Be a bit constructive here.Paradise Chronicle (talk) 23:54, 21 March 2023 (UTC)

I don't know if this adds to the discussion, but a few years ago the Tree of Life Project had a bot called Polbot which created many species pages, but was ended when many of those pages needed corrections....Pvmoutside (talk) 00:24, 22 March 2023 (UTC)

The following question was proposed previously, but a discussion on it was never opened due to the cancellation of the ArbCom mandated RfC. It might be worth revisiting?

Which proposed definition of mass creation should we adopt?
Please rank your choices by listing them in order of preference from most preferred to least preferred. Preferences, weighted by strength of argument, will be resolved through IRV.
A: A single editor creating a large number of articles based on boilerplate text and referenced to the same small group of sources.
B: A single editor creating more than 100 articles based on boilerplate text and referenced to the same small group of sources.
C: A single editor, creating more than 10 articles per day, 20 articles per week or 50 articles per month, based on boilerplate text and referenced only to the same small group of sources.
D: None of the above

BilledMammal (talk) 00:26, 22 March 2023 (UTC)

C.

The large number of A is too vague.

In B 100 articles are meant in total or per minute? If this is not clarified the ones who prefer not to apply will find any excuse. And I doubt if boiler plate should be mentioned as then a possible answer would be that they edit micro stubs manually for days and then publish all at once within a few minutes like I already read before. Paradise Chronicle (talk) 02:38, 22 March 2023 (UTC)

100 means in total; previous discussion has suggested that boilerplate is necessary, both because it can be determined by reviewing the articles, and because there is agreement that mass creation isn't simply due to the rate of creation but what is created. BilledMammal (talk) 02:43, 22 March 2023 (UTC)

Thank you for the explanation and also the constructive suggestion. Paradise Chronicle (talk) 15:52, 22 March 2023 (UTC)

@Paradise Chronicle you still haven't explained what problem you want to solve. Until you can do that everything else is pointless. What do you want to achieve by applying MASSCREATE? What benefit will doing so bring to the encyclopaedia? It's worth noting that as far as I can tell from a quick glance, none of the suggested definitions BilledMammal would apply to Lord Cornwallis' articles because they are not based on boilerplate text. Thryduulf (talk) 00:50, 22 March 2023 (UTC)

I have explained above, but you probably didn't read. The aim is to prevent long discussions in the future as we had in the past with Lugnuts and other editors. I believe if editors apply at BRFA, we can show examples to the ones who create deficient stubs. I'd say Lord Cornwallis and I believe also Moonswimmer and Esculenta for sure (articles are rather good) could serve as examples to show to editors who also want to masscreate articles. But since no-one is interested in that I thought it would be interesting to know how the policies on masscreate and meatbot can be applied. If no-one knows we can also just abolish them, then also no-one will have the idea to bring them up. Either show a way how to apply it or abolish it. Paradise Chronicle (talk) 02:16, 22 March 2023 (UTC)

@Thryduulf, I think the motivation is "drama prevention" rather than anything about the articles or the creation – like if we were to write down that "Mass creation applies to the creation of six or more articles per hour, except during a new moon, when the rate is lowered to one article per hour, unless you have reviewed five extra DYKs during the last 90 days, in which case the usual rate limits apply", and another rule that says "If someone claims mass creation when the creation rate is approved by this tool, then the first three editors who notice this are entitled to post 'Liar, liar, pants on fire' on the editor's talk page", then we won't have l-o-o-o-n-g discussions about whether creating two articles that I dislike is "mass creation" instead of "a violation of all that is right and decent".

However, given that I see editors who persist in claim "original research" for material that is both verifiable and cited, I am not convinced. Maybe if we give them another badname they'd switch to that eventually.

Paradise, the problem with "top 20" is that if editor #20 has created 1,000 articles ever, then:

• I can do whatever I want for the first 999 articles, including flooding the review queues with 999 articles in the space of 999 minutes, but
• if I create just one article per week, then after ~20 years, I'm going to have to get permission from the bot folks to do something that is obviously not bot-like editing.

You need to have a rate limit on it. WhatamIdoing (talk) 01:27, 23 March 2023 (UTC)

@WhatamIdoing, the Top 20 are only for 2022, not for the last 20 years. And also, Wikipedia can develop towards quality, as it happened in many areas of Wikipedia. I believe this development will also come to article creation but maybe I am just a bit ahead of time. Paradise Chronicle (talk) 07:01, 24 March 2023 (UTC)

Based on a rolling 12-month period or on the previous calendar year?

It doesn't make sense to tell someone that they were in the top 20 last time, so creating even one article now requires extra permission. And it might not make sense anyway, because what if I create hundreds or thousands of redirects, but someone expands those into real articles? Our tools detect that as being a real article (now), so it would count someone else's article creation "against" my limit, unless you did a manual review, which is not really helping.

And it doesn't address the practical problem with mass creation, which is flooding the review queues. It does not matter what the overall limit is, if you say I can do whatever I want for the first ____ articles, including flooding the review queues with ____ articles in the space of ____ minutes will always be a problem unless ____ is a sufficiently low number that the reviewers can handle the burst of activity (generally accepted as 25 to 50 per day). WhatamIdoing (talk) 18:34, 25 March 2023 (UTC)

Then let's turn it around. What kind of editor would have to apply at BRFA as suggested by MASSCREATE and MEATBOT? So far none seems to have applied for and none was given the rights even though they have created more than 25-50 articles per day or used semiautomated tools for their article creations. I have asked this already before but no answer so far. Paradise Chronicle (talk) 19:04, 25 March 2023 (UTC)

Paradise Chronicle, I think the rule should be that you apply at BRFA if your future plans will produce a level of articles that the community expects to cause problems for the Wikipedia:New pages patrol. That level has been set at 25 to 50 articles per day for many years. I would personally reduce it slightly, to say something like "25 to 50 articles per day day, or a total of more than 300 articles per month", but other editors would probably choose other numbers. WhatamIdoing (talk) 23:26, 28 March 2023 (UTC)

300 a month only one has created in 2022, so this would just raise the level instead of reducing it. I'd support a WP:MEATBOT approach that if articles are seemingly faster created than for example video link for the worlds fastest typists (ca. 200 words per minute) like creating several articles within a few minutes or 25 per day its considered semi-automated editing and worth of a review. It's not supposed to punish editors, but much more to regulate masscreation and show editors who like to masscreate articles what the community believes is good for wikipedia and what kind of editing raised concerns. Paradise Chronicle (talk) 21:56, 3 April 2023 (UTC)

The classification for Mass creation (in which 100 created articles in total are seen as a sign for masscreation) produced by BilledMammal is also interesting and has also not received much feedback either.Paradise Chronicle (talk) 22:05, 3 April 2023 (UTC)

In re this would just raise the level instead of reducing it: Does the number of articles that individuals are permitted to create actually need to be reduced? Are there still any editors who like to masscreate articles around? If not, why should we write down a rule to ban something that nobody is doing any more?

It's not sensible to say "More than a decade ago, Lugnuts created ~100,000 articles. I think his quality was poor, so I decree that editors who want to create one thousandth as many articles as him must get special written permission first." WhatamIdoing (talk) 18:08, 7 April 2023 (UTC)

Yes. I've been trying to compel them to request permission as required by WP:MASSCREATE, and in some cases I have been successful (with the result never being a consensus in favor of mass creation), but many ignore the requests. BilledMammal (talk) 18:11, 7 April 2023 (UTC)

MASSCREATE requires people to request permission for >50 articles per day. 100 per lifetime would be a substantial reduction from that.

@Paradise Chronicle, I see that you have created more than 300 articles. That is more than 100 in total. Are you a mass creator? Do you think that Wikipedia needs to be protected from you? Should you be getting special permission for every article you want to create in the future? WhatamIdoing (talk) 18:32, 7 April 2023 (UTC)

I wouldn't call me a mass creator in the current meaning. But I support the 100 article bar and would apply for permission if it came through. Paradise Chronicle (talk) 19:30, 7 April 2023 (UTC)

I want you to imagine yourself explaining Wikipedia's processes to someone in your real life, and saying something like this:

"I want to create one article this month. Now, if I were a new editor and didn't know what I was doing, I'd just click here and do it. But I'm experienced, so have to jump through bureaucratic hoops first. I'll have to write up a description, identify my planned sources, and get written permission. By the time you consider writing the request and all the people reading and replying, applying will take more time from the community than creating the article. Of course, a newcomer wouldn't like this; we only impose this on people who have experience with creating articles."

Do you think they would consider that to be sensible or silly? WhatamIdoing (talk) 04:41, 11 April 2023 (UTC)

Today, it only concerns editors who crossed the bar of 25-50 articles a day or used semi-automated tools for their article creation. The semi-automated is mainly mentioned since the 25-50 was ignored in the past. I do not believe the result of the Lugnuts and the Carlossuarez discussions is the one editors hoped for when they began editing. The Lugnuts articles were sourced well enough when they were created, but not anymore later. I believe the rules and guidelines will eventually get enforced, as it's not really informative to have heaps of unexplained, unsourced statistics and micro stubs of a few words or phrases. Paradise Chronicle (talk) 06:25, 11 April 2023 (UTC)

@Paradise Chronicle, I think you would hold a different view if you had been around back in the day. Please click this link and open, say, 10 tabs: nostalgia:Special:Random. That's what editors hoped for when they began editing. That's what they were doing. If you'd like to see some of the best, then try the equivalent of Featured Articles. Clicking through the first five, I see: one with ASCII art but no references; one with a general reference; two with suggested sources but no refs; and one with no sources mentioned at all.

If you're interested in learning more about the early days, then nostalgia:What Wikipedia is not might also be interesting. Also, if you see a page title that says /Talk at the end, that's what turned into talk pages. Before that (and even concurrently with it), editors just dumped their comments in the article page, at the bottom of the page. Namespaces weren't a thing back when Wikipedia was started. Talk pages were invented by Wikipedia.

And, more generally, when you think about saying I do not believe the result ... is the one editors hoped for when they began editing, you might want to pause and consider whether that statement should be re-written as I do not believe the result ... is the one I hoped for when I began editing. Since you started editing (your prior account) in 2018, you likely have a very different view of what's reasonable than the folks who were editing in 2003, or even in 2013. WhatamIdoing (talk) 20:21, 17 April 2023 (UTC)

Yeah, your reply sort of proves my point in a way that Wikipedia developed for the better. I do not believe you'll find consensus to go back to 2005 where "FAs" were able to be unsourced. In small wikis this is still possible but the English one is sort of a reference for the majority of the world which makes it one of the first hits on google and similar search engines all over the world. My suggestion is that Wikipedia develops further from quantity to quality but at the moment, consensus will not be found for that. And no, I meant what I wrote, and I believe you agree as well. Nor I, Lugnuts, Carlossuarez and the majority of other the editors partaking in the discussions were expecting that such a heap of poorly sourced content was able to exist and grow on Wikipedia when they began editing.Paradise Chronicle (talk) 18:16, 20 April 2023 (UTC)

It actually doesn't need to be reduced if the policies were enforced, but admins find any kind of excuses in order not to apply them. 25-50 a day most of the top 10 have created so far, very likely all use semiautomated processes. To apply for permission is not meant to ban masscreation, one can create 100 a day and for as long as they want, but please masscreate informative articles, not stubs with a few phrases or full of statistics.Paradise Chronicle (talk) 19:52, 7 April 2023 (UTC)

How frequently did the top 10 exceed 50 articles in one day?

(Note the NOTSTATS only bans "unexplained" stats.) WhatamIdoing (talk) 04:43, 11 April 2023 (UTC)

Why don't you ask for Semiautomated? I just believe that Wikipedia guidelines will develop towards quality instead of quantity as it did in the past. There would be also other policies that would apply, like WP:NOTMIRROR or WP:NOTPROMO for statistics mainly or only sourced to databases (not independent of the article subject). But I see the resistence of applying MASSCREATE and MEATBOT, so I guess its a matter of patience.Paradise Chronicle (talk) 07:37, 11 April 2023 (UTC)

Proving that someone exceeded 50 article creations on the same day is easy. Proving that they used an off-wiki tool requires either mind reading or intrusive surveillance, neither of which I'm good at. Consequently, I'm asking for the thing that really could be enforced (in software, if necessary). WhatamIdoing (talk) 20:23, 17 April 2023 (UTC)

Just came here to mention that a similar discussion was held here, where some standards were purposed for articles specific to the Dams. I think at the end, it boils down to the quality of article , not the quantity of article. Each project's articles should be discussed on the specific project group because you can find the concerned experts there and can decide on the quality, standards and overall assessment. After all one cannot be an expert in everything. Best regards!nirmal (talk) 02:11, 23 March 2023 (UTC)

My opinion is that the problem could be mitigated by banning the creation of stubs. If an article on a subject doesn't have at least, say, 250 words or an equivalent number of bytes then it doesn't belong in the encyclopedia. Maybe stubs should be relegated to the wiki dictionary or some other site. Smallchief (talk) 16:21, 24 March 2023 (UTC)

An encyclopaedic stub and a dictionary entry are not at all similar, and suggest you have a fundamental misunderstanding of the purposes of Wikipedia and/or Wiktionary. That does not lend favour to your proposal. Thryduulf (talk) 16:59, 24 March 2023 (UTC)

@Smallchief Great idea the one with the wiktionary. I have/had a similar idea. I thought that if one is not able to word out 10 phrases on a subject, it's not notable enough for wikipedia. As for me it's not enough to add a source, but also the information to the article that is in the source. Paradise Chronicle (talk) 17:43, 24 March 2023 (UTC)

Yes you are right. There @Nirmaljoshi was told not to create more stubs on dams but create Lists on dams in Japanese administrative divisions. Result? Nirmaljoshi created 19 stubs in 2 1/2 hours on the 1 March. That's the kind of discussions I'd like to prevent.Paradise Chronicle (talk) 17:54, 24 March 2023 (UTC)

No, there was not any clear outcome. Please read the discussion properly. Anyway, in the dam related article, one guy hijacked the process and I left on him to move forward.nirmal (talk) 01:28, 25 March 2023 (UTC)

I agree with you that there was no proper closure, but as to me the replies with the strongest arguments were the ones that supported List of Dams articles (comparable to the Lists of Dams in the USA). And your suggestion of a certain professional criteria per ICOLD is good as well, but not one of your dams created on the 1 of March I checked fulfills your own criteria of 1 Million Cubic capacity. Or maybe you can explain how lower numbers still fit in the ICOLD criteria?Paradise Chronicle (talk) 02:31, 25 March 2023 (UTC)

The top 20 article creators in that query generally have a volume of article creations (single digits of articles per day) that could easily be attained by someone hand-crafting and hand-typing individual articles rather than using any automation for these articles. That is not what MASSCREATE and MEATBOT are about. So this proposal seems to me to be missing the point. —David Eppstein (talk) 05:43, 11 April 2023 (UTC)

Little update, Esculenta was now blocked for one month for using AI for article creation per MEATBOT. I have actually asked them to apply for article creation at the BRFA in March but they didn't apply. They were blocked without my direct involvement in the discussions and I would have preferred for them to apply at the BRFA instead of being blocked. Paradise Chronicle (talk) 07:47, 23 April 2023 (UTC)

I’ve read the entire thread above a couple of times. My feeling is I’d rather wait till individual editors do something disruptive and then take action against them if it’s needed. I don’t think we need a policy to cover everything anyone might do, and I think long discussions about individuals’ editing, if they’re needed, are absolutely fine. Mccapra (talk) 08:23, 23 April 2023 (UTC)

Seems to me that the problem is best solved by demanding better quality from article creators. The solution is to have a policy that a newly created article must contain a minimum text of 200 words and be footnoted with at least one reliable source.Smallchief (talk) 11:16, 30 April 2023 (UTC)

I certainly would prefer a requirement for quality in new articles, and suggested one in the RfC on mass creation, but it was ignored. The community certainly seems to be focused on limiting quantity rather than requiring quality as an answer to dealing with mass creation of poorly sourced stubs. Donald Albury 13:06, 30 April 2023 (UTC)

Indeed, so many of these problems would be completely solved by requiring at least one piece of SIGCOV in SIRS for GNG-based articles to avoid draftification/userfication. Then we wouldn't even need the creator to actually write prose in the article. JoelleJay (talk) 16:57, 30 April 2023 (UTC)

Good idea. The main problem with these stubs is that they're hard to expand, and this would begin to address that — DFlhb (talk) 17:47, 30 April 2023 (UTC)

Proposed definition (MASSCREATE and MEATBOT)

As an initial draft I propose replacing the current text of WP:MASSCREATE with the following:

Any large-scale automated or semi-automated content page creation must be approved at Wikipedia:Bots/Requests for approval.

For the purpose of this policy the use of any tools that replace, in part or in whole, the manual work required to create an article will be considered automated or semi-automated creation. These tools include, but are not limited to, the following: For the purpose of this policy use any of the following tools will be considered automated or semi-automated creation. This list is not exhaustive and it is possible to engage in mass creation without the use of any of these tools.

• Large language models (eg. ChatGPT)
• Boilerplate text
• AutoWikiBrowser

When determining whether creations are done at a large scale only the cumulative number should be considered; the rate of creation is not relevant. There is no set definition of "large scale", although anything more than 25 or 50 is likely to be so. Creating articles without the use of tools, regardless of the scale or rate, is not considered mass creation, although WP:MEATBOT still applies.

All mass-created articles (except those not required to meet WP:GNG) must cite at least one source which would plausibly contribute to GNG, that is, which constitutes significant coverage in an independent reliable secondary source.

As defined this won't affect the average editor who is manually creating articles. Further, clarifying and enforcing the definition will benefit the community in two ways.

1. For mass creation that is constructive and that the community would approve of, it will provide an opportunity for the community to suggest modifications to produce better articles; it is easier to improve an entire set of mass created articles at the start of the process than it is to do so after the articles have been created.
2. For mass creation that is not constructive, such as the mass creation of geostubs by Carlossuarez46, it will allow the community to intervene before the scale of the problem becomes a significant burden on the community.

We consider the cumulative number, not the rate, because the issues mass creation can cause are related solely to the number of articles created, not the rate they are created at. It is possible for mass creation done at a low rate to result in greater issues than mass creation done at a high rate because detecting low rates of mass creation is more difficult and thus can result in a greater number of pages that the community must deal with. BilledMammal (talk) 09:20, 23 April 2023 (UTC)

There are multiple problems with this. Firstly, the rate of creation is relevant. If I create 51 articles in 365 days using one of those methods that would not cause anybody any problems at all yet would be prohibited by your definition, yet creating 1000 articles in 10 days without using "tools" might or might not be covered (see below) despite being likely problematic.

I say "might or might not" because the proposal is contradictory :

• Any large-scale automated or semi-automated content page creation must be approved and
• it is possible to engage in mass creation without the use of any of these tools., yet
• Creating articles without the use of tools, regardless of the scale or rate, is not considered mass creation.

The third bullet point contradicts the first two.

Finally, you seem to have ignored much of the discussion above regarding what is and isn't problematic. Thryduulf (talk) 09:37, 23 April 2023 (UTC)

The third bullet point doesn't contradict the first two. If you aren't using any tools then you aren't engaged in automated or semi-automated creation. However, I've reworded the second bullet point.

For manual large scale creation, like your example of 1000 articles in 10 days, I don't believe we can or should address it. I don't believe we should because the issues caused are different, and because we can address those issues under other policies - the community can easily handle an editor manually creating 1000 problematic articles in 10 days under WP:DE.

I don't believe we can because any attempt to do so will make it more likely that this policy will apply to editors who have the reasonable expectation that it won't because they are not using any tools in their editing; per the discussion above, which I haven't ignored, this is something that must be avoided.

If I create 51 articles in 365 days using one of those methods that would not cause anybody any problems at all yet would be prohibited by your definition It wouldn't be prohibited; it would just require you to go through BRFA, where approval should be quick if no issues exist. However, issues can exist for even smaller levels of mass creation. For example if you want to create 51 articles with ChatGPT I think community oversight would be a very good idea.

I also think that such an example would be extremely rare or even non-existent; how many editors engage in semi-automated or automated creation of articles but stop at 51 or a similarly small number? Do you have any examples? BilledMammal (talk) 10:12, 23 April 2023 (UTC)

Editors need to seek permission to upload files and create categories? I've seen some poorly thought out categorization schemes where I wish the editors creating the categories would have consulted somewhere about creating them. But requiring editors to seek permission to create more than 25 pages in their Wikipedia careers is ridiculous Are disambiguation pages and redirects included too? Plantdrew (talk) 16:31, 23 April 2023 (UTC)

That aspect is taken directly from the current WP:MASSCREATE policy. It also would only apply to automated or semi-automated activities; as most editors create categories and upload files manually it wouldn't apply to them. In line with the current policy, it wouldn't apply to redirects but it would apply to dab pages. BilledMammal (talk) 17:04, 23 April 2023 (UTC)

• Oppose due to the "rate doesn't matter" and inclusion of boilerplate text. — Rhododendrites ^talk \\ 14:15, 4 May 2023 (UTC)
• Oppose Boilerplate text is standard in most articles as they tend to have a common structure and phrasing. Templates are commonly created for the purpose and are used extensively. Andrew🐉(talk) 12:33, 6 May 2023 (UTC)

Alternative proposal: Move MASSCREATE out of BOTPOL

As I've looked at recent discussions around WP:MASSCREATE, I've become convinced that these are being hampered by that being a part of WP:Bot policy. It seems to me that the community wants to concern itself with mass creation in general, without regard for whether it's automated, semi-automated, or fully manual. WP:MEATBOT can help there, but that can only stretch so far—if you get to the point where "boilerplate text" might include Wikipedia:Manual of Style/Layout, you've probably gone too far.

Additionally, the bot policy can't legitimately say much about how non-bots should go about getting approval. MEATBOT is mainly about enforcement, not approval. In the recent RFC, a proposal to require BRFAs for mass-creation approval was rejected, and BAG does not seem to want it there either.

So how about it? Should the community move WP:MASSCREATE to some other policy, or to a policy page of its own? Mass creations by bot would still also be subject to WP:BOTPOL and WP:BRFA for the bot aspect, but the new policy would be freed from having to imply that all mass creations are somehow bot activity. Anomie⚔ 12:17, 23 April 2023 (UTC)

@Anomie Don't think it is big enough to be a stand alone policy, but it certainly doesn't need to be in BOTPOL (got somewhere else it could be merged?); botpol should reference wherever it ends up as a reminder to BAG/operators that bots that want to do that not only need to be approved as a bot, but ensure they have whatever community support is needed to exempt them from that policy. — xaosflux ^Talk 13:31, 23 April 2023 (UTC)

It might expand a bit once released from the constraint of being ostensibly about bots. But my main goal is to establish a consensus to move it out of BOTPOL since it really no longer fits there, where exactly it ends up I'm happy to leave to others to decide later. I agree that WP:Bot policy#Mass page creation should remain as a stub. Anomie⚔ 13:59, 23 April 2023 (UTC)

A layout guide can't be boilerplate text, but apart from that I think you make a good point - even if we decide to exclude fully manual mass creation from its scope it is better for MASSCREATE to be outside BOTPOL. We would need to replace the reference to BRFA; I think instructing editors to get community consensus at VPR would be a good replacement.

The best target I can see to merge it to would be Wikipedia:Editing policy, but I think it is better off as a standalone policy; it would be one of the shorter policies we have, but there are several of comparable or lesser length such as WP:IAR and WP:STRONGPASS. If it is made a standalone policy I think the best classification for it would be as a procedural policy; the same classification as BOTPOL. BilledMammal (talk) 13:50, 23 April 2023 (UTC)

• Oppose for the record. Huge change to the policy needs a formal RfC, but also there's not enough of a proposal here to explain what it would say when moved out of the bot policy. — Rhododendrites ^talk \\ 14:15, 4 May 2023 (UTC)
  • 🙄 Do you actually oppose the idea of moving it at all? Or are you just "opposing" because you want a 100% fleshed-out proposal instead of a check for whether it's worth the time making one? Anomie⚔ 01:19, 5 May 2023 (UTC)
    • Moving it isn't really what's happening (or not the meaningful part). This is completely redefining what "mass creation" is to include some as-yet undefined kind of mass creation that applies to totally manual editing. Simply moving it doesn't actually change anything, but changing the way it just talks about automated or semi-automated editing is, and that needs a fully fleshed out proposal. — Rhododendrites ^talk \\ 22:30, 5 May 2023 (UTC)
      • As far as I'm concerned, this proposal would indeed be satisfied by moving the existing text with zero changes to some other location. And I agree with you that actually making changes to the policy would require specific discussion about those changes. I disagree with your assertion that simply moving it wouldn't change anything: it would change the context, and that's exactly the point. "It's in the bot policy so it can only apply to bots" is in the way of those discussions, causing them (like the sections above) to have to try to stretch WP:MEATBOT to cover clearly non-bot edits and to somehow involve BRFA in the approval process for these not-actually-automated creations. Anomie⚔ 12:57, 6 May 2023 (UTC)

So I took a look at all the policies that User:Anomie has noted, and it seems to me that there should be a small subsection in Wikipedia:Editing policy which explains some basics about bot editing and about semi-automated editing (meatbot), and even WP:FAITACCOMPLI. Automated editing wasn't that big of a deal in Wikipedia's early days, but now we even have semi-automated editing options integrated into Wikipedia. I think we're doing a diservice to our editors if we don't at least point to where to find more information on these things, without relying on a bottom-of-the-page navbox. - jc37 13:35, 6 May 2023 (UTC)

Make Wikipedia:Verifiable but not false a guideline

There is no guideline that states that incorrect information should be removed. Wikipedia:Verifiable but not false is an explanatory essay. Some of us have been treating it (explicitly or implicitly) as if it were a guideline and removing or correcting incorrect information but in the absence of an actual policy or guideline it is merely an exercise of editorial judgment. (Although WP:BLP talks about "contentious" information, which is defined as "challenged or likely to be challenged", which is generally considered to include erroneous material.) This is not an RfC; as a preliminary I am surveying opinions on whether a proposal to elevate it to guideline status would receive support. Hawkeye7 (discuss) 00:04, 13 April 2023 (UTC)

The essay feels too redundant to be a guideline. I had not read it before now, and most of the principles feel like those that would naturally stem from existing guidelines and policies. For example, it is already uncool to make claims like those given in the essay (e.g. "All Americans think Hitler was evil") because those claims cannot be reliably sourced. The other principles are little more than restatements of WP:DUE, WP:NPOV, or WP:RSAGE. Orange Suede Sofa (talk) 00:30, 13 April 2023 (UTC)

While they may seem to stem naturally, the whole point is that we have no commitment to accuracy or correctness. WP:RSAGE is a case in point; we ignore it at MILHIST in favour of WP:FALSE. That is because of the problem of errors being propagated from one (otherwise) reliable source to the next. Hawkeye7 (discuss) 03:24, 13 April 2023 (UTC)

If this is elevated to a guideline, then what will change at MILHIST? If the problem is how an editor (or project) chooses to handle widely accepted guidelines, then address that directly. If it is not a problem, then we're all good here. If an existing guideline is a problem, then address that. BTW, with your note about no commitment to accuracy or correctness, I think you're getting at a much deeper philosophical problem that the existing policies and guidelines address: can we ever know what is accurate or correct? If not, we need a way to leverage the world's existing body of information to arrive at a largely consensual representation of a given subject, and I continue to believe that the existing policies and guidelines do that to the best of our ability. Orange Suede Sofa (talk) 22:45, 13 April 2023 (UTC)

What would change is that instead of edits being removed on the grounds that they are unsourced, undue or some other excuse, it will be explicitly stated that they are being removed because they are factually incorrect. Hawkeye7 (discuss) 02:02, 14 April 2023 (UTC)

How would an uninvolved editor be able to verify that the statement is factually incorrect? If there are sources that indicate that, why couldn't normal editorial judgment be followed? Orange Suede Sofa (talk) 02:14, 14 April 2023 (UTC)

This essay is not very well written. It's far too confusing as it stands to be elevated to be a guideline. I'd focus on improving the essay first. Jahaza (talk) 00:36, 13 April 2023 (UTC)

Let me know what you find confusing and what you think could be clarified on the talk page and I'll have a go at it. Hawkeye7 (discuss) 03:24, 13 April 2023 (UTC)

I do not think it provides anything not already in policies and guidelines. Certainly claims in sources can be removed if later sources contradict them or if we have information they are false. For example, that reliable sources show that some Americans adore Hitler disproves the claim that all Americans consider him to be evil. We could also counter with a source that said most Americans held this view.

This only becomes an issue in my experience when tendentious editors wiki-lawyer to include information they know to be false. For example, a secondary source may misstate what was said in a primary source. The solution is for editors to discuss in good faith. But if someone is determined to push their POV, more rules won't stop them. In fact, it can give them ammunition for wiki-lawyering.

TFD (talk) 00:56, 13 April 2023 (UTC)

The argument in these cases tends to be that while it is false, it meets our criteria for inclusion based upon widespread use in reliable sources. Hawkeye7 (discuss) 03:24, 13 April 2023 (UTC)

It would help to see a good example of an article that has information known to be false (not merely controversial) yet editors permit the information to stand. I am familiar with some BLP cases where someone claiming to be the subject says "my age is wrong" (or whatever) contrary to all available sources, but even those cases have an established path for resolution. Orange Suede Sofa (talk) 23:01, 13 April 2023 (UTC)

Yes, I have handled a case just like this. An athlete approached me and asked me to fix the incorrect date of birth on her article. To her, this was a big issue, because it was tantamount to an accusation of cheating. She showed me her passport and driver's licence as proof. Unfortunately, this ran afoul of WP:BLP, particularly WP:BLPPRIMARY, which says you are not allowed to use such sources. The origin of the error was easy enough to find: it was a simple typo, but one that had been spread widely by otherwise reliable sources that relied on the original erroneous but usually authoritative one. So what I did was invoke WP:IAR and elevate WP:FALSE over WP:BLP on the grounds that the latter does not improve the encyclopedia. I simply located a site that had the correct birth date and used that as the reference instead. Hawkeye7 (discuss) 01:18, 14 April 2023 (UTC)

This is super frustrating, yeah. Recent example I ran into was The Comfortable Chair -- pretty interesting band. (What's there in the article is a start, needs someone to go digging for the print sources.) Rob Fitzpatrick of The Guardian says Jim Morrison discovered them; he's a respected journalist and seems to be citing from aforementioned print sources. However, User:Midnight12 on the talk page, who says they are a member of the band, says this isn't true. Their contribs suggest that, at the very least, they're not a random drive-by poster. But obviously I have no way of actually verifying that they are who they say they are, or that they just weren't aware at the time. The best I could do was throw a "reportedly" into the copy since, if nothing else, it was reported. But obviously that's kind of a copout. Gnomingstuff (talk) 18:46, 14 April 2023 (UTC)

As to an article with false information that has been allowed to stand, consider Albert Kesselring, footnote 1. His birth date. Somewhere along the line, a typo crept into a source, and this erroneous information was repeated by several otherwise reliable sources. (The joke among military historians is that history doesn't repeat itself nearly as often as historians do.) A long debate followed with other editors who felt strongly that the article should acknowledge both the correct and the incorrect dates since WP:FALSE is only an essay and we should adopt a neutral point of view on matters of fact. I did not believe that having two birth dates, one which we knew to be incorrect, would benefit the readers in any way. The footnote represents the resulting compromise. "Albrecht" as a first name derives from Kenneth Macksey, who erroneously believed that it was the German form of "Albert". Again, the error has been propagated to other sources. Kirsten von Lingen wrote that this was "plain wrong", but another editor felt that saying so was non-neutral, so that comment was removed. Hawkeye7 (discuss) 01:18, 14 April 2023 (UTC)

I had a related experience in a death discussion about about Marilyn Monroe's sister Berniece Baker Miracle. As an aside, the Monroe page itself is a remarkable and featured work; related pages get special scrutiny, and rightly so. Based on less-than-reliable sources the BLP subject had died, but the only source we could present was Find-a-grave (with several photographs of her gravestone). This went on for some months and put Wikipedia in the awkward but never unique situation of hosting outdated, incorrect and potentially damaging information about a BLP. BusterD (talk) 08:57, 18 April 2023 (UTC)

Editorial discretion along current guidelines seems better for such cases. Any guideline about truth is bait for RGW-style arguments, and we say verifiability not truth precisely to avoid those pointless quagmires. We can use editorial discretion to value more recent sources over older ones because they are more likely to be in line with what is currently accepted as correct knowledge, but that doesn't mean what we have is definitely true. CMD (talk) 03:44, 13 April 2023 (UTC)

"That statement has been viewed as claiming Wikipedia is, somehow, not concerned with truth." -- Is there really a critical mass of people saying this in good faith? If not, what's the issue? Gnomingstuff (talk) 07:46, 13 April 2023 (UTC)

A very, very, very good essay. Minor grips over wording, but it's vital. For example, recently, I found one book that said Steve Wozniak used 45 chips on a circuit board; another book said 42 (a magazine said 44...) Then I found a Woz interview where he says: I got it down to 42, but it went back to 45 before it ran well. I could have just flipped a coin and picked a number, but now the discrepancy has been resolved.

Secondary sources routinely publish errors; citogenesis proves that. We've run into peer-reviewed papers and scholarly books that saw uncited crap on Wikipedia, and repeated it as fact! The whole point of WP:NOTTRUTH was to dumb-down WP:OR so even fringe-pushers can understand it. But we have a huge audience, and it would be irresponsible to punt the accuracy question to our sources, without exercising nuanced editorial judgment. Bad-faith editors can misuse WP:FALSE, but they can misuse anything. Tracking down and reconciling potential factual mistakes in source is what any responsible, thoughtful editor "should" do, and "should's" are what guidelines are for. DFlhb (talk) 01:07, 14 April 2023 (UTC)

Right now we basically have three categories of this type of thing. Policies and guidelines (which in shorthand are sort of "rules") and then thousands of essays which anybody can get lost in and usually remain obscure unless they have a short catchy name to link to within sentences. We need another category of highly exclusive highly vetted pages. Some will be guiding principles, too general to be specifically invoked in disputes (as guidelines and policies are) . I think that this would contain things like 5 Pillars and this proposal. The other group would be highly vetted explanatory essays that describe how Wikipedia is and operates. North8000 (talk) 19:33, 14 April 2023 (UTC)

I agree there needs to be a level between "guideline" and "essay", because "essay" at this point can either mean "this is so frequently referenced it's effectively a guideline" (e.g. WP:BLUESKY) or it can mean "this is one editor's opinion" (e.g. Wikipedia:Avoid negative claims) or it can mean anything in between (e.g. WP:POSA, which by the very fact it can find so many examples clearly has not achieved wiki-wide consensus). Loki (talk) 23:51, 14 April 2023 (UTC)

Good points, but they point to more fundamental changes needed. Your essay is a good start in some of those areas. In cases where objective accuracy exists, we need to modify folklore to say that wp:ver is a means to that end, not the end. The other folklore that we need to get rid of is that editorial judgement (within the guardrails) (e.g. to resolve dilemmas like you describe) is illegitimate or banned in Wikipedia. Finally we need to establish that source reliability is context-specific, that it relates to objectivity and expertise with respect to the text which cited it. Sincerely, North8000 (talk) 13:52, 14 April 2023 (UTC)

Someone asked above for examples of articles where information was verifiable but false; I can provide a couple:

• A source says Fallon Fox had surgery at "Bangkok National Hospital", but if you look for more information about that hospital, most of what you'll find is about Fox (parroting that initial source) or else unreliable miscellany, because AFAICT Bangkok National Hospital doesn't exist: the original source apparently made a mistaken assumption about what the full name of the national hospital in Bangkok that's called "BNH" is — the hospital is actually named Bangkok Nursing Home hospital. In that case, after another editor raised the issue on talk, I changed the article to just say "a hospital in Bangkok" since this is verifiable and the exact hospital name is unimportant trivia, but no reliable sources have the correct name. (Possibly even the detail that Fox had surgery in Thailand is removable trivia, but that's a separate issue.)
• Qasem Soleimani's article faced at least two such issues: some reliable sources said he was the first person in Iran honored with a multi-city funeral (but this is false, since other notable people were previously honored with multi-city funerals as discussed in other RS, but these other RS predate and weren't about Soleimani, so technically might be WP:SYNTH), so editorial discretion was used to drop that claim. And one US intelligence source said he was born in Qoms province, but other RS say he was born in Kerman province; he lived his early life in Kerman, and when he was buried in his birthplace, that was Kerman province, so I downgraded "Qoms" to a footnote, but the idea that he might've been born in Qoms still made its way citogenetically into some later news articles, so it might be better to just drop the wrong information.

I sympathize with the idea that it would be useful to have a note somewhere explicitly stating that Wikipedia strives to be accurate. But I share the concern expressed above that making an explicit guideline or policy besides WP:V would encourage edit wars ("sure, RS all say Trump / Xi / Kim Jong Un / Qanon / etc did X, but I know it's not true so I'm removing it per NOTFALSE!!"). -sche (talk) 22:22, 15 April 2023 (UTC)

I understand this concern, but the point is that in removing information simply because it is false, you are indeed removing it per WP:NOTFALSE! This is acting although WP:NOTFALSE already has guideline status. Hawkeye7 (discuss) 19:32, 16 April 2023 (UTC)

It's permissible to remove information simply because it's false, and if we have a rule that says otherwise, then that rule needs fixing.

About a dozen years ago I fought tooth and nail to get "verifiability, not truth" removed from policy because it's important that we try to tell the truth. I also think that we block and ban people who lie. Oh sure, we have all these fig leaves about consensus and pretexts involving disruptive behaviour and advocacy and POV-pushing, but actually, underneath it all, there's a real distinction between people who're here to educate and inform on the one hand, and people who're here to propagandise, advertise and misinform on the other.—S Marshall T/C 08:10, 17 April 2023 (UTC)

The problem is that one person's "truth" may be another person's "lie". How then are we to determine that content that someone wants to remove because they say it is false is indeed false? If there is no citation to a reliable source, such content can be removed. But, if we allow someone to remove content that is supported by a citation to a reliable source because they say it is false, how do we know that it is indeed false, and not just a mistaken opinion of the editor who wants the content removed? That is why I supported "verifiability, not truth", because, all too often, "truth" is in the eye of the beholder. Donald Albury 13:18, 17 April 2023 (UTC)

Oppose doing so. It's a fine essay. I see no reason it needs to be a guideline. --Jayron32 14:18, 17 April 2023 (UTC)

Oppose. "Verifiability, not truth" is a powerful statement. It's the secret to avoiding a constant high-temperature flame war and has the not inconsiderable benefit of actually being better for favoring true content over false content, and honestly should be placed back on WP:V in big bold letters. Anyway, given that Wikipedia:Verifiability, not truth is technically only an essay at the moment, it only seems reasonable that this kind of essay have the same status. Obviously, the truth is important, but the kind of stance suggested by NOTFALSE just gives a big bludgeon to the worst cranks & POV-peddlers who want to argue about whether their fringe theory is true or not. VNT refocuses the debate onto "fine, whatever, let's say it's true, who's actually published it in the mainstream. Nobody? I guess we can't have that on Wikipedia yet." The actually good faith editors interested in truth can work fine under both a VNT and a NOTFALSE system, but the fringe theorists tend to be deterred better by VNT and encouraged by something like NOTFALSE. SnowFire (talk) 05:49, 18 April 2023 (UTC)

VNT was deliberately removed from wp:ver after a gigantic RFC. Actually two gigantic RFC's with the same result. North8000 (talk) 19:23, 18 April 2023 (UTC)

I'm familiar, yes. It was a mistake. SnowFire (talk) 04:04, 19 April 2023 (UTC)

Oppose. SnowFire says it better than I could. "True" and "False" are both loaded and subjective terms that get in the way of writing a verifiable encyclopaedia. Thryduulf (talk) 10:42, 18 April 2023 (UTC)

Oppose. Don't try to ground rationales in underlying "truth". It's a problem. Truthwarriors often know full well that the article matches the sources, they want to push their POV in articles by ranting that the sources are biased or wrong. I have successfully brought peace to some of these hellholes by firmly explaining Wikipedia policy requires our content to be an accurate summary of what Reliable Sources say, explaining that they need to find sources to back up their claims, explaining that their truth-arguments simply do not work here, explaining that under policy we are required to ignore their truth-arguments.
We have abundant methods for keeping bad content out. One often noted method is simple editorial discretion to leave out anything we consider not useful to the reader. An often overlooked point is that a "generally reliable" source does not imply reliability for every individual claim in that source. Even the best sources apply a lower standard of care to minor incidental details, and available evidence can be considered when evaluating the care applied on that specific point. Something that appears to be a typo or simple mistake fails our Reliability standard, regardless of whether it's "true". Alsee (talk) 07:28, 21 April 2023 (UTC)

blocked user evading block--Jayron32 17:14, 16 May 2023 (UTC)
The following discussion has been closed. Please do not modify it.
See also WP:Village pump (policy)#Add_public_on‑chain_activity_to_WP:RS with code is law for an example, where self mathematical verifibility when linked to WP:OR means articles should remain provably wrong (some statements made by the article can be quicly proved wrong but use of the source fall in WP:OR because being published on the ledger doesn t equal what is published in a book or on the web) . 37.170.88.2 (talk) 13:15, 16 May 2023 (UTC) This makes no more sense than when you wrote similar gibberish in that now closed discussion. --Jayron32 16:43, 16 May 2023 (UTC)

• This is where “Verifiability does not guarantee inclusion” is so useful. It may take some discussion to achieve consensus, but we absolutely CAN omit verifiable information that we agree is false. What we can NOT do is replace that false information with unverifiable information we think is true. Blueboar (talk) 14:31, 16 May 2023 (UTC)

Discussion

There is no Nutshell summary. Without that, I'd oppose as well. A quick reading gave me the impression, the whole essay was a bit vague and vague policies are not what we want.Paradise Chronicle (talk) 18:04, 4 May 2023 (UTC)

RfC on a procedural community desysop

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

---

Although rare, there are situations where the community has consensus that an administrator should be blocked indefinitely, or at least for a significant period. In those circumstances, this proposal suggests that administrators who have been blocked for more than 28 days do not hold the trust of the community and therefore the sysop userright should be removed procedurally alongside inactivity desysops. Worm^TT(talk) 14:05, 17 April 2023 (UTC)

Proposal: Procedural community desysop

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

---

The following section should be added to WP:Administrators

Procedural removal

On the first day of the month, any administrator who is blocked and has been blocked for more than 28 days will have their administrator user-right procedurally removed (alongside inactivity removals). Administrators who have their sysop user right removed in this manner are not eligible to simply request return at the bureaucrats' noticeboard, but may appeal the removal to the Arbitration Committee. The administrator may regain their administrative permissions through a successful request for adminship.

Survey (Proposal: Procedural community desysop)

• Support as proposer. Recent events have brought home to me that we are still lacking in ways to handle poor behaviour by administrators. I believe that as a community, we have consensus that an indefinitely / long term blocked administrator does not hold the trust of the community. However, in those situations, the only place to remove the toolkit is Arbcom (or waiting 12 months). I see no reason why such a removal shouldn't happen more quickly, and no reason that Arbcom needs to be involved if it does.
  Instead, I'm suggesting that we have a 1 month period, which allows for cooling off, then removal as part of the next automatic removals, no request necessary, no fuss, no mess. Worm^TT(talk) 14:05, 17 April 2023 (UTC)
• Support I'm speaking as an admin here. If my conduct as an editor warranted any sort of long term block of a month or so, I should not be trusted with the admin tools any longer. RickinBaltimore (talk) 14:15, 17 April 2023 (UTC)

  The reasoning here sounds straightforward to me. It seems rather easy to become an Admin these days, based on some of the pro/con discussion I have seen this year regarding length and depth of candidate editing experience. So, I can certainly understand some people getting carried away and behaving "poorly". Martindo (talk) 06:48, 26 April 2023 (UTC)

• Oppose Pointless. A blocked admin can't (since 2018) unblock themselves, and if they're blocked indefinitely, they'll just be auto-de-adminned when the time comes around. I find it difficult to think of a situation where this process would be useful. --Jayron32 14:17, 17 April 2023 (UTC)

  Actually, editing their own talk page would be enough to forestall the annual edit requirement. Courcelles (talk) 13:33, 18 April 2023 (UTC)

• Support with revisions to clarify "blocked". In exceptional circumstances we might pblock a sysop from a small number of pages but still want them to continue as a sysop -- I feel that "blocked" in this case should mean "blocked from the entire mainspace".—S Marshall T/C 14:20, 17 April 2023 (UTC)

  I'm having a hard time picturing under what circumstances we might want to pblock somebody yet still trust them enough to hold a mop. -- RoySmith (talk) 14:33, 17 April 2023 (UTC)

  People could want to have a pblock? —Kusma (talk) 17:06, 17 April 2023 (UTC)

  The community has rejected the idea of an admin being desysoped due to a partial ban. Don't see why a single page block should be any stronger in this context. Animal lover |666| 20:05, 17 April 2023 (UTC)

  Only sitewide block should be considered for the removal of administrators. Thingofme (talk) 14:09, 18 April 2023 (UTC)

• Weak support. The choice to only desysop on the first of the month concerns me as it could lead to some controversial situations; an admin blocked for 50 days on the 5th of March will remain an admin, while an admin blocked for 30 days on the 2nd of March will not. I find it hard to justify this, as for blocks of under two months whether an admin remains an admin becomes random chance. However, this isn't enough for me to oppose this proposal as I believe it is important to have a process to address situations where admins have so clearly lost the trust of the community. BilledMammal (talk) 14:21, 17 April 2023 (UTC)

  It appears to me from Worm That Turned's vote that it would happen during the normal automatic removals, I'm assuming that means the others happen on the first of the month, so no need to create extra work. But you have a good sentiment Happy Editing--IAmChaos 16:44, 17 April 2023 (UTC)

  That was my guess. Can someone confirm it would actually work the same way via software? Martindo (talk) 06:44, 26 April 2023 (UTC)

• Support in principle but Oppose in its current form. I don't get why this needs to be tied to a specific day on the calendar. But more than that, it allows for stealth desysops. Let's say I block bradv. He's been inactive for 9 months, so he's not going to notice. If nobody else happens to notice, come June 1st, he'll get desysopped. I assume that's not your intent, but as written, it's what would happen. This could be fixed by adding a requirement that in addition to blocking brad, I would have to post a notice to WP:AN to start the clock ticking. Then it essentially becomes WP:PROD for admins. -- RoySmith (talk) 14:32, 17 April 2023 (UTC)

  OK, it's been demonstrated to me that blocks do show up on watchlists, and I'm sure every admin's talk page is watchlisted by lots of people, so that satisfies my concern about stealth blocks. I still don't get why this needs to be tied to a specific day on the calendar (and if it must be, at least make it the ides) but that's not enough to me to oppose. -- RoySmith (talk) 15:07, 17 April 2023 (UTC)

  Interestingly, I did consider putting together a proposal about blocking administrators as part of this, which included a notice to AN. But I didn't feel it was necessary. That said, I really don't like the idea that administrators get an automatic AN review if blocked, creating a "class structure" - we already have supermario issues, which is something I'm trying to address.

  If you are concerned about blocking inactive admins, well, yes, it's possible, but most admins userpage's are watchlisted by multiple people - a stealth block would be noticed. Even if it wasn't, this is something that the appeals process would be quick to fix. Worm^TT(talk) 14:46, 17 April 2023 (UTC)

  Does watching somebody's user page generate a watchlist notice? Normally, a block is accompanied by a talk page notice, but it doesn't have to be. Could you please block User:RoySmith-testing without any explicit notice? I'm watching their user page. Let's see if I get a notice. -- RoySmith (talk) 14:53, 17 April 2023 (UTC)

  It does show up on watchlists. To show this, I have just pblocked your test account for 3 hours. Best, Barkeep49 (talk) 14:57, 17 April 2023 (UTC)

  Yeah, I got:

  × Block log 14:57:29 Barkeep49 talk contribs block changed block settings for RoySmith-testing talk contribs blocking the page User:RoySmith/Three best sources with an expiration time of 2023-04-17T17:56:33 (autoblock disabled) ‎(requested for testing purposes by User:RoySmith) (unblock | change block)

  I'm actually kind of surprised about that, but, OK. -- RoySmith (talk) 15:02, 17 April 2023 (UTC)

• Oppose in this form. (a) it isn't clear that 28 days is enough for a good-faith unblock request in complicated cases and we shouldn't let stalling an unblock turn into a desysop (b) why not just escalate to ArbCom after the 28 days? (c) would any block trigger this? —Kusma (talk) 14:38, 17 April 2023 (UTC)

  I also note that no discussion is required, meaning that the mechanism is - in theory - not implementing a "community desysop" but a "single admin PROD-like desysop". I know that this will likely play out differently in practice, but there should be safeguards against the proposed mechanism. —Kusma (talk) 15:09, 17 April 2023 (UTC)

• Support If editor has been blocked for more than a month, especially if that block gets confirmed by the community which I suspect it would in a majority of these cases, they shouldn't be an admin anymore. This is true even if the block is for less than an indef or a year, to address Jayron's question about why not wait for the current inactivity to desysop. I see this as an important way for the community to take some control over the deysop practice, something I have long favored. The presence of this in policy would be an important way of combatting the super mario effect as there is now some incentive for an admin to block, as they would anyone else, an admin who has breached policy rather than just go "well it's for arbcom to sort out". As to the idea that it takes someone longer than 28 days to formulate an appeal, they can still appeal the decision: by re-running for RfA. If the community wants to be able to handle some desysops on its own, and it's my fervernt hope that it does, then we need to stop letting the perfect be the enemy of the good and support reasonable proposals like this as first steps towards building community capacity around merit based desysops and showing concerned editors that the community can handle these issues, not just arbcom. Best, Barkeep49 (talk) 14:55, 17 April 2023 (UTC)
• Support - I'm not quite sure why it's necessary to wait for 28 days. If we're going to go in this direction, then it seems to me that a CBAN of an admin should carry with it an automatic immediate desysop, which, after all, can always be undone if necessary - but, that being said, this proposal is certainly better than the situation we have now, where there's absolutely no way for the community to desysop an admin (despite the fact that it's the community which creates the admin in the first place, via RfA). Beyond My Ken (talk) 15:06, 17 April 2023 (UTC)

• Remove support in favor of Tony Ballioni's proposal below. Beyond My Ken (talk) 09:11, 20 April 2023 (UTC)

• In the proposal, admins can desysop other admins. There is no community element. —Kusma (talk) 15:18, 17 April 2023 (UTC)

  I don't agree. A block of an admin would be reviewed by the community. It wouldn't happen based on a single admin's view - or rather, it wouldn't stick for over a month based on a single admins view. Worm^TT(talk) 15:20, 17 April 2023 (UTC)

  Only admins can initiate the desysop review by blocking. The community can't initiate this. —Kusma (talk) 15:53, 17 April 2023 (UTC)

  Admins are part of the community - what's more, if you have a consensus of non-admins at say, WP:AN, we can be confident that an admin would implement it. The only way this works is with consensus, and with our current practises. Worm^TT(talk) 15:56, 17 April 2023 (UTC)

  I am rather uncomfortable with how many implicit assumptions about the functioning of the community and the current practises are part of this proposal. —Kusma (talk) 16:42, 17 April 2023 (UTC)

  +1 - it seems unclear to me why a community desysop process does not actually require the community to weigh in, and only assumes that it will. Galobtter (talk) 19:03, 17 April 2023 (UTC)

• Oppose If we wish to devise a procedure for community-instituted de-sysop, we should devise a procedure for community-instituted de-sysop (with appropriate safeguards). The proposed process will only mean that editors will be encouraged to !vote at for a month or longer block at WP:AN when they believe that the admin should be de-sysoped (irrespective of whether they believe that a block itself is necessary) since that is the only procedural loophole they have been granted to achieve the desired end. Why introduce such a de-sysoping through wink-and-a-nod process? Abecedare (talk) 15:08, 17 April 2023 (UTC)

  All editors have safeguards if they are wrongly blocked or they wrongly lose a permission. I do not believe administrators should get extra safeguards and I do not believe that someone who has had conduct worth a 28+ day block fulfills the administrator conduct policy and thus should not be an admin. Best, Barkeep49 (talk) 15:12, 17 April 2023 (UTC)

  Sorry, if I was not clear enough. My argument is not that admins with long blocks should not be desysoped (frankly, I can't imagine a scenario, except for self-requested blocks, when they shouldn't be) or that admins need extra-safeguards from being blocked (they don't!). My objection is that a >28-day block should not be a necessary intermediate step for a community-instituted desysop. If the community wishes to desyspo an admin they should !vote for it explicitly rather than be forced/encouraged to !vote for a > 28-day block with the understanding that such a block would eventually lead to the desired end, i.e., a desysop. (I think I may be repeating myself, so if you or anyone wishes to discuss this separately we can do so at my talk-page w/o taking too much space here.) Abecedare (talk) 15:31, 17 April 2023 (UTC)

  @Abecedare I would absolutely support a direct community desysop proposal, but as yet, we have not found one that can gain consensus (even though mor than one have had majority support). I am not sure that opposing something you agree with because you see a potential something tangentially better is a good idea though. Is that not the definition of perfection getting in the way of good? Worm^TT(talk) 15:52, 17 April 2023 (UTC)

• Support I'm an admin. I got blocked. A lot of people asked me to appeal, so I did, apologising for bad conduct (I was going through a horrible time in my personal life, leading me to lash out completely unnecessarily in complete violation of WP:ADMINCOND) and I was unblocked, easily within a week. If you can't successfully file an appeal within 28 days, you probably shouldn't be an admin. Ritchie333 ^{(talk) (cont)} 15:23, 17 April 2023 (UTC)
• Support I had a completely different comment, but Ritchie333 edit conflicted me and changed my mind. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:28, 17 April 2023 (UTC)

  I did also misunderstand on first reading, thinking that having a block imposed of 28 days or more triggered the desysop, rather than still being blocked after 28 days. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 15:32, 17 April 2023 (UTC)

• Support. Although I think this proposal does not go far enough. In practice this sounds similar to a community admin de-sysop process in two steps (Admins getting blocked - 28 day period for the procedural desysop) and I would like more discussion on a robust system based around considering it as a single process (but presumably higher thresholds to implement). That discussion does not have to be now or on this survey, but I think more community power to desysop admins is a good thing. Soni (talk) 15:31, 17 April 2023 (UTC)
• Oppose. If a desysop is needed, do it via ArbCom. That's what it's there for. Seraphimblade ^{Talk to me} 15:34, 17 April 2023 (UTC)
• Comment Also @Worm That Turned: maybe this should be listed on WP:CENT or similar. Soni (talk) 15:33, 17 April 2023 (UTC)

  It's already been on CENT :). Best, Barkeep49 (talk) 15:44, 17 April 2023 (UTC)

  Ah, I see how I missed it. I forgot links are marked as "read" on my browser if I follow it from anywhere, not just from CENT specifically. Thanks for clarifying. Soni (talk) 15:50, 17 April 2023 (UTC)

• Support per Ritchie333. I agree that it's a fair assumption that if an admin stays blocked for 4 weeks then they don't have the community's trust. —pythoncoder (talk | contribs) 15:57, 17 April 2023 (UTC)
• Oppose. This proposal reminds me of the one linking desysops with community restrictions, which resulted in a clear consensus against.
  Despite the supporters' best intentions, this worsens the "unblockable" and "Super Mario" effects, given that the proposed policy increases the consequences of blocking an administrator and further discourages it. If the proposal prevents even one administrator from being blocked when they should be, then it is not worth it: administrators must be held accountable for their actions. We elect the Arbitration Committee so that it can handle requests for removal of administrative tools. That grave responsibility should not be borne by a single editor.
  When Special:Block is opened, one needs to be convinced that imminent or continuing damage and disruption to Wikipedia will be prevented. That is the main concern. That decision-making process, which is already clouded by the fact that a user with social capital is being blocked, should not be impaired by secondary questions over whether an administrator is fit to continue holding that access.
  Administrators must be held accountable. But this is not the answer. Sdrqaz (talk) 16:18, 17 April 2023 (UTC)

Not sure I agree with you on the top line but I really appreciate your well reasoned and concise argument. I think its so important that people look beyond just the question in front of us and try to fit the current proposal into the big picture. Horse Eye's Back (talk) 16:43, 17 April 2023 (UTC)

• (edit conflict) Oppose This proposal allows admins to near-unilaterally desysop another one, unless a review of the block is brought up at AN/I which won't always happen even if a block is controversial. It also makes blocks of an admin greater than 28 days unnecessarily more contentious. I am willing to support a method for the community to desysop an admin, but it should unconditionally require community discussion. Snowmanonahoe (talk) 16:21, 17 April 2023 (UTC)

  Any admin who is blocked is able to make an unblock request and ask for a community review. I think 28 days is plenty long enough for them to do that. Boing! said Zebedee (talk) 16:31, 17 April 2023 (UTC)

  Currently, a blocked admin would be subject to a standard block review. With this proposal, they will be subject to a community desysop review, a very different beast for which there is no precedent. It is quite a new ability for any single admin to initiate a community desysop review. —Kusma (talk) 16:47, 17 April 2023 (UTC)

• Question - Does anyone have a number for how many times an admin has been blocked >28 days and arbcom hasn't quickly and easily stepped in to remove permissions? Seems like a reasonable proposal, but has it ever been needed? — Rhododendrites ^talk \\ 16:23, 17 April 2023 (UTC)

  This feels a bit like a chicken and the egg. Recently, for instance, Athaenara could have been desysopped under this proposal rather than the arbcom motion which happened. One virtue of this proposal, which I didn't mention above, is that I think it would save some time and community drama - even an ArbCom case request is high on both. Barkeep49 (talk) 16:44, 17 April 2023 (UTC)

  I reviewed the list of current admins; the only one who this would have affected would be Smartse, who was blocked for 78 days per their own request to enforce a wikibreak. BilledMammal (talk) 18:23, 17 April 2023 (UTC)

  @BilledMammal: Not true. Per my research using a PHP script making API queries, Randykitty self-blocked in 2018 for 85.3 days (relevant contribution history). That's the longest block tor a current administrator, assuming my algorithm is correct. – wbm1058 (talk) 20:12, 7 May 2023 (UTC)

  ...and Spartaz was blocked for 79 days in 2018 as well, per their request. – wbm1058 (talk) 21:22, 7 May 2023 (UTC)

  That was before my RfA. SmartSE (talk) 18:31, 17 April 2023 (UTC)

  But raises the question of whether it's sensible to de-sysop for requesting a wikibreak. Imagine someone on a military deployment: "Thank you for requesting that your account be blocked while you know you won't be able to use it. By the way, we're going to de-sysop you." Thank you for your service, indeed. WhatamIdoing (talk) 21:06, 17 April 2023 (UTC)

  I'm unsure as to whether to support the proposal as a whole, but it would need an exemption for an admin in good standing who requested to be blocked. Certes (talk) 10:01, 25 April 2023 (UTC)

  ...especially as an adept wikilawyer would sidestep this measure by resigning their adminship before requesting a block, then re-request sysop when they return. Certes (talk) 10:07, 25 April 2023 (UTC)

  Part of me wants to support this as a sorta-kinda community desysop process. Rather than "should this person be desysopped" it's "should this person be blocked for exactly 29 days? wink wink what I mean?" My concerns are (a) that the illusion of a community desysop process will lead arbcom to defer to the community for some cases, when it seems like arbcom is doing alright with the extreme cases already (such as those requiring a long block); (b) I'm not sure why it would reduce drama. Anytime someone with a lot of experience gets blocked for one day (nevermind a month or more), it leads to a ton of drama. It's the block more than the desysop, right?; (c) Isn't this easy enough to handle on a case-by-case basis? A desysop can be carried out by arbcom motion, and that should be relatively straightforward in the case of someone blocked for a month. On the other hand, requiring an action by arbcom means there's room for judgment to handle exceptional cases like a requested block. Not sure. — Rhododendrites ^talk \\ 12:51, 19 April 2023 (UTC)

• Support. If an admin is indef/long-term blocked and has been so for more than 28 days, I don't think it could be read in any other way than they've lost the trust of the community. An ArbCom request in such a case would be little more than a rubber stamp (as I can't see ArbCom reversing such a strong community action), so this would really just save time and effort for the same ultimate result. Boing! said Zebedee (talk) 16:26, 17 April 2023 (UTC)

  @Boing! said Zebedee Or maybe they just needed a break or they rage quit? I'm not meaning to call you out on those (nor do I need to know the details), but we should consider if those events should have resulted in the loss of your mop. -- RoySmith (talk) 14:53, 19 April 2023 (UTC)

  Voluntary relinquishment due to taking a break or leaving Wikipedia would still allow for requesting privileges to be re-granted without a request for administrative privileges, within the bounds of the activity requirements. isaacl (talk) 15:39, 19 April 2023 (UTC)

• Support. The community appoints admins. If it can be trusted to do that, it can be trusted to remove them. The proposed conditions under which this would occur seem entirely reasonable. AndyTheGrump (talk) 16:50, 17 April 2023 (UTC)

  The community has been doing an absolutely terrible job at appointing admins (extremely conservative and unforgiving of small mistakes). —Kusma (talk) 16:58, 17 April 2023 (UTC)

  I think that's true, yes. But I wonder if it's another side of the same thing - if theres no community way to get rid of an admin, does it make people at RfA a lot more cautious and demanding? (I really don't know, just pondering out loud.) Boing! said Zebedee (talk) 18:20, 17 April 2023 (UTC)

  We've had years of people clamouring against "admins for life" and we have recently made it harder to retain admin status, offending a few low-activity oldtimer admins. It doesn't seem to have made people less cautious. I don't think admin-PROD is going to make any difference to RfA either. —Kusma (talk) 20:34, 17 April 2023 (UTC)

  Hmm, yes, I think you're probably right - maybe the creeping intolerance at RfA simply goes hand in hand with general rule creep across the project. Boing! said Zebedee (talk) 07:09, 18 April 2023 (UTC)

• Support If an admin needs to b e blocked, and the block sticks, they are obviously unfit to be an admin. We don't need a month-long committee case to make decisions this obvious. Beeblebrox (talk) 17:00, 17 April 2023 (UTC)
• Support - this accounts for appeals happening and so on, so is fine. For the sake of clarity, this can be taken to oppose any alternate standard that might be picked out from this discussion (obviously I'll amend if I see a good one, just to avoid missing a discussion). Nosebagbear (talk) 17:01, 17 April 2023 (UTC) Since we have broken out new ideas as they arise, !vote adjusted to just this one. Nosebagbear (talk) 14:58, 24 April 2023 (UTC)
• Hesitant support. I have several concerns here. First, that this will raise the stakes for blocking an admin, which is already hard enough: but we don't do it very often, so perhaps it's not a concern. Second, per Abecedare above, that we're not going far enough; but I don't want to let the perfect be the enemy of the good either. Finally I'm concerned that the ARBCOM appeal clause defangs this proposal. If the intention is that a full ARBCOM case should not be necessary step to a desysop, we're making it to easy for this to end up in ARBCOM's lap anyway. I suppose the burden is shifted from the community to the admin, so perhaps it's a shift for the better; but I'm unconvinced this is going to be a big change in that respect. Ultimately, though, yes, an admin blocked for more than 28 days should likely be desysopped. So I land here. Vanamonde (Talk) 17:35, 17 April 2023 (UTC)
• Support - (another admin here). I think Wugapodes and Beeblebrox have explained why. - Donald Albury 17:46, 17 April 2023 (UTC)
• Support. I'm a bit worried that this will incentivize admins/the community to make blocks that wouldn't otherwise need to be made, but I also strongly agree with what Ritchie333 is implying below: that holding out for the perfect proposal means we end up stuck with an even less desirable status quo. I believe this proposal will remove admins who need to be removed and will not remove admins who don't need to be removed, all while furthering admin accountability to the community, which is important to me. That means it's likely to be on net an improvement, and I support things that are improvements even if my ideal desysop proposal might read differently. And if this system doesn't work, I have no doubt that the community will be capable of revising or repealing it. Extraordinary Writ (talk) 17:52, 17 April 2023 (UTC)
• Support per nom. This doesn't seem likely to solve much since I can't imagine very many admins are blocked for a month, return to editing, and don't resign the tools. But as a few of the supporters have alluded to, even a miniscule tightening of the rules for administrators who have clearly lost community trust (and anyone remotely high-profile here who is blocked for a month has very clearly lost the community's trust) is a net-positive. Even if its only real effect is to show that we can agree on something. Ajpolino (talk) 18:14, 17 April 2023 (UTC)
• Oppose Is this really a "community" desysop process? That is, if most of the power is with admins, can it even really be called a community process? The proposal ostensibly starts with a case where "the community has consensus that an administrator should be blocked indefinitely, or at least for a significant period". But the actual proposal doesn't require any sort of community consensus that the admin be blocked. Yes, any block that's in anyway not obvious will almost certainly go to the community within 28 days, but it still gives the power to admins to start the desysop process. I also note that WP:CTOP blocks can be unilaterally imposed and require a "clear consensus" to lift, so we could have a situation where 60% of the community disagrees with a block but that still results in a desysop. Imagine also being the closer of such a discussion and having the almost unilateral power to decide if someone gets desysopped. Yes, there's the safeguard of "may appeal the removal to the Arbitration Committee" but in a proposal meant to save time I only see more drama and time being wasted in any controversial case.
  I also think this makes blocking admins worse, both in them not being blocked and in them being unnecessarily blocked. As Sdrqaz eloquently explains, this makes blocking admins more troublesome. But I also think this could result in admins being unnecessarily blocked just so they can be desysopped. Someone brought up Wikipedia:Arbitration/Requests/Case/Neelix as one case where this could be useful. But I note that Neelix was never blocked for more than a few days until well after the case, and I don't think a block should have been imposed just to cause a desysop - often times, a community restriction is all that is actually needed. I think there's a case of Goodhart's law here - I'm not and I don't think anyone is disputing that an admin blocked for more than 28 days is unfit to be an admin, but I think using that as a the only measure will cause more problems than it will solve.
  To be honest, I'm not convinced there's any particular need this is addressing. ArbCom has only seemed more and more willing to de-sysop over the past few years (and I've generally seen this as a good thing). The main argument seems to be that this will save a full case in obvious cases, but ArbCom literally just de-sysopped by motion without requiring a case (after a lot of hemming and hawing to be fair). And that was in a case where the community even rejected an indefinite block, so less obvious than any case this proposal addresses. I honestly think all we need is ArbCom being more willing to desysop by motion in obvious cases and the community supporting that. Galobtter (talk) 19:00, 17 April 2023 (UTC)
• Support because it's something. Moneytrees🏝️(Talk) 19:46, 17 April 2023 (UTC)
• WeakSupportOppose "Support" reasons are those given by the nom and because it's something. "Weak" Oppose because this we need stronger more routine community reviews rather than focusing on desysop, and this one is for even rarer cases when they blew it as an editor rather than aqs an admin. We need to strengthen WP:Administrative action review and take the "poison pills" out of it. And add to it more admin conduct issues. And the most common results would be mere findings and guidance and maybe a few trouts. North8000 (talk) 20:18, 17 April 2023 (UTC)

"Safe" but so specialized/ unlikely to get used that it's not worth the diversion and complexity of creating. North8000 (talk) 20:41, 18 April 2023 (UTC)

• Oppose Why can't we just keep it simple and have a community desysop process based on an up-and-down majority vote like Commons? -- King of ♥ ♦ ♣ ♠ 20:36, 17 April 2023 (UTC)

  Because people keep opposing to the specific proposal rather than the general concept, so it never gets consensus. Ritchie333 ^{(talk) (cont)} 20:59, 17 April 2023 (UTC)

  The next admin block/unblock will be a de facto desysop discussion, and we have no rules at all how to deal with these, so we'll just make the rules up as we go along on ANI. That is a terrible way to make sound policies. —Kusma (talk) 21:08, 17 April 2023 (UTC)

• Support. I disagree with Sdrqaz that this will make the WP:SUPERMARIO effect worse. To the contrary, I believe it will help by linking the "normal" way of dealing with conduct issues (blocks) with the loss of tools. Otherwise, this is a sensible, if imperfect, proposal. I think Tamzin's concern can and should be easily solved by specifying the block must be non-voluntary. And I would rather have a clause delaying the removal of the bit if there is an appeal ongoing: there shouldn't be a race-against-the-clock to form consensus within the next 24 hours at AN before a new RfA is required to regain the mop. I also think it would be cleaner to simply specify that losing the tools in this way counts as losing them under a cloud, instead of separately explaining how one can regain the tools after losing them in this way. But perfect cannot be the enemy of progress. HouseBlaster^talk 21:45, 17 April 2023 (UTC)

  Just after I hit publish, I realized the significance of something WTT said above: "(or waiting 12 months)". One off-the-rails admin can already issue a block that will eventually result in the removal of the bit. Heck, anyone can hop over to ANI and seek consensus for an indef ban, which would result in them losing the tools after a year. All this proposal does is lower the amount of time it takes before the tools are removed. Do you think someone who is blocked for more than 28 days but less than a year deserves access to the tools? I don't think so. HouseBlaster^talk 21:54, 17 April 2023 (UTC)

• Support Without reservations. This has been desperately needed for 20 years. The process itself can be amended later if needed but we need SOMETHING here. The idea the community can elect admins but never remove them without appealing to ArbCom is backwards and always has been. - Who is John Galt? ✉ 21:47, 17 April 2023 (UTC)
• Oppose - I support the idea of a process for community desysop. But this isn't it. First, 28 days is way too short a time period. This should be a year at least, and only in the case of a ban. Second, as we have shown through adding things like partial blocks, what an editor does in one place may not disqualify them from being able to positively help out in other ways. And so, just being blocked for reason A, should necessarily mean that the admin tools should be removed. Due to the idea of escalation blocks, should someone who receives a 30-day block suddenly lost the tools? Also, there's a difference between a block and a ban - and this is intentional. So no, we should not be removing tools merely due to an arbitrary time period of a block. To be clear, I think I might have supported this if the time period was "a year and a day", and if it was a "community ban", not merely a block. - jc37 22:42, 17 April 2023 (UTC)

  @Jc37 If an admin doesn't edit for a year, say, because they're blocked - they already have their admin rights removed. But I can guarantee, that there would be community uproar and an arbcom case before that happened. This simply gives a procedural option, shortening the time period, meaning that Arbcom need not be involved. Worm^TT(talk) 07:35, 18 April 2023 (UTC)

  @WTT - 28 days is way too short. It needs to be at least longer than the 6 months of the Wikipedia:Standard offer. To do otherwise is just inherently wrong. And, in practice (based upon actual requests I've seen), longer than a year is what's more likely, if the community is willing. Hence my "a year and a day". If you think there would be an uproar and this needs encoding, then let's please have that discussion. And what everone's been saying here about a single admin essentially making this happen - that really just sounds like a bad idea. And setting aside the act itself, I think adding this to the mix will rachet up the drama. That's a time sink that we can avoid, I think, by making this a community ban rather than merely a block. - jc37 07:48, 18 April 2023 (UTC)

  @Jc37, I understand where you're coming from, as I say, we already remove for inactivity after a year, block or ban. So, in my eyes, your suggestion is moving further away from the goal of a community desysop without Arbcom. Why is (at least) 28 days too short? It allows for absence, cooling off, negotiation, self imposed / community imposed sanctions or any other dispute resolution. A month is considered a reasonable period for discussion at almost every venue I can think of. Worm^TT(talk) 07:59, 18 April 2023 (UTC)

  If that's all true, why then do we wait 6 months for the Standard offer? I think that community has already set the absolute minimum length of time there, and really, even there, it suggests longer. What does it say about us if we say: "It's been 30 days - you've done your time and now are unblocked, but we don't trust you any more." ? Useight (below) was very right that this just screams punitive. Where's the fire? - jc37 08:11, 18 April 2023 (UTC)

• Support per Ritchie333 and Beeblebrox. I have nothing to add to their words. LEPRICAVARK (talk) 22:48, 17 April 2023 (UTC)
• Support per Ritchie333 and Beeblebrox. In the extremely unlikely event that someone was blocked for >28 days, and was not unblocked before that period elapsed, but did still have the trust of the community then they could demonstrate this trust to arbcom who would grant the appeal and/or they would easily pass a new RFA. Thryduulf (talk) 23:05, 17 April 2023 (UTC)

  I think that's a bit of circular reasoning. That could be said of anyone for any reason. For example: "If they have the community's trust then they would easily pass a new RFA, so we should have daily RfAs for admins."... - jc37 23:20, 17 April 2023 (UTC)

  Well daily is hyperbole, but I fully support having reconfirmation RFAs when someone figures out how to get community consensus for a scalable process. Thryduulf (talk) 00:01, 18 April 2023 (UTC)

• Support with caveats. An admin who has been blocked in good faith for more than 28 days should just not be an admin. If they haven't been able to appeal their block in that time, then they don't have the support of the community, and they should be demopped until they can demonstrate support in a reconfirmation RFA. What we're proposing here is a desysop related to clear misconduct; WP:CLOUD should apply. These shouldn't be procedural with the right to regain the tools upon request, like inactivity desysops are. If I block someone and take away their pagemover userright for out-of-process moves, they don't just get it back when the block expires, they have to make a new WP:PERM request and demonstrate suitability all over again. There's no way admins should be held to a lesser standard than that. Ivanvector (^Talk/_Edits) 23:30, 17 April 2023 (UTC)
  • Ivanvector, the proposal already covers this with Administrators who have their sysop user-right removed in this manner are not eligible to simply request return at bureaucrat's noticeboard, right? Or is there something else you'd prefer? Extraordinary Writ (talk) 23:35, 17 April 2023 (UTC)

    Thank you, I misread. Comment revised. Ivanvector (^Talk/_Edits) 15:24, 18 April 2023 (UTC)

• Oppose just because I think this is going to end in wheel wars. I would support automatic removal of sysop on a successful community ban that was widely participated in, however. It should also be made clear that ArbCom is still an option to result in a desysop. --Rschen7754 00:49, 18 April 2023 (UTC)

  I'm not surprised to see an editor, like yourself, who was around for the wild west days bring this up but it strikes me as not part of our current culture. The last time we had a true wheel war was Fred Bauder, no? I feel WHEEL is properly understood to be a brightline desysop offense these days and so admins just don't do it. In this situation the third mover would be someone reinstating a block so losing your admin bits to try to make sure someone else loses theirs would be a choice. Best, Barkeep49 (talk) 02:49, 18 April 2023 (UTC)

  I don't remember if WP:FRAM came before or after Fred Bauder but there were minimal penalties for that scenario. Rschen7754 03:02, 18 April 2023 (UTC)

  We have strong procedures for wheel wars and actually, we haven't seen them in years. Maybe the odd Wheel skirmish, but nothing of the like from Wikipedia's early days. Yes, this proposal risks pushing those procedures, but I think that's worth it. Worm^TT(talk) 07:32, 18 April 2023 (UTC)

• Oppose While it might seem intuitive to say that an admin blocked for a month shouldn't be an admin, a block can be instituted by any admin or cabal of admins and I don't agree their decision should overturn the results of an RfA. I don't have that much faith in the sort of admins we have on this website. Chris Troutman (talk) 03:13, 18 April 2023 (UTC)
• Oppose. The purpose of a block is to prevent damage or disruption to Wikipedia. Assuming the block was done properly, then the block is performing that function (that is to say, the user is blocked and therefore cannot damage/disrupt Wikipedia). Having the block do something more is not within the intended scope of a block. I would go so far as to say that this proposal would make 28-day blocks punitive instead of (or in addition to) being preventative. It's unclear to me how removing the bit prevents something that the block doesn't. Useight (talk) 03:46, 18 April 2023 (UTC)

  "Preventative, not punitive" is a very, very good point. - jc37 06:10, 18 April 2023 (UTC)

• Support per Ritchie333 and Beeblebrox.Pharaoh of the Wizards (talk) 05:41, 18 April 2023 (UTC)
• Oppose I support a community-based desysop procedure, but only one that has a clearly defined and equally community-based resysop procedure. The proposal as written tries to address potential objections around resysop by splitting the baby and having ArbCom oversee an undefined appeals procedure.
  Ultimately it comes down to this: if this is procedural and linked to inactivity desysops as the proposal is hinting at, then an individual should be able to request it back at BN. If it is actually a community-based disciplinary procedure, +sysop should only be able to be restored via RfA, not by ArbCom.
  Worm, I'm assuming you wrote this proposal as something that would address potential objections and could pass (i.e. the objection that there's no procedural protection, so leaving the option of an appeal on one hand, and then the objection that if it is procedural it can just be re-requested on the other.) The problem is that the resysop provisions try to have it both ways, and the real crux of any desysop proposal is the resysop provisions (removing the flags are easy; the question is who can get them back.)
  I would support some version of this with resysop provisions that are clearly defined and aren't ambiguous and subject to a relatively opaque ArbCom appeal process - whether that be requiring RfA, or allowing restoration at BN. But the current language will cause drama when someone is desysoped after 28 days, is unblocked on day 29, and then goes to ARCA or even emails the mailing list. If this is going to be community based, resysop must be community based too. TonyBallioni (talk) 06:00, 18 April 2023 (UTC)

  I accept that the Arbcom appeal process is opaque, and you are right, I put it in to address potential concerns. The point of the committee is to deliberate, and I'm sure the group could make a decision on whether the procedural removal should have happened - which will go back to whether the block was valid in the first place. I'd also welcome expansion of that clause to whatever the community wished (from ability to raise a full case to only appeal in absolute obvious circumstances, eg bad block that somehow stuck) - or indeed the complete removal of the clause. I am against allowing restoration at BN, but RfA being the only option here would be fine by me. Worm^TT(talk) 07:30, 18 April 2023 (UTC)

• Oppose. Blocks are a technical measure to prevent imminent or likely damage to Wikipedia. This proposal would turn them into a proxy for a high-stakes disciplinary process. That is not the purpose of the block feature. It is ArbCom's job to desysop users, and in the rare cases in which the community keeps an admin blocked for more than a month I find it difficult to imagine that ArbCom would not take up an appropriate motion, as they recently did in the Dbachmann case. Sandstein 11:32, 18 April 2023 (UTC)
• Support per Worm That Turned and Ritchie333. ✠ SunDawn ✠ (contact) 11:39, 18 April 2023 (UTC)
• Support I originally thought I would oppose this, but ultimately an action serious enough to warrant a 4 week block is one that would have led me to oppose at an RFA, and by extension should be enough to indicate that the user shouldn't be an admin. I understand that mistakes happen, but at this length it isn't a minor infraction or one-off issue, and there's been time for appeals and considerations. So yes, I'm ok with this, and oddly enough I'm more ok with this than some of the issues that I've seen result in a desysop via Arbcom. That said, if it is easier to remove admin rights I wish it was also easier to grant them, but perhaps one needs to be modified to fix the other. - Bilby (talk) 11:45, 18 April 2023 (UTC)
• Support. Seems uncontroversial and logical, per "an admin blocked for that long should not be an admin". --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 12:10, 18 April 2023 (UTC)
• Support with perhaps an exception that a self-imposed block should not trigger the desysop. But if an admin is blocked for cause and can't find an unblock from any other admin in a month, that's prima facie evidence of having lost the community's trust. Courcelles (talk) 13:37, 18 April 2023 (UTC)
• Support - First choice as compared to the alternate proposal below. There's nothing I can really add that hasn't already been said. Other than Fnord. --⛵ WaltClipper -(talk) 15:49, 18 April 2023 (UTC)
• Weak Oppose per Jayron32. This seems more like a solution in search of a problem than an actual need. If someone can show me a need, i.e. where an admin really needed to be de-sysopped and existing procedure failed to do it, I could be convinced to support. Dave (talk) 16:38, 18 April 2023 (UTC)
• Support This proposal won't really solve the problem of unaccountable admins or the need for a community desysop procedure, and will in practice probably never be used. But it's something, and really, it should work this way regardless. Writ Keeper ⚇♔ 17:34, 18 April 2023 (UTC)
• Support per above. If an editor with admin rights gets blocked for a month, they're clearly not fit to be an admin -FASTILY 19:55, 18 April 2023 (UTC)
• Oppose This is prescribing punishment without due process, and would incentivize wheel warring. We need to come up with more than just the outcome. We need a set, agreed upon way of removing adminship in the first place. Just because someone has been in jail for a month does not make them guilty. CaptainEek ^{Edits Ho Cap'n!}⚓ 20:30, 18 April 2023 (UTC)
• Oppose mainly per Sandstein. This proposal is outside the traditional use of the block tools. It seems like a method for reducing Arb's workload, which isn't really that high anyway. I think if you are going to desysop someone, some kind of process needs to take place. Since desysopping via Arb really isn't that difficult, it needs to stay there. Arb has virtually unlimited tools, from full cases, suspend and desysop, hear and keep the bit, admonish, or sanction. Arb has shown they can do it in less than 28 days. Pushing it off onto the blocking admin and a calendar seems to be a cheap substitute for fair process, and frankly, seems a bit lazy. Dennis Brown - 2¢ 20:35, 18 April 2023 (UTC)
• Oppose. Upon reading the proposal my inital reaction was to support, but then I read the opposes here and changed my mind. The main argument that convinced me was Useight's point about WP:BLOCKNOTPUNITIVE. This seems like it would expand the block function into something punitive. I do think admins should be held to a higher standard than the average user, but I don't think an expansion of the block is the proper way to bring that about. Patr2016 (talk) 21:23, 18 April 2023 (UTC)
• Support. An admin who is successfully blocked for an extended period almost certainly does not have the trust of the community that is supposed to be the basis for adminship. Contra the "blocks should not be punitive" argument, as User:HouseBlaster points out above, a long enough block could already result in a desysop for inactivity. This is exposing the same result in a shorter timeframe, which is justified for the reason I stated initially. --RL0919 (talk) 06:03, 19 April 2023 (UTC)

  The words "could" and "same" are doing a lot of heavy lifting in that sentence. I have quickly sketched out this process and the inactivity process (apologies if I missed some details) here. There is a scenario in which the result is the same (defined as an administrator being desysopped and requiring a new RFA to get the bit back), but not necessarily (hence the "could"), but it would essentially have to be a two-year block with talkpage access revoked in order to force the same result as this 28-day proposal could do. To be clear, I'm not arguing the merits of this proposal here (as I already have done above), nor the merits of the inactivity policy, as that is not relevant here. I'm asserting that insinuating that this proposal is more or less the same as the inactivity policy applying to a blocked admin, only shorter, is a disingenuous argument. Useight (talk) 15:41, 19 April 2023 (UTC)

• Oppose as unnecessary and potentially harmful as a strict policy. Long-term or indefinite blocks of admins are fortunately very rare. The situations where they do happen, and the proposed policy would apply, are already drama-filled, and it is precisely for that reason that it is helpful to have someone like Arbcom reflect on whether continued admin permissions are warranted. I see lots of potential for additional drama from a policy like this one (e.g. keeping a user blocked past the time a block is needed to prevent disruption so that deadminning is triggered). I would support the community validating to Arbcom that admins engaging in behaviour that gets and keeps them blocked long-term is conduct unbecoming and grounds for desysopping, but given this is a rare occurrence I think the additional step of Arbcom weighing the desysop is beneficial and hardly a horrible additional workload. Bottom line: the *behaviour* that leads to a long-term block of an admin is likely grounds for desysopping, but that should be through normal channels for a conduct-related desysop (Arbcom) rather than "procedural". Martinp (talk) 17:41, 19 April 2023 (UTC)

  Added an alternative proposal relying on WP:LEVEL2 below. Martinp (talk) 18:12, 19 April 2023 (UTC)

• Oppose in it's current form. This seems overly bureaucratic, and makes no mention of specifically being blocked for misconduct as opposed to something like a self-block to enforce a wikibreak or a circumstance where an appeal is ongoing (controversial ones can last longer than 28 days). I'll review the alternates below, but in general I'm opposed to this sort of "automatic" process for anything but housekeeping. The Wordsmith^{Talk to me} 18:26, 19 April 2023 (UTC)
• Support - if blocked for that amount of time, indeed a desysopping is in order. Atsme 💬 📧 02:44, 20 April 2023 (UTC)
• Oppose this specific policy implementation but not the general idea of such a process. Andre🚐 02:47, 20 April 2023 (UTC)
• Support per Barkeep, Beeblebrox, et al. firefly ( t · c ) 08:27, 20 April 2023 (UTC)
• Support - Recent months have highlighted again the need for some kind of community desysop procedure; while this proposal would not work for all situations, it is an improvement on the current situation. Fundamentally, an admin who has been and remains blocked for 28+ days is not a suitable person to be an admin. The worries about rogue blocks leading to desysops without community input do not worry me - I cannot imagine that one admin blocking another, especially for 28 days, would not makes its way to ANI almost immediately. I would be very happy to add a condition that if the community later overturns the block (as a bad block, rather than a "you've apologised and learned your lesson"), then admin rights can be restored. Equally, I would be happy to put in a hold condition that would pause the process if there is an active, ongoing review of the block. And waiving the procedure for non-bad behaviour blocks (self-requested, for example) would be fine too. WJ94 (talk) 09:19, 20 April 2023 (UTC)
• Oppose as a solution looking for a problem. Stifle (talk) 10:14, 20 April 2023 (UTC)
• Oppose a rare occurrence like this can be handle by ArbCom. Such a rule would encourage gaming the system (get a long block on an admin you don’t like to end them for good). Jehochman ^Talk 12:19, 20 April 2023 (UTC)
• Oppose this is an overly baroque procedure. I'm supporting the alternate proposal instead. Jahaza (talk) 16:54, 20 April 2023 (UTC)
• Support in cases where someone is blocked for that long they should almost certainly be desysopped. Any block like this would be subject to lots of community review anyway and I highly doubt it would be used just to desysop someone. Hut 8.5 18:20, 20 April 2023 (UTC)
• Oppose as needless bureaucratic bullsnot to control the flow of power. Rules, restrictions, and more rules on top of more restrictions... This whole site creeps me the bleep out! Huggums537 (talk) 05:32, 21 April 2023 (UTC)
• Oppose as pointless - blocking an admin for this period of time happens very rarely, and the one time it did happen (Athaenara) it wouldn't have helped as Arbcom was already pursuing a desysop long before it would have triggered. * Pppery * _{it has begun...} 21:20, 21 April 2023 (UTC)
• Weak oppose as I really like the sentiment of the proposal, but I think it would have the opposite of the intended effect. I'm really not worried about wheel warring or covert blocking, since any block of an admin is inevitably going to garner a lot of scrutiny. What I do worry about though is the impact this has on blocking admins. Either the potential desysop consequence is a factor in blocking a sysop, in which case the wonderfully uncontroversial question "have they done something desysoppable" would be introduced to the decision making process behind the block (and you can imagine how many admins want to make unilateral decisions on that). Or, the desysop sanction is not a factor, in which case a) said sanction is punitive, not preventative, and b) any admin that feels compelled to block another admin is opened up to immense drama and inevitable speculation over their motives. The drama that would likely come with a blocked sysop today is already big, and I don't think raising the stakes and adding a timer and an ultimatum on whether to unblock would be an improvement. Giraffer ^{(talk·contribs)} 14:30, 22 April 2023 (UTC)
• Oppose There's too many potential negatives to this, and the reality is the number of cases it could possibly address are vanishingly small, if they exist at all. I don't see a need for more instruction creep to deal with a non-existent problem. --Hammersoft (talk) 17:01, 23 April 2023 (UTC)
• Weak support My first thought was 'oh, what if it was a bad block?' and some protection needs to exist for that. Also, my second thought was 'let's just block someone for 28 days and there they go, desysopped!' with the intention being the secondary and not the primary...'oh look, 28 days? Desysop!!'. Nonetheless, I hope common sense will be applied to this proposal, as it will make desysopping quicker in some cases when it needs to be. Obviously, an indef block of an admin means goodbye admin rights. That's pretty clear cut. talk to !dave 12:54, 24 April 2023 (UTC)
• Weak Oppose - kill the "On the first day of the month" part, if this is going to happen it shouldn't be pegged to a specific day of the month, should just be rolling like everything else in the admin policy. (Now, if it in practice happens a bit late sometimes - no big deal, but if the processor is late and the block has already lapsed then it shouldn't be done either....). In short, this sets up yet another pile of bad timing issues that like to find their way in to the admin policy, cause headaches, and need to eventually be repaired. Try again, — xaosflux ^Talk 22:54, 24 April 2023 (UTC)
• Oppose mainly per TonyBallioni's lengthy oppose and Stifle's pithy one.--Bbb23 (talk) 23:12, 24 April 2023 (UTC)
• Support this with reasonable exceptions as needed, and also support TonyBallioni's proposal. – John M Wolfson (talk • contribs) 23:30, 24 April 2023 (UTC)
• Oppose - Can't see how this is needed or useful. Paul August ☎ 23:34, 24 April 2023 (UTC)
• Support - very reasonable.--Dl.thinker (talk) 23:47, 24 April 2023 (UTC)
• Oppose per Stifle who beat me to it. This is a solution in search of a problem. I have confidence that if an admin has been blocked for good cause that the matter will be handled by ARBCOM where they would also have at least an opportunity to present their side rather than being automatically punished in contravention of the community's blocking policy. See also WP:CREEP. -Ad Orientem (talk) 00:58, 25 April 2023 (UTC)
• Oppose grave punishment done mechanically without deliberation. Lokys dar Vienas (talk) 04:06, 25 April 2023 (UTC)
• Oppose Per Seraphimblade. A month gives plenty of time for Arbcom to sort things out, and if they can't handle desyops in that time, why do we have an Arbcom again? Jclemens (talk) 04:14, 25 April 2023 (UTC)
• Oppose both per WP:BLOCKNOTPUNITIVE and per CaptainEek's "just because someone's been in jail for a month doesn't mean they're guilty" argument. I'd support a separate community desysop procedure, but would not support automatically tying it to a block. Loki (talk) 23:53, 24 April 2023 (UTC)
• Oppose Classic solution in search of a problem. What problem are we trying to solve here? How many times has an administrator been legitimately blocked for 1+ months and didn't subsequently lose the tools? More needs to be done to better define the problem to be solved by this proposed policy change, so that we can gauge whether this is the best solution to that problem. As it stands, the proposed solution is somewhat bizarre, e.g. having it tied to the first day of the month. —⁠ScottyWong⁠— 04:50, 25 April 2023 (UTC)
• Oppose; the ArbCom exists to deal with these matters. The proposal as written fails to exclude no-cause self-blocks and self-requested blocks. The proposed process could easily be gamed. Sending desysop proposals though the ArbCom avoids gaming and less-than-desirable behavior like pile-ons and partisan !votes at dramah boards. See also WP:CREEP. Baffle☿gab 05:46, 25 April 2023 (UTC)
• Oppose; sounds good on paper, but it just means that admins are able to desysop each other, and given ArbCom exists to deal with these sorts of matters, why don’t we just leave desysops to them. Zippybonzo | Talk (he|him) 06:16, 25 April 2023 (UTC)
• Oppose: I've worked at CAT:RFU and introduced a category for idle unblock requests because of the overwhelming amount of unblock requests in the queue that needed some kind of sorting. Even with these, currently 31, idle unblock requests taken out of the main category, there remain 96 open unblock requests as of now. A noticeable amount of these won't reach a decision within the next 28 days, so I'm not sure which allegedly reasonable source that number of days comes from. I'm unhappy with the assumption that an admin's unblock request will surely be handled quicker than the others, skipping the queue as an implicit necessity codified into the desysop procedure. ~ ToBeFree (talk) 06:51, 25 April 2023 (UTC)
• Oppose we already elect Arbcom to desysop admins when necessary. Re this specific proposal, the only admin who would have been caught by this in recent years was someone requesting a block to enforce a wikibreak. I don't think that we should discourage such wikibreaks in this way, or more likely create huge ANI debates about the blocking of admins who could be more quickly, fairly and less dramatically reviewed and if necessarily desysoped by Arbcom. I'm also concerned that this raises the stakes when blocking admins, especially thirty day blocks in the last couple of days of the month. I think that if anything we should try to reduce the stakes re the blocking of admins, an admin should be blocked in a situation where a non admin would be blocked. ϢereSpielChequers 06:57, 25 April 2023 (UTC)
• Oppose. A solution in search of a problem. There is absolutely no evidence that we have a significant number of admins who get blocked for an extended period of time without being desysopped by Arbcom. Moreover, as noted above, this proposal, if implemented, would significantly raise the stakes for blocking an admin. That would increase the amount of drama and gamesmanship surrounding such blocks and likely make such blocks more difficult to impose in practice. Nsk92 (talk) 08:23, 25 April 2023 (UTC)
• Oppose Reading through all the arguements above, Sandstein's was the most persusaive. The Squirrel Conspiracy (talk) 09:56, 25 April 2023 (UTC)
• Support We say that being an administrator is "no big deal," but as soon as a proposal comes up to remove administrators, it suddenly is a very big deal and administrators circle the wagons. This is a very reasonable idea. Figureofnine (talk • contribs) 12:11, 25 April 2023 (UTC)
• Oppose per Sdrqaz and The Wordsmith. OhanaUnited^{Talk page} 13:19, 25 April 2023 (UTC)
• Oppose, at least in current form. I think there's an unacceptable level of arbitrariness in this design. First, based on the votes, I now understand that "has been blocked for 28 days" refers to the the number of days the admin has been blocked as of the first of the month, not the total length of the block, as the buffer is meant to ensure an appeal is possible. But—and I concede it's possible I'm missing something big about how block timing works—doesn't that create chaos? Consider a user blocked for 1 month (or, hey, 30 days) at any point between April 3–29. By the first of the month, that user will not have been blocked for 28 days. Even if the user is blocked for 5 weeks on April 10th, they will not be subject to this sanction. But a user blocked for 1 month on, say October 2nd will have privileges stripped, because, by November 1, the user will have been blocked for 28 days.--Jerome Frank Disciple (talk) 13:55, 25 April 2023 (UTC)
• Support per Ritchie333. Inevitably, this procedure will have growing pains and problems. However, refinement requires testing and this is a very reasonable proposal. ~ Pbritti (talk) 17:49, 25 April 2023 (UTC)
• Oppose. This is a solution looking for a problem. If an administrator truly needs to be blocked longer than a couple days, I would expect an WP:ARC request to be filed well before the 28-day period is up. Recent examples have demonstrated that ArbCom is perfectly capable of expeditiously desysopping administrators in less than 28 days where necessary. For example, see
  1. Special:PermanentLink/1149026678#Dbachmann, in which ArbCom summarily desysopped an administrator (who was not blocked) after only 8 days of discussion, and
  2. Special:PermanentLink/1116499056#Athaenara, in which ArbCom summarily desysopped a blocked administrator after only 34 hours (see [1] for the desysop motion)
• Essentially, with the threshold set at 28 days, this will result in no tangible change to the current process, which is already quite efficient. Mz7 (talk) 21:22, 25 April 2023 (UTC)
• Support Though i don't care for the bureaucratic portion of it ~ on the first, twentyeight days... ~ which seem somewhat open to misinterpretation or abuse, it is a positive step towards a proper community de-admin process, and very clearly any admin who's been blocked for that long has lost the trust of enough of us that they shouldn't be adminning any longer. Happy days, ~ Lindsay^Hello 21:43, 25 April 2023 (UTC)
• Support- if an admin is blocked for that long, it means they must have done something very wrong. Admins who get such a long block should not be admins after all as they have broken Wikipedia policies to a serious extent. 747pilot (talk) 01:39, 26 April 2023 (UTC)
• Support This seems like a reasonable policy. Martindo (talk) 06:59, 26 April 2023 (UTC)
• Oppose Is there a problem with the current desysop procedure? Arbcom seems to desysop problematic administrators just fine. Lightoil (talk) 08:34, 26 April 2023 (UTC)
• Conditionally support if this can only occur where there are no ongoing appeal actions. Peacemaker67 (click to talk to me) 09:07, 26 April 2023 (UTC)
• Support as a stopgap between leaving problematic admins with the tools and having to wait months for ArbCom to handle the matter. Anarchyte (talk) 12:40, 26 April 2023 (UTC)
• Oppose The fact that an editor is blocked, does not automatically mean that he is not fit to be an admin. Sometimes it does, sometimes it doesn't. Therefore, this must be decided on a case-to-case basis, without any fixed procedures. Debresser (talk) 12:58, 26 April 2023 (UTC)
• Support Perhaps it's pointless, but I have a really hard time seeing how it could be a net negative. ᴢxᴄᴠʙɴᴍ (ᴛ) 13:45, 26 April 2023 (UTC)
• Oppose as written. Firstly, per Jayron32, there seems to be no actual problem that this would address. Secondly, the block tool is preventative and used to prevent ongoing disruption. This is mostly unrelated to reasons why an admin should be deadminned, and would muddy the waters — Martin (MSGJ · talk) 13:47, 26 April 2023 (UTC)
• Support – I note that some opposing arguments state that blocking doesn't automatically mean that removing the bit is necessary. I concede that point, but I also note the length of block required for this to become relevant. ANYONE who has been blocked for 28 consecutive days has shown to this community that their trustworthiness is questionable at best. While beyond the scope of this RfC, I would also support that, in addition to Administrators, all extended permissions – viz. CheckUser, Oversight, Bureaucrat, and anything granted at WP:PERM – should be automatically rescinded if that user has been blocked for 28 consecutive days. I've seen rather egregious conduct be met with blocks of only a few days, so for a 28-day block to be levied then someone really WP:DONTGETIT. — Jkudlick ⚓ (talk) 20:52, 26 April 2023 (UTC)
• Oppose I appreciate the intention in the proposal but I'm concerned with the aspect for creating higher level drama among individuals rather than solving an apparent, existing structural problem. Regards, --Goldsztajn (talk) 23:32, 26 April 2023 (UTC)
• Oppose. The intent is good, but the procedure is poor. It creates unnecessary tensions among administrators and we have a regular procedure for desysopping via Arbcom which should be respected. In addition, 28 days may just be too short a period to appeal. --TadejM ^{my talk} 16:10, 27 April 2023 (UTC)
• Support. Just about any proposal that makes it easier to get admin tools out of the hands of those who abuse them gets my support. The scenarios suggested in the oppose !votes where this causes problems are largely implausible. —swpb^{T • beyond • mutual} 17:47, 27 April 2023 (UTC)
• Weak support. I am not sure how often administrators block each other. If an administrator gets blocked, it should be serious enough to not only warrant a block but to warrant removal of administrator privileges. Samuel R Jenkins (talk) 04:32, 28 April 2023 (UTC) Blocked sock. NmWTfs85lXusaybq (talk) 03:43, 1 May 2023 (UTC)
• Oppose I agree that the community needs a de-sysop procedure, but this is not it. This could make block of less than 50 days become somewhat of a Russian Roulette for whether they stay an admin. Furthermore, this is hardly a "community procedure" since only other admins can block admins. We need a system, but not this one. QuicoleJR (talk) 16:19, 28 April 2023 (UTC)
• Support per Beeblebrox and Ritchie. Admins must have the confidence of the community, so it makes sense for their bit to be subject to community consensus, rather than needing to rely on ArbCom. Also agree with others that the risk of stealth desysops is very low; and anyway, that would itself be an ADMINCOND issue. DFlhb (talk) 19:24, 28 April 2023 (UTC)
• Support if nothing else. I think this is a poor solution, but any form of community desysop is better than nothing... CLYDE ^{TALK TO ME}/_{STUFF DONE} 21:17, 28 April 2023 (UTC)
• Oppose per QuicoleJR. And WP:CREEP. This adds more procedural layers, while lacking clarity for implementation E.g., the faulty 1st of the month element. Something much simpler might find consensus. Pechmerle (talk) 05:53, 29 April 2023 (UTC)
• Weak support I have concerns around mobbing but also if someone has that kind of ban they shouldn't be an admin UNLESS there is some sort of reasonable reason. Dr vulpes ^{(💬 • 📝)} 06:03, 29 April 2023 (UTC)
• Weak oppose. It just seems like a lot of clean up when they should've had their admin rights removed as part of the block. I do agree with the proposal but not the process. Any admin who's worthy of a block should be desysopped automatically, and if they want their rights back, a community review should be conducted. Callmemirela 🍁 ^talk 14:48, 29 April 2023 (UTC)
• Oppose Too many weird edge cases in this proposal, as already well described by others. Anomie⚔ 14:56, 29 April 2023 (UTC)
• Oppose too much of a catch all such as admins blocked for a wiki break. Also desysops should not be automatic in my view, each one needs proper consideration, Atlantic306 (talk) 20:03, 29 April 2023 (UTC)
• Support – This is a "Like, duh!" proposal, so of course it's opposed. Welcome to Wikipedia. --IJBall (contribs • talk) 00:16, 30 April 2023 (UTC)
• Support. It seems like a waste of ArbCom's time when there is a snowball's chance in hell that a blocked editor deserves to be an administrator.  — Freoh 12:11, 30 April 2023 (UTC)
• Weak Oppose In theory this could be good (say, someone gets radicalized into being a QAnoner or Anti Vaxxer on YouTube and that becomes their new activist cause for the site). However, I worry ArbCom in the end will value civility over all else and this will heighten demographic disparities in administrators. People of color, women, and queer people are more likely to be seen as incivil and I can easily conceptualize perma-bans from administration resulting in an even higher proportion of straight white men determining who is write or wrong at ArbCom, which already has documented troubles with arbitrating contentious topics related to race, gender, and sexuality.Computer-ergonomics (he/him; talk; please ping me in replies ) 12:56, 30 April 2023 (UTC)
• Oppose Needlessly bureaucratic and WP:CREEPy. Some1 (talk) 14:03, 30 April 2023 (UTC)
• Support, but what is who is blocked and has been blocked for more than 28 days? What happens if your block lasted more than 28 days but expired on say 5th of the month? Then you escape removal in the current cycle because it is not yet 28+ days, but in the next cycle, you won't fulfil is blocked requirement and won't be removed despite being blocked for 28+ days. I think is blocked is unnecessary. If you were blocked for 28+ between previous and current cycle, you should be desysoped. AhmadLX-(Wikiposta) 16:38, 30 April 2023 (UTC)
• Oppose. The proposal is plausible enough on its face. But having read through all of the arguments above, nobody seems able to articulate an actually-existing problem that this would solve. Further, quite a few people have noted problems that this proposal would be likely to create. This is a narrow enough circumstance that the impacts would be limited, but given the risk of harm to the project and the lack of any clear benefit, it seems best to leave this sort of rare edge case to be handled on a case-by-case basis. -- Visviva (talk) 23:57, 2 May 2023 (UTC)
• Oppose for basically the same reasons as Visviva.-- Aervanath (talk) 10:05, 3 May 2023 (UTC)
• Support: Not the first time Tony's comments have been the pivot upon which consensus might swing, but while I don't really disagree with his statements (and also note Galobtter's fair points about "not community"), I still basically take the Moneytrees approach here: it's barely anything so at least it's something. If it were to go, I'd prefer clarity that it's considering full blocks not partial blocks. ~ Amory (u • t • c) 12:26, 3 May 2023 (UTC)
• Oppose - This seems to create more problems than it solves. If the problem is untrustworthy admins, then giving admins the power to effectively de-sysop each other by imposing 28 day blocks seems to exacerbate the problem. Admittedly there could be a review, but I am not sure how well that would work. Rlendog (talk) 14:20, 3 May 2023 (UTC)
• Support but enforcement should consist of removing admin rights on day 28. Aasim - Herrscher of Wikis ❄️ 15:08, 3 May 2023 (UTC)
• How often does this happen? Guy (help! - typo?) 17:11, 3 May 2023 (UTC)
• Weak oppose. Add me into the column of respondents who think we are long overdue to establish some sort of broad community based desysop process, but who view this particular proposed solution to be far too awkward, unnesesarily indirect, and likely to prove prone to numerous problematic knock-on effects, several (but probably not all) of which have been identified above. Personally, I would advocate that we simply create a process for a discussion and direct community !vote (presumably to be typically conducted at ANI like msot CBANS), with an atypical requirement that there be a certain advisory threshold for minimum number of participants and minimum proportion of support perspectives, so that any communty desysop has some degree of rough parity with the volume of community will expressed through RfA itself. I don't really see the need for a more complicated process or more involved criteria than that: so long as there is a relatively high burden of required support baked into the policy language that describes this process, the community should be able to handle these exceptional cases through the same open-discourse and proposed sanctions methodologies with which it handles any other claims of serious misconduct. SnowRise ^{let's rap} 02:04, 4 May 2023 (UTC)
• Oppose. Solution in search of a problem that also has the potential to create new problems. The minimal benefit does not outweigh the risks. T. Canens (talk) 03:50, 4 May 2023 (UTC)
• Weak support - I'm fine with the principle but share the concerns of User:BilledMammal and User:Xaosflux about limiting implementation to the first day of the month. My preference would be not to specify that in the policy. Procedurally that could mean automatic implementation on the first day of each month, but that bureaucrats could also desysop blocked admins meeting the criteria manually at any time. The scenario User:BilledMammal outlined indicates why limiting implementation to one day a month is a bad idea. WaggersTALK 07:29, 4 May 2023 (UTC)
• Support – in general I support making it easier to revoke adminship. That brings us closer to the ideal of adminship being WP:NOBIGDEAL, which will hopefully make it easier to increase the number of new admins. —Mx. Granger (talk · contribs) 13:18, 4 May 2023 (UTC)
• Support, although I don't really see this as a community desysop procedure in the sense of "something done by the community", I don't see how an admin subject to a long block, not overturned, for a month can be considered to hold the confidence of the community. In any case, as the proposal currently stands, there are sufficent avenues of appeal. Alpha3031 (t • c) 11:13, 6 May 2023 (UTC)
• Oppose Needs to be after any length block (subject to any appeals over the block). Only in death does duty end (talk) 11:37, 10 May 2023 (UTC)
• Support – any admin blocked for that long should not be an admin. Ritchie's point an appealing is also particularly convincing. Aza24 (talk) 05:37, 11 May 2023 (UTC)
• Oppose per Tony. "Community desysop" should−explicitly and without exception−require community consensus. —Rutebega (talk) 19:44, 11 May 2023 (UTC)
• Support, though not an admin, my beliefs are the same as RickinBaltimore. InvadingInvader (userpage, talk) 04:15, 12 May 2023 (UTC)
• Weak oppose – no need for a procedural desysop here, in my opinion. Editing your own talk page while blocked should not count as an edit for postponing the year-long desysop, however. Skarmory (talk • contribs) 23:56, 12 May 2023 (UTC)
• Weak oppose mostly because this feels like instruction creep. It sounds like this might unintentially apply to self-blocked admins taking a break and would only truly apply to a few people (per BilledMammal conversation). Darkfrog24 (talk) 01:17, 13 May 2023 (UTC)

Discussion (Proposal: Procedural community desysop)

The concern I have with Arbcom is that it is such a long-drawn out process, that it burns out the people who are participants in a admin conduct related case, that they'd rather quit Wikipedia than stick it out. So we not only lose an admin, we lose an editor. Kudpung and RexxS are the most obvious cases I could think of, and it's just possible, perhaps, that a 48 hour civility block on either could have stopped them from quitting, addressed the complainants' concerns somewhat (for example, it's not a WP:SUPERMARIO if they get blocked, and a block removes immediate disruption and defuses situations in a way a long Arbcom case can't) and allowed them to hold on to their admin bit. Ritchie333 ^{(talk) (cont)} 15:52, 17 April 2023 (UTC)

"Administrators must be held accountable. But this is not the answer." This is pretty much why we don't have enough accountability, because too many people oppose the specific proposal over supporting the general concept. So nothing ever happens. Ritchie333 ^{(talk) (cont)} 16:31, 17 April 2023 (UTC)

(Since I'm being quoted) Ritchie, this isn't an enemy-of-the-good situation for me. If I thought the proposal would have a neutral effect, or a tiny positive one, or maybe even a negligible negative one, I wouldn't have opposed. My issue with the proposal is that it makes things worse, and that we are choosing to do something because it is something rather than because it's a positive change. As I explain above, I believe that it worsens accountability. Sdrqaz (talk) 02:02, 18 April 2023 (UTC)

I somewhat like this idea, but don't think I can support without a distinction between "for-cause" blocks and other ones. While it's rare for an admin to be blocked at length as a not-for-cause matter, I recall someone self-blocking a few years ago due to a family emergency, although I can't recall who at the moment. I would suggest adding for misconduct after the words who is blocked; I think it will be pretty straightforward for the bureaucrats to sort out the difference between "admin X is indeffed for repeated copyright violations" and "admin Y is indeffed with summary 'requested some time away from Wikipedia'". I also would rather this say something to the effect of and has no pending on-wiki appeals, although I tend to agree with Ritchie that after 28 to 59 days, things have probably shaken out. -- Tamzin^{[cetacean needed]} (she|they|xe) 16:32, 17 April 2023 (UTC)

For self-requested blocks, I think it would reasonable to relinquish administrative privileges at the same time. As a voluntary removal of permissions, the editor would be able to request to have them returned without having to go through a request for administrative privileges discussion. isaacl (talk) 18:26, 17 April 2023 (UTC)

One general issue is that our desysopping methods are already working better than our sysopping methods, so making additional desysopping methods (with no evidence that the current ones are insufficient) looks to me like working on the wrong problem. —Kusma (talk) 16:56, 17 April 2023 (UTC)

I choose to take that remark as a compliment. However, I don't think it is as much a matter of being insufficient as it is being unnecessary. Again and again when wayward admins are brought before the committee, they simply shut down and refuse to present a defense. So, the committee has been doing things like opening cases but suspending them for a few months, with the admin in question being temporarily desysopped unless and until they indicate a desire to open the case. To date, no admin has chosen the option of a full case when presented with such a choice. So, those admins do get removed, after 3-6 months, providing somebody remembers to actually close the case when it is supposed to close, which failed to happen at least twice in the last few years. This is simpler, faster, and presents pretty much the same choice to the admin: show up and present a cogent defense, or don't and let your admin tools go. Beeblebrox (talk) 17:08, 17 April 2023 (UTC)

I would note that as of this edit, among current or past arbs 5 support and 1 opposes. It's possible that "our desysopping methods are already working better than our sysopping methods" can be true but more because our sysopping methods are so broke that the desysopping looks good by comparison. Best, Barkeep49 (talk) 18:14, 17 April 2023 (UTC)

Recent for-cause desysops were handled quickly and with a comparably low amount of noise. I expect that there will be more noise under the proposed system, just less paperwork for ArbCom. —Kusma (talk) 18:52, 17 April 2023 (UTC)

I don't know. I feel like all of the recent admin arb cases, minus Jimmy's, had lots of community noise before and after it reached the case request stage. Best, Barkeep49 (talk) 20:02, 17 April 2023 (UTC)

In the Athaenara case, probably the desysop under this proposal would have gone through, but the block/unblock chaos might have been worse with blocks automatically meaning desysops. In the Geschichte case, if the community had had the tool of desysop-via-60-day block, it is anyone's guess how the epic ANI discussion would have played out, but I do think we'd have had more noise. —Kusma (talk) 21:21, 17 April 2023 (UTC)

"A blocked admin can't (since 2018) unblock themselves, and if they're blocked indefinitely, they'll just be auto-de-adminned when the time comes around." They are still able to edit their talk page and file an unblock request. This'll probably result in an ANI thread like this: "Hi, I just blocked admin X for edit warring and personal attacks, they're not admitting fault and threatening to block the other party in the dispute, can we review the block?" Or even, "Hi, I've indeffed Jimbo Wales as they've just blocked 3 arbs indefinitely; it clearly looks like their account is compromised". It'll get a response. If they're not prepared to file an unblock request, either they've got ANI flu and given up, or they think blocking is for the "little people" and not them, in which case they shouldn't be an admin. Ritchie333 ^{(talk) (cont)} 17:45, 17 April 2023 (UTC)

• Question: So, I have been doing some thinking on this beyond my initial oppose vote. What I want to know is what existing ongoing problem is this supposed to solve? Which is to say, what are some examples of blocked admins who got to keep their tools after being unblocked, and for which this process would have taken the tools away? It feels like a solution in search of a problem, at this point. I mean, unless someone can actually point to this being a problem (and I don't mean "one isolated case", I mean "an ongoing issue that keeps biting us in the ass"), then I really fail to see why we're going through the trouble to create a new policy. Can anyone in support of the policy provide evidence that this is a problem that needs new policy to fix? Examples, evidence, etc? --Jayron32 17:40, 17 April 2023 (UTC)

  The principal problem, as Beeblebrox said, it is it stops putting an unnecessary workload on Arbcom. It's a bit of an old example, but Wikipedia:Arbitration/Requests/Case/Neelix comes to mind. After the mass-creation of puerile redirects were discovered, he could have been blocked (to prevent any more being created) until the community could work out what to do. The community could have decided to site ban Neelix. But he was an admin, so Arbcom had to get involved, wasting everyone's time as I think there was near unanimity that Neelix should have been sanctioned. Ritchie333 ^{(talk) (cont)} 17:49, 17 April 2023 (UTC)

  You've asserted that it is "unnecessary workload". If your only example is a singular 8-year-old arbcom case, that's pretty flimsy in terms of necessitating a new policy. I think ArbCom can handle one such case every decade or so. Doesn't seem to me like "unnecessary workload". I ask again, what is the evidence this is needed? --Jayron32 17:53, 17 April 2023 (UTC)

  Also, I note that your best example was an ArbCom case that was resolved in 3 days. Replacing a process that takes 3 days with one that takes 28 days is somehow more efficient? --Jayron32 17:55, 17 April 2023 (UTC)

  It was the first example I could think of, and one of the most memorable, but by no means the only one. For example, Carlossuarez46 could have been blocked for personal attacks, or Athaenara could have just been indeffed for hate speech and left as is. Also, it might be worth comparing the 3 days with the amount of text that was generated, and from how many users - also, it's worth remembering that it only took 3 days because Neelix resigned his tools with a pledge he would not get them back with a new RfA. Ritchie333 ^{(talk) (cont)} 17:59, 17 April 2023 (UTC)

  Again, hardly a major issue. The memorable cases are memorable because they are so rare. We don't need to write new policy for cases spaced out over several years. You claim to be saving ArbCom work; have they asked the community for this help? Also, people are free to contribute to discussions as they see fit. I could equally claim that the amount of text this discussion has generated is out-of-proportion for the magnitude of the problem it proports to solve, which makes it worse than the problem it is trying to solve. I'm just saying that if you want more support for a proposed overhaul of policy, you've not shown how it is needed. A few isolated, weird cases have been shown. We don't have an epidemic of blocked-but-still-can-use-their-tools admins now, do we? If this were happening 3 times every 8 weeks or even 8 months, I'd think we have a problem. 3 times in 8 years seems hardly worth creating a policy over. --Jayron32 18:14, 17 April 2023 (UTC)

  If in practice the community has considered being blocked incompatible with having administrative privileges, then codifying this shifts discussion from the majority of cases where this view is held to those where exceptional circumstances may alter the community's opinion. This should be a net reduction in discussion (of course provided the initial inference on the community's view on blocked admins is true, which this RfC seeks to establish). isaacl (talk) 18:07, 17 April 2023 (UTC)

  How often are admins blocked? There's no need to create a policy to deal with a rare event. --Jayron32 18:14, 17 April 2023 (UTC)

  Sure, I often agree with that view. We'll see if the community thinks it's a net positive to explicitly state the incompatibility versus handling it each time it comes up. isaacl (talk) 18:41, 17 April 2023 (UTC)

  It's rather hard to query, because the database doesn't give an easy way to check whether user X was an admin at time Y, but for a mostly-complete set, combine quarry:history/65830/669690/650357 for current admins who've been blocked (mostly accidents/testing, with false positives for users like me who were blocked pre-adminship), the "Blocked or locked" sections of WP:FORCAUSE, Wikipedia:Former administrators/reason/resigned for past admins who are currently blocked (with false positives for post-desysop blocks), and Wikipedia:Former administrators/reason/compromised and "compromise" entries in WP:RESYSOPS (where I think everyone is or was once blocked); these miss most cases of blocked-then-deysopped-then-unblocked (but there's only one of those every few years) and blocked-then-unblocked-then-desysopped (but those are likewise mostly accidents/testing, with unrelated desysops). To my knowledge, prior to Athaenara, the last admin to be indeffed for cause as a regular admin action (i.e. not CUblock/ArbComBlock) and then get desysopped was Craigy144 in 2010—copyvio block, desysopped as unresponsive to ArbCom. There's several more recent blocks-then-desysops for compromise, with or without later unblock and/or resysop. -- Tamzin^{[cetacean needed]} (she|they|xe) 19:01, 17 April 2023 (UTC)

  @Tamzin: Fred Bauder was indeffed as a normal admin action by FPAS in 2018 for edit-warring and subsequent wheel warring. Maxim then removed the sysop flag as a unilateral emergency 'crat action (for violating WP:NEVERUNBLOCK/WP:WHEEL) shortly thereafter.

  There's a couple other indeffs done as normal admin actions that post date that of Craigy144 though none of them ended up lasting all that long, and thus were not the proximal cause of ARBCOM action, although in some of those cases they were part of the pattern that resulted in a later ARC and subsequent desysop. 74.73.224.126 (talk) 00:59, 9 May 2023 (UTC)

  @Jayron32:, you are right. This would probably apply about once every 5 years and won't affect Arbcom workload. But it's safe. Sort of like saying that if it it's found that somebody can't do basic addition (2 + 2 = ?) that we take away their math teaching position. North8000 (talk) 20:27, 17 April 2023 (UTC)

  @Jayron32, @North8000: The question is whether blocks of admins will remain rare if they have the option of turning into "community" desysops. —Kusma (talk) 10:33, 18 April 2023 (UTC)

  @Kusma: Good question. My guess is that that wouldn't happen. Basically a complex effort of a group of people mis-using the system to "get" an admin. But maybe a reason to avoid enacting something like this that really isn't going to serve a purpose. North8000 (talk) 13:39, 18 April 2023 (UTC)

  The Neelix case took four days. Guy (help! - typo?) 17:17, 3 May 2023 (UTC)

Regarding the concern that the proposal allows a single admin to block another, triggering a community discussion that may lead to the removal of administrative privileges: note unilateral blocks can only be enacted for edits related to contentious topics, enforcing specific arbitration remedies that authorize blocks, or for flagrant policy violations. An appeal of a block not meeting these conditions should be upheld, and the community can then decide if any further discussion of the situation is warranted. In essence, the same discussions that would occur today would still occur under the proposed change, with an added implication that being blocked is incompatible with holding administrative privileges. isaacl (talk) 17:50, 17 April 2023 (UTC)

It might be a good idea to have someone set up a bot to notify WP:AN whenever an administrator is blocked. Obviously it's pretty unlikely that such a block would slip under the radar for 28+ days, but if that notification would help reässure anyone that this proposal wouldn't be desysopping people under cover of darkness, it'd be a positive. Extraordinary Writ (talk) 18:08, 17 April 2023 (UTC)

Note the actual removal of privileges would not happen in the dark, and any unwarranted stealth blocks is going to be noticed when the list of blocked admins is prepared. So while it may be a good idea to have a bot update a page with a query of the list of blocked admins that can be transcluded elsewhere (or some other implementation), I don't think it's critical for this proposal. isaacl (talk) 18:38, 17 April 2023 (UTC)

This proposal does not require the community to weigh in in any way - it does not require the block to be reviewed or upheld. This is for obvious reasons: blocking an admin should in theory not be any different than a non-admin. But it at the same time relies implicitly on, and quoting the proposer himself, the assumption that "A block of an admin would be reviewed by the community". So I think it threads the needle of not explicitly making blocking admins different but in practice requiring community review of every long block of an admin (with the caveat that this will probably happen regardless of this proposal). In short, I'm not sure a proposal that explicitly required community review of the block would pass, but this proposal is functionally that. Galobtter (talk) 19:42, 17 April 2023 (UTC)

If blocking an admin results in de-adminship, then we will stop even pretending to treat blocks of admins the same as blocks of non-admins. WhatamIdoing (talk) 21:09, 17 April 2023 (UTC)

@WhatamIdoing FWIW, from a technical standpoint it effectively does.

While blocked the only logged action a blocked admin can perform is to block the admin that blocked them. SQL^{Query Me!} 23:10, 17 April 2023 (UTC)

Adding: Apparently you can't see deleted revs but can still see private abusefilter hits while blocked. SQL^{Query Me!} 23:18, 17 April 2023 (UTC)

But that "de-adminship" is automatically temporary. If you were blocked, you would still be an admin when the block expired. This is not what's proposed here. This proposal says: If you can get an admin blocked on January 3rd, for any reason, and it's not lifted before February 1st, then that admin will be permanently de-sysopped, even if the block is set to expire on February 2nd. WhatamIdoing (talk) 00:46, 18 April 2023 (UTC)

I am not sure if this has been considered. But since I found a discussion on desysopping, I bring it on. In the past I have observed two desysops not so much related with their sysop activity but with their views. I'd support a process where a sysop can be desysopped for their actions not so much for their views (they expressed some years ago). To desysop one for a few phrases in a little venue, when they had a tenure for several years...Have you considered to bring the desysop process before the community like the RfA?Paradise Chronicle (talk) 10:22, 25 April 2023 (UTC)

Clarification sought, in three scenarios:

• Admin A is blocked for 50 days on 10 July. On 1 August they haven't been blocked for 30 days yet so retain the mop. On 1 September they're no longer blocked, so retain the mop. Correct? That would seem to go against the proponents who argue that a 30-day block is a bad enough sign that the comunity no longer trusts A.
• Admin B is blocked for 40 days on 2 October. Drama ensues and a friendly (to B, anyway) Admin C unblocks Admin B in good faith, as C feels the block was inappropriate. A scant 23 minutes later after some testy posts at AN/I, Admin D reinstates the block, which holds. On 1 November, the review shows that B was not blocked 30 days and so retains the mop.
• Admin F is blocked for 30 days on 1 May. On 1 June, F is no longer blocked and so retains the mop. (The obvious "lucky timing" case.)

Is this the correct understanding of the proposal as written? — JohnFromPinckney (talk / edits) 21:24, 19 April 2023 (UTC)

Tweak based on comments made: "On the first day of the month, any administrator who is blocked and has been blocked [for cause] for more than 28 days [in the preceding two months] will have their administrator user-right procedurally removed (alongside inactivity removals)." SilkTork (talk) 08:39, 25 April 2023 (UTC)

SilkTork, do you mean to propose (as I think you might) ...for a total of more than 28 days...? That is, it could have been three separate blocks, yes? — JohnFromPinckney (talk / edits) 09:21, 25 April 2023 (UTC)

The convenience of routine software "housekeeping" functions does make this proposal seem awkward to implement. I suggest a shorter time limit, say 17 days of *consecutive* block, regardless of what happens between day 17 and the start of the subsequent month. I recommend 17 because it includes 3 full weekends, allowing for variations in time zone. Martindo (talk) 07:03, 26 April 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.

Alternate proposal (Procedural community desysop)

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

---

Let's simplify this, and align it with current policy and process.

If an editor is banned by the community (not merely blocked), their granted permissions - including but not limited to admin tools - are removed. And even if the editor successfully appeals the ban and returns to editing, they will need to re-apply through the typical processes (such as WP:RFA) to regain any removed granted permissions.

(This is for an indefinite, full ban only, not a limited, topical, or partial one.)

In the rare instance where the ban is reversed due to a mistake by the community (but not merely due to a successful appeal of the ban), then said removals are reversed as well. - jc37 08:28, 18 April 2023 (UTC)

Survey (alternate community desysop proposal)

• Support I see no reason that this is mutually exclusive from the other proposal, but I do support this. If a site ban passes on an admin, they should no longer be an admin. Worm^TT(talk) 08:40, 18 April 2023 (UTC)
• Support I support this. It is reasonable and a step even further in the right direction, with respect to having community say in desysops without forcing Arbcom involvement. I would like to also see non-ban related proposals for desysops, but those can wait for a more future time Soni (talk) 08:43, 18 April 2023 (UTC)
• Support, that is fine (assuming ban means "site ban" and doesn't include any interaction bans). This would have worked in the Athaenara situation and would not have been discussed in the Geschichte case. —Kusma (talk) 09:28, 18 April 2023 (UTC)
• Support as above Ritchie333 ^{(talk) (cont)} 10:21, 18 April 2023 (UTC)
• Support per WTT. Thryduulf (talk) 10:35, 18 April 2023 (UTC)
• Support Seems much more reasonable than the first proposal. If someone has lost the community trust to the point where a community discussion has led to a community ban, that should implicitly imply that such a person has lost enough trust to lose the tools. The first proposal leaves too much on a single, possibly time-limited block, it puts too much in the hands of a single individual. --Jayron32 11:42, 18 April 2023 (UTC)
• Support - this is probably the only community decision which is so extreme that it would never occur unless the community has lost trust completely. Users may demand a temporary block or a partial ban to an admin who ruled against them on some issue, but not a permanent site ban; a small number of highly vindictive users may demand that, but the community won't support it. Animal lover |666| 12:48, 18 April 2023 (UTC)
• "Their granted permissions - including but not limited to admin tools" - this will overturn the consensus determined in Wikipedia:Requests for comment/User rights of (site) banned users. Also, for the proposal itself: (1) I am personally against it citing WP:CREEP and current ArbCom is sufficient to handle such cases; (2) I suggest we should explicit mention that such actions may still be appealed to ArbCom.--GZWDer (talk) 13:43, 18 April 2023 (UTC)

  My understanding is that ultimately (after community paths have been trod) any community action may be appealed to arbcom. So that would presumably include this. - jc37 14:08, 18 April 2023 (UTC)

  I never really agreed with that in the first place anyway. --Rschen7754 23:25, 18 April 2023 (UTC)

  Consensus can change; no state of consensus is permanent, and no discussion can bind any future state of the community at Wikipedia from discussing an idea and reaching a new consensus. It is a good data point to know what the existing consensus is on a topic when discussing it, but that existing consensus only lasts until it isn't consensus anymore. This very discussion is the way we are change that consensus. --Jayron32 14:42, 19 April 2023 (UTC)

• Weak support - I think the wording here will still favor de-sysop requests being taken to ArbCom rather than a community de-sysop process, for the reason that a site ban would be considered an action with greater scope and severity than a de-sysop. I don't think this is a sufficient remedy, but it's better than nothing. --⛵ WaltClipper -(talk) 14:07, 18 April 2023 (UTC)
• Support introducing this consensus-oriented method of removing bits. As worded, this proposal would allow for the community to de-crat, de-CU, and de-OS; I believe that these are features of this proposal, not bugs. I would also suggest that whenever a unban discussion takes place, people should be advised to make it clear if they are supporting an unban as "User:Example should not have been banned in the first place" (in which case the tools should be restored) or as "no longer required to prevent disruption" (in which case they should not). I would also like it if we specified that any CBAN discussion that results in the bit being removed should be closed by a 'crat. That is, it should function like RfA closure does: anyone can WP:SNOW/WP:NOTNOW close, but only a 'crat can close as successful. (For the avoidance of doubt, I am not advocating that we institute 'crat chats or a "discretionary range" for CBAN discussions.) HouseBlaster^talk 15:08, 18 April 2023 (UTC)
• Support as duh. If an admin is site banned by the community, then obviously they lose their rights. Sending it to ArbCom would be, in my opinion, a waste of time as ArbCom would pretty much rubberstamp the desysop. RickinBaltimore (talk) 16:01, 18 April 2023 (UTC)
• Support. I don't see this as mutually exclusive with the above, and I don't see it being used often, but I agree with the principle. Vanamonde (Talk) 16:10, 18 April 2023 (UTC)
• Support, in addition to the original proposal above. Boing! said Zebedee (talk) 16:27, 18 April 2023 (UTC)
• Support I opposed the original proposal but this is of course very reasonable and something I think we can all get behind. I think the amount of instances covered by the original proposal but not by this proposal is vanishingly few. (As a minor and moot point, I'm not sure if we can technically de-CU or de-OS a user, since WP:ARBPOL gives those duties to ARBCOM, but of course ArbCom will remove the permissions from a site-banned user.) Galobtter (talk) 17:33, 18 April 2023 (UTC)
• Support This proposal won't really solve the problem of unaccountable admins or the need for a community desysop procedure, and will in practice probably never be used. But it's something, and really, it should work this way regardless.— Preceding unsigned comment added by Writ Keeper (talk • contribs) 17:35, 18 April 2023 (UTC)
• Support, noting that in the Athaenara case several arbs implied they would do this anyways if it came to it. It's a little odd how this interacts with non-admin-tier rights, but at the same time not really an issue, since most of those can all be restored at any admin's discretion; the exceptions are EFM and EFH, but that's probably a good thing. I know I'd have no problem giving rollback back to a recently-unbanned user if the ban didn't involve rollback abuse or edit-warring, for instance. As to desysopping and decratting, I agree with HouseBlaster that this should follow the default rule that a discussion should only be closed by someone with the tools to enact it (or in the case of decratting, the authority to request a steward enact it). With de-CU and de-OS, a 'crat could close as "banned and referred to ArbCom regarding CU and OS" and start a pro forma case request. Like Galobtter, I very much doubt any committee will hesitate to remove rights in that situation. -- Tamzin^{[cetacean needed]} (she|they|xe) 18:05, 18 April 2023 (UTC)
• Support regardless of whether the original proposal passes. Of course, 99% of admins who do something even remotely sitebannable are going to be desysopped by the Committee (whether by level 1, level 2, or motion) well before the ban discussion is closed, and I hope arbitrators continue doing that without feeling that they need to defer to the community: the last thing I want to do is slow down the desysop process in straightforward and/or urgent cases. But in general I think the proposal does move us (very marginally) in the right direction toward additional admin accountability to the community, so I'm happy to support. Extraordinary Writ (talk) 18:33, 18 April 2023 (UTC)
• Support regardless of whether the original proposal passes; makes sense. Editors holding rights are expected to hold the trust of the community; if the editor is banned it is very clear that they have lost that trust. BilledMammal (talk) 19:58, 18 April 2023 (UTC)
• Support Not much more to add. Admins and 'Crats must retain the community's trust --Enos733 (talk) 20:06, 18 April 2023 (UTC)
• Oppose per my above oppose. I don't see what problem this fixes. What terrible thing happened that this will prevent? Lowering the workload for Arb? I don't see the workload as a problem. Dennis Brown - 2¢ 20:37, 18 April 2023 (UTC)

  What terrible result will come from this passing? As far as I can tell, this should have nearly 0 effect in a century of Wikipedia but that nil effect would be good. Animal lover |666| 12:10, 19 April 2023 (UTC)

• Support. It hopefully won't be needed often, but this does look like a process that the community can handle without needing an Arbcom case. - Donald Albury 20:40, 18 April 2023 (UTC)
• Support It takes an awful lot of misbehavior to earn a site ban, & most admins are very visible folk. Further, some of admins gained the bit back when standards weren't as high, & even if this never implemented, it'll serve as a sword of Damocles to check admins from being too enthusiastic with the bit. -- llywrch (talk) 21:10, 18 April 2023 (UTC)
• Weak oppose It's like saying that a person who can't do basic addition isn't allowed to teach math in a university. No argument with that, but it's something that will never get used and so not worth messing with. North8000 (talk) 21:17, 18 April 2023 (UTC)

  And, BTW this is a better proposal than the initial one. North8000 (talk) 17:29, 19 April 2023 (UTC)

• Support even if seldom used, this will be a start for community based decisions. Graeme Bartlett (talk) 23:19, 18 April 2023 (UTC)
• Support contains the spirit of the original proposal without the drama-adding elements. --Rschen7754 23:24, 18 April 2023 (UTC)
• Support as a minimum. AndyTheGrump (talk) 23:56, 18 April 2023 (UTC)
• Support for the same reasons I !voted support above. -FASTILY 02:09, 19 April 2023 (UTC)
• Support simple and straightforward. Legoktm (talk) 03:57, 19 April 2023 (UTC)
• Support in addition to supporting the original proposal above. An admin who draws a CBAN is even more obviously not trusted by the community. --RL0919 (talk) 06:08, 19 April 2023 (UTC)
• Support, as a CBAN is a clear indication of the loss of the community's trust. ScottishFinnishRadish (talk) 13:57, 19 April 2023 (UTC)
• Support per WTT. Ajpolino (talk) 14:59, 19 April 2023 (UTC)
• Oppose - this isn't a logical extension of the original proposal, which was to procedurally remove the tools from admins blocked for a significant term, considering that blocks are to prevent editing disruption. There's generally no consensus that blocks can be used to respond to administrative misconduct, that's why we have WP:LEVEL1. Any admin who blocks another admin because of an administrative action is likely to be the first mover in a wheel war, and we should not introduce ambiguity to that policy. An administrator who is banned by the community is likely to be blocked anyway, and would have their permissions removed after 28 days if the above proposal passes or after a year under current policy; I don't see why this is necessary. However, the extension is a backdoor to create a community desysop process by which the only way for the community to remove admin rights is to ban the admin, even if their edit history is spotless. That's too heavy-handed, and it's absolutely going to be abused by bad actors to intimidate or eliminate administrators that get in the way of their tendentious agendas. It's a step too far, especially considering it's a first step. Ivanvector (^Talk/_Edits) 16:14, 19 April 2023 (UTC)

  In what circumstances do you envision a community consensus to ban an admin "if their edit history is spotless"? --RL0919 (talk) 20:10, 19 April 2023 (UTC)

• Support as a start. If you mess us enough to get yourself community banned, then you're clearly not suitable to hold advanced user rights. SkyWarrior 17:50, 19 April 2023 (UTC)
• Weak oppose based on the current wording. I think this is a solid idea, but I'd like to see it clarified that if an appeal finds that the original close was improper (incorrect reading of consensus, involved admin, wheel warring, things of that nature) rather than an appeal determining that the ban was valid but should now be lifted, then permissions should be restored. The Wordsmith^{Talk to me} 18:25, 19 April 2023 (UTC) Switching to Support as I had missed part of the proposal. It seems like a good idea and a fairly obvious change to be made. The Wordsmith^{Talk to me} 20:38, 19 April 2023 (UTC)

  That should be inherent in the last line of the proposal. Reversal due to "Community mistake". There are many ways in which mistakes could be made in a discussion. From the proposing, through to the closure. I don't think we could list them all. But should it be determined that the ban was done in error, then the granted tools should be restored. Essentially undoing a "miscarriage of justice". - jc37 19:28, 19 April 2023 (UTC)

  Somehow my eyes managed to skip over that entire line, I do see now that my issue is already addressed. I'll update my statement accordingly. The Wordsmith^{Talk to me} 20:37, 19 April 2023 (UTC)

• Support other have already said everything I could say. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 21:30, 19 April 2023 (UTC)
• Support this is better than nothing, but it is vastly inferior to the original proposal. The bar for admin accountability on this site is still way too high. LEPRICAVARK (talk) 01:56, 20 April 2023 (UTC)
• Support per my comments above. TonyBallioni (talk) 02:05, 20 April 2023 (UTC)
• Support Andre🚐 02:49, 20 April 2023 (UTC)
• Oppose. I do not see the practical need for this instruction creep (WP:CREEP). Community bans of admins are hopefully very rare (has there ever been a case?), and there is no reason to believe that ArbCom would not promptly desysop an admin who has been properly banned by the community (if only because they can no longer legitimately use their tools). The problem with this proposal is that it would incentivize people to use ban discussions as a proxy for a desysop by community consensus, which so far the community has declined to institute for what I think are good reasons. Sandstein 07:20, 20 April 2023 (UTC)
• Support I think usage othis will be incredibly rare but it's conceptually sound. Best, Barkeep49 (talk) 07:52, 20 April 2023 (UTC)
• Suppport noting that this doesn't conflict with the primary proposal here so, despite the title, it's not in any meaningful sense an "alternative". I'm supporting it as a complementary idea.—S Marshall T/C 08:01, 20 April 2023 (UTC)
• Support in parallel to the primary proposal. As WTT said, If a site ban passes on an admin, they should no longer be an admin. firefly ( t · c ) 08:25, 20 April 2023 (UTC)
• Support in addition to the proposal below. Beyond My Ken (talk) 09:11, 20 April 2023 (UTC)
• Support - Seems straightforward that if a user does not have the trust of the community to edit Wikipedia, they don't have the requisite trust to be an admin. Compatible with WTT's proposal above. WJ94 (talk) 09:21, 20 April 2023 (UTC)
• Oppose, solution looking for a problem. Stifle (talk) 10:12, 20 April 2023 (UTC)
  • To add to this comment, this solution would be a witch-hunters' paradise. It takes a week, and a massive stressful process, to grant adminship. Removing adminship based on a pile-on on ANI is a desperately bad idea. There's a reason WP:QKP was killed off. Stifle (talk) 08:36, 12 May 2023 (UTC)
• Oppose a rare occurrence like this can be handle by ArbCom. Such a rule would encourage even more gaming of the system (campaign for a long block on an admin you don’t like to end them for good). Jehochman ^Talk 12:18, 20 April 2023 (UTC)

  Hi Jehochman. The survey about long blocks is before this one. This one concerns site bans. - jc37 13:07, 20 April 2023 (UTC)

  Same logic, different terminology. (I did copy and paste.) This proposal is even more unnecessary because it addresses an extremely rare situation. If an administrator gets sitebanned, ArbCom should definitely be looking into it to understand what happened (compromised account, etc.). Jehochman ^Talk 19:22, 20 April 2023 (UTC)

• Support per WTT Pharaoh of the Wizards (talk) 16:35, 20 April 2023 (UTC)
• Support a bit narrow but I don't see any problems with this —pythoncoder (talk | contribs) 18:09, 20 April 2023 (UTC)
• Support This sounds good too. - Who is John Galt? ✉ 21:33, 20 April 2023 (UTC)
• Support, but I can't believe this is even a question. You mean to tell me that a banning doesn't mean you lose your privileges? Ok, so if I get banned you are telling me I still get to keep my autoconfirmed, rollbacker, and pending changes reviewer status rights, or is it only admins that get to keep tools? That is ridiculous. Huggums537 (talk) 05:46, 21 April 2023 (UTC)
• Weak oppose as pointless instruction creep, per Dennis Brown, Jehochman, Sandstein. If an admin gets cbanned, I would imagine they would be pretty uncontroversially and with minimum additional drama be de-adminned by Arbcom using their Level II procedures. This situation is fortunately sufficiently rare that we don't need additional policy to sidestap that existing solution. I'm opposing this variant only weakly, as opposed to original proposal, since by applying simply to cbans and not imposing arbitrary timelines, the instruction creep is more manageable. But it's still unnecessary. Martinp (talk) 15:05, 21 April 2023 (UTC)
• Oppose as pointless - it appears this situation has never happened in recent history. * Pppery * _{it has begun...} 21:18, 21 April 2023 (UTC)
• Support as codifying what should be common sense. Giraffer ^{(talk·contribs)} 14:34, 22 April 2023 (UTC)
• Support, provided that an amendment is made to indicate that it must be an indefinite site ban, so that we don't see silly things like a five-minute site ban being proposed as a "backdoor desysop". Seraphimblade ^{Talk to me} 15:44, 22 April 2023 (UTC)

  Done - I already noted it did not include limited bans, but added the clarification anyway. - jc37 16:29, 22 April 2023 (UTC)

  Although of course tomorrow the community could invent a fixed-duration site ban, with the historical concept of a site ban, it's always indefinite. Editors are site banned when they are no longer welcome to be participate at all in the English Wikipedia community. It's not a situation that times out without an appeal. isaacl (talk) 04:03, 23 April 2023 (UTC)

• Support While I acknowledge that the cases where this could apply are likely small which gives me reason to oppose, I think this is the best possible way to handle community based desysop proposals. We've been trying to untie this gordian knot for almost 20 years without success. It's been clear for a long time now that we need such a process. I can see how this process could have problems; a single administrator closing the discussion to CBAN? Hmm. Gang mentality polluting the results? Hmm. Sockpuppeters coming out of the woodwork after their favorite target? Hmm. I think the process can weather that. I would like to see one caveat applied though; CBAN "discussion must be kept open for 72 hours except in cases where there is limited opposition and the outcome is obvious after 24 hours". The 24 hour statement shouldn't apply in this case, instead requiring 72 hours. --Hammersoft (talk) 17:23, 23 April 2023 (UTC)
• Weak support I don't think this is needed, as it is rare and there are existing venues to deal with this situation, but it may avoid needless redundant paperwork. — xaosflux ^Talk 23:00, 24 April 2023 (UTC)
• Support - a natural, I'd say merely technical extension of ban. Lokys dar Vienas (talk) 03:56, 25 April 2023 (UTC)
• Support in that it's 1) a higher threshold, 2) consistent across permissions, such that, if I remember correctly, it would have been useful--even if just as a principle--in some of the old bot operator/automated editing conduct issues. Jclemens (talk) 04:25, 25 April 2023 (UTC)
• Support, as reaching a consensus for an indefinite siteban is a clear, existing way for the community to express a complete loss of trust. ~ ToBeFree (talk) 07:22, 25 April 2023 (UTC)
• Oppose. Unnecessary, a solution in search of a problem. Nsk92 (talk) 11:47, 25 April 2023 (UTC)
• Support This formalises what should be obvious. talk to !dave 12:15, 25 April 2023 (UTC)
• Support.--Jerome Frank Disciple (talk) 13:57, 25 April 2023 (UTC)
• Oppose as an absurd weakening of the original proposal. Figureofnine (talk • contribs) 14:49, 25 April 2023 (UTC)

  These proposal are not exclusive. — xaosflux ^Talk 12:45, 27 April 2023 (UTC)

• Support: a plainly fine proposal; far better than nothing. ~ Pbritti (talk) 19:39, 25 April 2023 (UTC)
• Neutral. I'm not substantively opposed to this proposal as I believe it reflects common sense: obviously a site-banned administrator has lost the confidence of the community and should be desysopped. However, like the original proposal, I see this as a bit of a solution looking for a problem, and I do not foresee that it will produce any tangible improvement to current process. We site-ban administrators exceedingly rarely—the threshold for a desysop is much lower than the threshold for a site-ban. If an administrator is under discussion for a site-ban, I would expect that a request at WP:ARC will have already been filed in parallel, and as I mentioned earlier, recent examples have shown that ArbCom is perfectly capable of expeditiously desysopping administrators where necessary. Mz7 (talk) 21:44, 25 April 2023 (UTC)

  Just wanted to add a bit to this to explain why I am "neutral" on this alternative proposal and "oppose" on the main proposal. I am more sympathetic to this alternative proposal because a site ban is a higher bar to clear than a block. A site ban requires clear community consensus at an administrative noticeboard, whereas a block can be imposed unilaterally. The consensus for a site ban can become clear pretty efficiently: I've seen cases at WP:AN where we've site-banned editors within a day or two (although because of the invention of WP:3X, site ban discussions are quite rare nowadays). This is in contrast to the required 28-day window from the main proposal.

  If we pass this alternative proposal, I can see cases where if an administrator does something so egregious that they need to be blocked indefinitely, the community would then have two avenues to desysop the admin: (1) start a site-ban discussion, or (2) request a desysop at WP:ARC. The reason I am "neutral" and not "support" is because I believe the existing process of requesting the desysop at WP:ARC already works as efficiently as a site-ban discussion (and may even be preferable because ArbCom is generally more evidence-focused and deliberative than the free-for-all style of WP:AN). Also, I am worried that this will lead to situations where we go for a site-ban on a blocked administrator where a simple indefinite block would have sufficed, just so that we can desysop them (a block can be overturned unilaterally whereas a ban requires community consensus to overturn). Mz7 (talk) 21:12, 27 April 2023 (UTC)

• Oppose as unnecessary any C-banned admin would almost certainly be desysoped by Arbcom. Lightoil (talk) 08:39, 26 April 2023 (UTC)
• Support Seems like a great idea to me. -- Grapefanatic (talk) 14:45, 26 April 2023 (UTC)
• Oppose at the moment any admin who was community banned would likely be desysopped by motion from arbcom. So if this went through there would either be no meaningful change, or we'd have a bunch of attempts to ban particular admins, with some people supporting the ban as the most effective way to desysop that admin, and others saying that they hope arbcom does a desysop but they don't think a ban is merited. If there is any scope for a community desysop it is to deal with people who arbcom would not desysop, but where the people who elect arbcom want to be harsher than arbcom. That group won't overlap with the people who merit a ban. ϢereSpielChequers 14:58, 26 April 2023 (UTC)
• Oppose; redundant proposal as the ArbCom can order an emergency desysop if needed. I agree site-banned users should not hold advanced rights but this proposal could be gamed, would create much dramah and become unworkable. Baffle☿gab 21:01, 26 April 2023 (UTC)
• Oppose per WP:CREEP. Still a solution in search of a problem. Passing more rules just for the sake of passing more rules is something I typically associate with politicians and (some) civil servants who need to justify their paycheck. -Ad Orientem (talk) 21:04, 26 April 2023 (UTC)
• Support in combination with the primary proposal. Long blocks and bans should mean de-sysoping, and a successful ban appeal should not mean an automatic restoration of the bit. Way too much abuse of the tools goes on, and anything that curbs that would have to have some pretty enormous downsides to lose my support. —swpb^{T • beyond • mutual} 17:50, 27 April 2023 (UTC)
• Support per Worm. ~ 🦝 Shushugah (he/him • talk) 22:57, 27 April 2023 (UTC)
• Support a reasonable thing that sould happen. I don't see the need for arbcom to pro forma vote to desysop someone here. --In actu (Guerillero) ^{Parlez Moi} 07:51, 28 April 2023 (UTC)
• Support as better than nothing, even if it's only used rarely. Hard to think of any case where an admin is banned, yet still trusted enough to keep the tools. DFlhb (talk) 16:47, 28 April 2023 (UTC)
• Strong support. I don't see a world where a user who is so distrusted to be banned is trusted to be an admin... CLYDE ^{TALK TO ME}/_{STUFF DONE} 21:22, 28 April 2023 (UTC)
• Support Being allowed to resume editing is a different kettle of fish to having one's advanced privileges restored. MrsSnoozyTurtle 05:01, 29 April 2023 (UTC)
• Neutral Makes sense, but it seems unlikely that existing processes (i.e. an ArbCom motion) wouldn't already handle this. Anomie⚔ 14:56, 29 April 2023 (UTC)
• Strong support per my comment in the original proposal. Removing admin rights should be done automatically when such user is blocked or banned. RFA is the venue to regain their rights. Callmemirela 🍁 18:03, 29 April 2023 (UTC)
• Support as superior to the original proposal. If an admin is site-banned by the community, then their privileges should be immediately revoked, full stop. I don't see a reason why this should need to be sent to ArbCom.-- Aervanath (talk) 10:09, 3 May 2023 (UTC)
• Basically in agreement with the above supports: sure, not mutually exclusive. I'd go much, much farther, but as above, at least it's something. ~ Amory (u • t • c) 12:27, 3 May 2023 (UTC)
• Support – seems like common sense, and in general I support making it easier to revoke adminship, as I explained above. —Mx. Granger (talk · contribs) 13:20, 4 May 2023 (UTC)
• Support at the same level as the original proposal. Aasim - Herrscher of Wikis ❄️ 16:16, 4 May 2023 (UTC)
• Support Thought this was done as a matter of course already; ArbCom shouldn't be in charge of literally everything. – John M Wolfson (talk • contribs) 01:37, 6 May 2023 (UTC)
• Support. Side note, while I do think both of these proposals essentially codify something that would almost certainly happen anyway through existing processes (Level II), and if we could only have one procedure I would probably prefer one that's separate from any blocks or bans, but we can have more than one and I doubt we'd get to the point of it becoming CREEP unless we somehow decided to start adding new "things that gets admins' bits removed by the community" to the list every week or two. Alpha3031 (t • c) 11:13, 6 May 2023 (UTC)
• Oppose Needs to be any ban (including topic). Only in death does duty end (talk) 11:38, 10 May 2023 (UTC)
• Support it's somewhat incredible this wasn't adopted in some form about 15 years ago. —Rutebega (talk) 19:56, 11 May 2023 (UTC)

Discussion (alternate community desysop proposal)

There's a couple suggestions above that the discussion should be closed by a crat. Since the desysopping would be a consequence of the ban by policy but not explicitly part of it, I don't think this needs to be the case. I feel like this is a case where the admin closing could simply leave a note at WP:BN, as is done with ArbCom desysops. Galobtter (talk) 18:21, 18 April 2023 (UTC)

I agree. Closure by an uninvolved admin is fine. Thryduulf (talk) 11:56, 19 April 2023 (UTC)

If this were likely to be relevant soon for a specific admin, it may have required a bureaucrat; however, since this is clearly not the case, admin closure should sefice. Animal lover |666| 13:54, 19 April 2023 (UTC)

I am somewhat concerned that this might end up (to a greater degree than the slow 28 day process) be used in some cases to force a desysop through banning someone, when their actions would not otherwise have led to a CBAN. I'm not sure whether mitigation with stressed clarity that a !vote seemingly acting to ban only as a means to desysop. Nosebagbear (talk) 20:43, 19 April 2023 (UTC)

I hope the community isn't so cruel as to site ban just to cause a desysop, but I agree there is a perverse incentive here - but I feel like that equally applies to the original proposal. Galobtter (talk) 02:52, 20 April 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.

Alternate proposal (Arbcom Level II desysop of long-term blocked admins)

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

---

Let's address the issue without gameable instruction creep and with minimum changes to existing policies for what are very rare cases. Arbcom can already desysop an admin under WP:LEVEL2 if "(a) the account's behavior is inconsistent with the level of trust required for its associated advanced permissions, and (b) no satisfactory explanation is forthcoming." Doing so doesn't take the weeks or months of an active or suspended arbcom case, just a vote by Arbcom. Therefore, if there is any ambiguity, let's just resolve the situation by affirming the statement in the next paragraph. Then in the rare cases an admin ends up in this situation, sua sponte or on request any arbitrator can propose a Level II desysopping and the Committee can effect it by voting. They will presumably do this with a minimum of fuss, but with a bit of consideration/deliberation as to whether there are any exceptional circumstances, and whether sufficient time has passed for it to become clear that the user in question will remain blocked for some time.

Statement: The community affirms that engaging in behaviour that leads to an admin becoming and remaining long-term blocked (or banned), for cause, is generally inconsistent with the level of trust required for retaining administrator permissions. Arbcom is empowered (alternative: directed?) to act per its existing policies (currently WP:LEVEL2) to deal with such situations.

Editing since forgot to sign: Martinp (talk) 18:10, 19 April 2023 (UTC)

Survey (alternate proposal for Arbcom Level II desysop of long-term blocked admins)

• Oppose For pure WP:BURO reasons. I do not see anything this proposal does that Arbcom does not already do, via their string of measures. A "please do this" from the community to Arbcom isn't enough. And the biggest draw of the other proposals for me was simply "Having more community measures to desysop" instead of putting even more things strictly at Arbcom alone.

In fact, I cannot imagine a single scenario where Arbcom would block or ban someone without de-adminning, making this even more of a rules creep. At least the others were explicitly "community decision" instead Soni (talk) 02:42, 20 April 2023 (UTC)

• Support in the event no other proposals here gain consensus (in which case I oppose this as redundant). ArbCom issues "community reminders" all the time; why can't we do the same to ArbCom? HouseBlaster^talk 03:01, 20 April 2023 (UTC)
• Oppose, instruction creep. ArbCom is elected and can be trusted to make this (rather obvious) determination on a case-by-case basis. Sandstein 07:22, 20 April 2023 (UTC)
• Oppose because this is not a process that offers the community any role in desysopping.—S Marshall T/C 07:59, 20 April 2023 (UTC)
• Oppose I don't see what the purpose of this is. Beyond My Ken (talk) 09:11, 20 April 2023 (UTC)
• (edit conflict) Oppose. This is not the way to amend arbitration policy, and will be wholly redundant to either of the first two proposals here. Thryduulf (talk) 09:11, 20 April 2023 (UTC)
• Oppose. This just seems like adding a bit more bureaucratic waffle, without achieving anything concrete. Boing! said Zebedee (talk) 10:03, 20 April 2023 (UTC)
• Oppose Doesn't ArbCom already have the power to desysop people? Why are we just reconfirming what they already do? --Jayron32 12:03, 20 April 2023 (UTC)
• Oppose because this isn't a proposal to change anything of substance. AndyTheGrump (talk) 12:06, 20 April 2023 (UTC)
• Neutral: I agree with the statement above but it is already the case the ArbCom removes admin rights from banned users. The statement is not a proposal for a community-based desysop process. Baffle☿gab 21:09, 26 April 2023 (UTC)
• Oppose per most of the above and WP:CREEP. Still a solution in search of a problem. -Ad Orientem (talk) 21:13, 26 April 2023 (UTC)
• Oppose. Is this not exactly what ArbCom already does? CLYDE ^{TALK TO ME}/_{STUFF DONE} 21:31, 28 April 2023 (UTC)
• Support-ish This doesn't really do anything other than restating the obvious: someone long-term blocked or banned probably has lost the trust of the community, and WP:LEVEL2 exists allowing ArbCom to remove the bit if they want. Anomie⚔ 14:56, 29 April 2023 (UTC)
• Oppose The more I read these proposals the more I see unintended outcomes and I'm beginning to wonder if I misunderstand the true purpose behind additional, unnecessary rules. Chris Troutman (talk) 18:37, 29 April 2023 (UTC)
• Oppose Does not address the actual problem. Only in death does duty end (talk) 11:39, 10 May 2023 (UTC)

Discussion (alternate proposal Arbcom Level II desysop of long-term blocked admins)

Since my proposal is garnering quite a lot of opposition, let me explain my thinking. In my view, yes this changes very little. I view it as uncontroversial that in many (most?) circumstances, being blocked long-term for cause is clearly incompatible with the level of trust needed to continue holding adminship. So I would like to think that if some admin ends up in that circumstance, Arbcom could just de-admin them for conduct unbecoming. However, there is significant functionary (including Arb) support for the present "community procedural de-admin" proposal, with specific bright line criteria. This support presents as the alternative being avoided a "long, drawn out arbitration case". So I'm proposing to explicitly just say, "yeah, Arbcom, go ahead and pull the bit using L2 without too much fuss where warranted" as a less bureaucratic solution to a rare problem then a convoluted "community procedural" process, one where we're needing to wordsmith ahead of time exactly what the block age and duration should be, what kind of block counts, etc. Basically, I feel we actually don't need more rules to solve a rare problem. However, since Arbcom members seem (implicitly) unsure if they have the authority to desysop someone just because the community has decided to block them for a long time, reassure them that they already do. Martinp (talk) 19:38, 20 April 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.

Alternate proposal: the community supports development of a de-sysop process

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

---

Let's stop beating around the bush and just propose this:

The community supports the development of a community based process for removing administrator rights for cause outside of the current arbitration committee procedures. If this proposal closes with consensus, the community directs that a binding RfC be opened within 30 days where community members may submit proposals to determine the process.

Survey (Alternate proposal: the community supports development of a de-sysop process)

• Support determines the actual consensus on the principle of the matter, and establishes a procedure to determine how to implement the consensus on the principle if it exists. Much better than picking around the edges. If there is a community consensus on the principle, let us establish that and then determine what the method of implementing it should be. TonyBallioni (talk) 02:10, 20 April 2023 (UTC)
• Support I've long assumed this first part describes the community's desire (though I suppose we'll see here). It's the second part, actually finding details of such a process, that folks seem to struggle with. But another RfC is certainly worth a try. Ajpolino (talk) 02:27, 20 April 2023 (UTC)
• Support This is most in line with what I would like to see. I worry that this structure guarantees another no consensus (being too similar to the last N failed RFA reforms, and apparently the other DESYSOP proposals). But I would like community desysop to happen, and supporting this is more preferable than standing in the way. Soni (talk) 02:46, 20 April 2023 (UTC)
• Support. I think where the earlier proposals fail is in trying to make this work within the existing block framework, when what is actually required is a concrete mechanism by which sysops who have lost the confidence and trust of the community can be de-sysoped. Patr2016 (talk) 02:57, 20 April 2023 (UTC)
• Support I guess, but I am not very optimistic that it will end in a real process. --Rschen7754 03:11, 20 April 2023 (UTC)
  • Oppose just because the "waste of time" argument is too strong. Maybe in another year. --Rschen7754 04:24, 26 April 2023 (UTC)
• Support. I agree with the principle, and while I reserve the right to say "I told you so" when the RfC ends up with too many proposals, too few participants, and no consensus, I agree with Soni that supporting this is more preferable than standing in the way. An oppose !vote certainly wouldn't make community desysop more likely to happen. Extraordinary Writ (talk) 06:23, 20 April 2023 (UTC)
• Support. I don't expect this to work but it is worth trying. BilledMammal (talk) 06:57, 20 April 2023 (UTC)
• Oppose. I frankly don't see the practical need for yet another drama-laden process. From what I can tell, the ArbCom process works rather well, as in the recent Dbachmann case. If and when we have a specific case where ArbCom declines to desysop a person who's obviously unfit for the job, then we can and should have this discussion. Sandstein 07:24, 20 April 2023 (UTC)
• Theoretical support, actual oppose. I support community desysop but for the reasons I mention here I find this proposal to get there not to be fully thought out or practical. Barkeep49 (talk) 07:42, 20 April 2023 (UTC)
• Oppose. This seeks to replace the practical, workable ideas already on the table with no tangible offer at all.—S Marshall T/C 07:57, 20 April 2023 (UTC)
• Oppose Per Barkeep and S Marshall. I support in theory, but not in practise. We have a couple of small step solutions here that are thought out. Scrapping the work above and hoping that a binding RfC which has failed twice in recent years is not a solution. Worm^TT(talk) 08:09, 20 April 2023 (UTC)
• Oppose per Barkeep et al. This is a fine idea in theory, but I fear it won't actually result in any real change. IMHO - best to take iterative steps toward a solution than start a(nother) large discussion. firefly ( t · c ) 08:22, 20 April 2023 (UTC)
• Weak support, this is much better than the original proposal where we would just make up the rules as we go along the next time an admin is blocked. I do think we can usually leave things to ArbCom, though; a slow and deliberative process is likely better than things like Wikipedia:Requests for comment/Kelly Martin/original. —Kusma (talk) 08:42, 20 April 2023 (UTC)
• Support - OMG, this is so freaking overdue, yes, yes, yes. Beyond My Ken (talk) 09:02, 20 April 2023 (UTC)
• Oppose at the moment. If either of the first two proposals on this page get consensus this will be redundant to them, if they don't then I can't see the point in spending more time developing a more complicated and drama-laden version of the same thing. Also per WTT et al. Thryduulf (talk) 09:16, 20 April 2023 (UTC)

  I mostly support because I hope the new process will be less drama-laden than turning every discussion about the block of an admin into a desysop discussion happening in an undefined location (the user's talk page? ANI?) under undefined rules. —Kusma (talk) 09:33, 20 April 2023 (UTC)

• Oppose, essentially per Barkeep49, S Marshall, Worm That Turned, though support in principle for a future time and place. Every proposal for a fully worked-out community desysop has failed. Part of the problem is that all sorts of alternative proposals come up, and we get lots of partial support for them. But with everyone tugging in a different way, nothing gets done. Every single time - absolutely nothing. So, while we have a couple of clear and simple proposals going here, please let's not derail things yet again. I say let's see how the simple proposals here work out, and then revisit a full community desysop proposal at a future time. Ideally, I'd like us to have a full community desysop. But if we try it here and now, I think it's almost certain that the only achievement will, yet again, be nothing at all. We've tried running too many times. We need to walk first, one step at a time. Boing! said Zebedee (talk) 10:07, 20 April 2023 (UTC)
• Oppose - it's not like it's been eons since the last time we went through this. So oppose per Worm et al. Also, functionally all RfCs are intended to be binding, so not sure what that was intended to add. Nosebagbear (talk) 10:13, 20 April 2023 (UTC)
• Support, though I am not sure we will end up with anything, like the last trillion times. Stifle (talk) 10:16, 20 April 2023 (UTC)
• Support, but I will not be volunteering to run it. :D Valereee (talk) 11:05, 20 April 2023 (UTC)
• Oppose, am swayed by Barkeep49, S Marshall, Worm That Turned and Boing! said Zebedee. Hiding T 11:23, 20 April 2023 (UTC)
• Support - a simple statement with the backing of consensus, affirming at a high level that the community desires a community desysop process. We always start with a proposal, then figure out what problems it solves, then ask if we actually want to solve those problems. Of course they fail, we're doing it entirely backwards. We need a discussion or process to flesh out what the problems are that the community wants to solve, and really only then can we constructively discuss how to solve them. But the first step of all is to determine whether or not the community actually wants such a process at all. I mean, I think it's pretty clear from the years and years of discussions and proposals, but I don't think we've ever really formally asked. Ivanvector (^Talk/_Edits) 11:53, 20 April 2023 (UTC)
• Oppose perversely because it's to easy to oppose. Making a swiping change that gets a majority agreement is extremely hard, because different groups will oppose different parts. Maybe if the community was split into two simple groups (as some editors appear to beleive it is) then it would be possible to get a 51% majority victory. But realistically getting a majority of editors to agree on such a big change is like herding cats. Incremental changes like those already suggested are much more likely to succeed. The recent inactivity requirements are a good example. -- LCU ActivelyDisinterested ∆transmissions∆ °co-ords° 11:58, 20 April 2023 (UTC)
• Oppose as pointless. The community has the power already to start such an RFC. No need to re-affirm what we could already do. If an editor or group of editors wishes to workshop an idea that might have a chance of gaining widespread consensus, they can just do so. They don't need a special RFC to empower them to do so. The barrier is not that proposals aren't made; the barrier is that no such proposal has gained consensus. --Jayron32 12:05, 20 April 2023 (UTC)
• Support I sympathize with those who object that this will preempt the proposals above, but realistically the only proposal above likely to pass is the one about desysopping a sitebanned admin, and that's honestly a pretty redundant proposal since a desysop in that case would be inevitable anyway. LEPRICAVARK (talk) 13:50, 20 April 2023 (UTC)
• Oppose in this context, where it is presented an alternative to the more specific process changes that are already under discussion. --RL0919 (talk) 15:40, 20 April 2023 (UTC)
• Hesitant conditional support. Contra several respected colleagues above, I don't see why this would derail the above proposals, which I also support: but for the sake of clarity, my support is conditional to this proposal not overturning consensus on the previous two. As to the rest, I'm hesitant about the "binding" bit; I don't want us to end up stuck with a bad proposal because nothing better reached consensus in a binding RfC; but I suppose I trust that our general opposition to change that is not fully thought through will handle that. Vanamonde (Talk) 16:26, 20 April 2023 (UTC)
• Oppose this is somewhat pointless, since there is nothing stopping anybody from starting an RfC or making a proposal on the subject anyway. Unless it's supposed to mean that we have to establish a community desysop process and the RfC is just to establish what it will look like, but I don't think that's a good idea. While community desysop is a good idea in theory a lot of the proposals end up being rather susceptible to lynch mobs and will probably make things worse. Hut 8.5 18:35, 20 April 2023 (UTC)
• Support Yes, this would also work. - Who is John Galt? ✉ 21:35, 20 April 2023 (UTC)
• Oppose. The lack of consensus in previous discussions about this, combined with flare-ups in drama in some high profile admin misconduct cases, lead me to believe it is best to leave desysopping for cause to Arbcom. That's a process that we've shown works reasonably well in cases of egregious misconduct. I would be much more inclined to support term limits on all admins in some way (e.g. reconfirmations after x years), with some sort of protection against grudge-bearing etc., since that would work better against the (perceived) issue of out-of-touch admins throwing their weight around on the boundaries of what they can get away with. Martinp (talk) 12:17, 21 April 2023 (UTC)
• Oppose per Sandstein and Boing!. I'm not sure what problem we are really solving and it seems unlikely that another RfC would actually lead to anything useful. Galobtter (talk) 21:53, 24 April 2023 (UTC)
• Support Fuck it, I think such a process is inevitable, and "something is better than nothing" here (even with the risk of action bias). – John M Wolfson (talk • contribs) 23:28, 24 April 2023 (UTC)
• Oppose: I'm fine with "the development of a community based process for removing administrator rights for cause outside of the current arbitration committee procedures", but the RfC the proposal asks for is happening here already. I'd especially not want one to be held if one of the above proposals already passes. ~ ToBeFree (talk) 07:31, 25 April 2023 (UTC)
• Support in principle, pending enough detail to make a more informed comment. Certes (talk) 10:16, 25 April 2023 (UTC)
• Oppose That's right, I would like this process to open another process to gain another process. Process? talk to !dave 12:17, 25 April 2023 (UTC)
• Weak support It would be better to focus the effort on giving more routine review and feedback such as tuning up and taking the poison pills out of WP:Administrative action review. Arbcom can handle the rarer severe desysop cases. But I 'spose it would be good to have some community route in place. And also to methodically decide on and float optimum proposal in order to resolve this question. North8000 (talk) 12:43, 25 April 2023 (UTC)
• Support I don't see why this has to be an alternative, but yes it is a good idea. I can't think of a reasonable reason to oppose this, as clearly there needs to be an easier way to put the brakes on misbehaving and unfit administrators. Figureofnine (talk • contribs) 15:55, 25 April 2023 (UTC)
• Oppose. My view is that the current process works sufficiently well. In other words, there is no need to develop "a community based process for removing administrator rights for cause outside of the current arbitration committee procedures". The proposal is not clear in describing what ways the current process is deficient, other than merely saying we want an alternative. Mz7 (talk) 21:33, 25 April 2023 (UTC)
• Oppose. As others have noted, it's not clear that there is any actual pressing problem (or any consensus that there is a problem) that we need to find a solution to. People should certainly continue to feel free to propose any bright new ideas that they have, but if there isn't a consensus for any of these proposals it's hard to see the point of an additional binding RfC. We'd just be progressing from one round of policy churn to another. -- Visviva (talk) 22:13, 25 April 2023 (UTC)
• Oppose. Please god no, no more RfC-trainwrecks. – Joe (talk) 04:19, 26 April 2023 (UTC)
• Oppose Our current process of removal of administrative tools works just fine. Lightoil (talk) 08:42, 26 April 2023 (UTC)
• Oppose per most of the above and WP:CREEP. Still a solution in search of a problem. -Ad Orientem (talk) 21:11, 26 April 2023 (UTC)
• Oppose, as unnecessary, a solution in search of a problem. There is precisely zero evidence that the current arbcom desysop for cause process is insufficient and somehow fails to remove admins who should be removed because of abuse/misuse of admin tools. I would support some version of term limits for admins, requiring a reconfirmation RfA to retain the tools, but that's very different from a community desysop for cause. Nsk92 (talk) 23:02, 26 April 2023 (UTC)
• Support, iff it includes Extraordinary Writ's option. Make it binding that the most supported option gets a six-month trial. Otherwise, this proposal is just the status quo, per Jayron32. DFlhb (talk) 16:41, 28 April 2023 (UTC)
• Strong support. Desysops should need not be taken all the way up to ArbCom. Even if the 2nd RfC doesn't develop consensus, change should still hopefully come per WP:BARTENDER. I support EW's option, but that should be discussed in the 2nd RfC. CLYDE ^{TALK TO ME}/_{STUFF DONE} 21:56, 28 April 2023 (UTC)
• Oppose You don't need an RFC about having an RFC. If you have a proposal that you think might actually get support, just propose it. If you want to workshop it first with like-minded people (good idea), go ahead and do it. The problem in the past is that no one has been able to come up with something that actually gets consensus, not lack of will to talk about it. Anomie⚔ 14:56, 29 April 2023 (UTC)
• Weak oppose as it's unclear as to what process the proposal is referring. Does it involve the community as a whole or established users? Furthermore, what "cause" would require for the community's input to desysop an admin? I feel desysop as part of a block then reaching to RFA to restore rights is the right process. I find this proposal unclear and vague, so I oppose for now as per Anomie above. Callmemirela 🍁 18:11, 29 April 2023 (UTC)
• Strong support - This is a proposal I can get around. I'm an advocate for a community-based desysop process without the explicit need for arbcom and this is a great start to initiate such a policy. The community should absolutely have a say and an opinion on site administrators who get to stay or go. — That Coptic Guy^{ping me!} (talk) (contribs) 20:44, 29 April 2023 (UTC)
• Oppose I have limited confidence, that an abstract RfC will actually lead to a clear outcome. I would rather ratify specific/limited recall processes, regardless of whether they're a step in the right direction or not, and shift the goal post to improving those policies instead of...inevitably...waiting for another perfect RfC proposal to come along. This is our chance and we should seize it. ~ 🦝 Shushugah (he/him • talk) 22:53, 27 April 2023 (UTC)
• Support failing the other two proposals above, this sounds like a good idea. Aasim - Herrscher of Wikis ❄️ 16:17, 4 May 2023 (UTC)
• Very strong support. I don't mean to sound hyperbolic, but I'm genuinely a little mystified by the number of "solution in search of a problem" takes on this rather non-specific proposal. Without question, the occasional need to take the mop back from a community member entrusted with it is an unfortunate but unavoidable concern, so the "problem" is very much concrete, and the specifics of how this process is handled have significant impacts. The only question, therefore, is whether we want this task to be the exclusive purview of ArbCom, and whether such an arrangement is the most rational and efficient state of affairs.
  As to the first part of that question, I've always gotten the impression that the community was widely supportive of a parallel process, but the more principle point is that I think it just makes good sense. I see no inherent problem with ArbCom continuing to do much of the heavy lifting in this regard, but I see no compelling reason why the community at large, with it's broader and more generalized mandate, should not have a detailed and agreed-upon process for quickly arresting problematic actors who managed to squeek their way into advanced tools, or were simply granted them in a more anarchic phase of the project's history.
  These may be relatively rare scenarios, but the damage that can be done to community cohesion and morale when the wrong personality is capable of abusing advanced permissions is significant, and in brightline cases, a laborious ArbCom brouhaha should not be the only option. Being entrusted with the bit should make a community member more inherently open to scrutiny, not for some reason suddenly unanswerable to the mere plebs who are also the sole source of that status (and the only ones who, as an institutional matter, can invest them with those tools in the first place). For a project based so fundamentally on the collective will of the community, in certain areas we sure have built up some fairly oligarchical twists to our systems, and this "the people we vote into advanced tools can only be stripped of them by the general agreement of just twelve community members" rule is one the most perplexing and irrational, in my opinion.
  So, as I see it, we're well past time to agree to a way forward for what is clearly something that is within the broader community's remit, and I think the real issue is figuring out a process which requires a robust community support for such CBAN-adjacent desysops, such that they don't take place unless there is support on a similar scale to that required by RfA itself. That is to say, so there is parity between community will for removing tools and the consensus needed to grant them in the first place (or something at least in the same ballpark). That can and should be an exhaustive and carefully-considered debate, but the question of whether the community should be able to exercise its prerogative on who can retain tools in the first place is, in a word, silly: with few caveats, every a priori principle of process on this project arises from community consensus--by quite conscious design and as a fundamental principle of the project. And even in this specific area, it's clearly that same broad community mandate which has the sole prescriptive function for investing these tools. So how can the broader community possibly lack the stature to remove those same tools in cases of abuse? SnowRise ^{let's rap} 09:52, 10 May 2023 (UTC)

Consensus for some sort of community desysop process has existed since 2019. The problem is that no one has been able to come up with a specific process that was able to gain consensus. Anomie⚔ 11:53, 10 May 2023 (UTC)

Sure, and to be honest, it's not surprising that there has been difficulty in nailing down the details of a specific procedure for that purpose. On the one hand, nobody wants a slapdash process for such an exceptional measure as desysop, and on the other, when it comes to community sanctions, there's reasons why the general community doesn't quite care for more structured and formulaic processes like those employed by ArbCom and AE. Finding a solution that both threads that needle and gets broad community support is unsurprisingly not the easiest thing in the world.

Still, I don't see how throwing our hands up in resignation can be considered a solution, and any oppose !vote here based on past difficulties is really missing the point, and abdicating our responsibilities for no concrete gain beyond a declaration of frustration, imo. Of course, no strawvote would be required in order for anyone to make a more concrete proposal for such a process at any time. But, realistically, because there were already proposals above at this moment in time, any additional proposal made in the near future would likely face calls for a procedural close because "we just talked about this".

So if I interpret the purpose of this alternative proposal correctly, it is to keep that door open by creating a clear community mandate to hash this issue out once and for all. Because it will be a real pity if the other proposals above lead to a procedural block on discussing the more general notion of a community desysop process in the near future. Because as you say, this general notion does have broad community support, even if we haven't been able to come to an agreement as to the particulars. So opposing just because of the past failures of particular groups of editors is not a particularly well reasoned-stance as regards whether the matter still warrants attention. SnowRise ^{let's rap} 05:56, 11 May 2023 (UTC)

• Support Actually for the same reason Jayron opposes, the only difference being I think editors do need to be reminded. I also find it hilarious to see opposes (to something that would potentially result in a genuine solution to the core issue) from admins who supported the complete non-solutions above (that are no solution to anything). Its almost as if Admins dont want their tools removed by the people who gave them. Who would have guessed at the conflict of interest there... Only in death does duty end (talk) 11:45, 10 May 2023 (UTC)

Discussion (Alternate proposal: the community supports development of a de-sysop process)

Isn't this just restarting WP:DESYSOP2019 and WP:DESYSOP2021? Galobtter (talk) 02:25, 20 April 2023 (UTC)

Yep, I thought we already reached this "consensus in principle" in DESYSOP2019. Personally I think the only way to break the logjam would be to add "if there is no consensus in the binding RfC for any one proposal, the proposal closest to gaining consensus will be implemented for a six-month trial" to the end of Tony's proposal above, but I'm well aware that there'd be plenty of resistance to that. Extraordinary Writ (talk) 02:36, 20 April 2023 (UTC)

Not really - a 4 year old consensus doesn't establish ground for acting now. I see this more in line with WP:RESYSOP 2019 and the initial principles RfC that established it. The method I proposed for DESYSOP2021 was me one person (me) coming up with a proposal. This would establish the principle, and then direct a RESYSOP2019 style RfC be held to implement. Re-establishing the consensus as a whole is useful, and then directing that a multi-proposal RfC is to be held paves the way. The multi-proposal/statement method tends to work better in these type of cases. TonyBallioni (talk) 02:41, 20 April 2023 (UTC)

I think WP:RFA2021 shows why that doesn't work, though: everyone puts forward their pet proposals, the discussion gets so long that nobody but the diehard policy wonks will take the time to wade through it, and we end up with no consensus. I don't really know what the solution is (maybe it's a brainstorming RfC followed by two or three well-thought-out proposals?), but I just find it hard to see a large multi-proposal discussion getting us any closer to consensus. Extraordinary Writ (talk) 02:59, 20 April 2023 (UTC)

Yeah, but the craziest proposals tend to not get enough support to have consensus, and are usually the later ones proposed. RFA2021 also had the problem (imo) of being about too many principles rather than a single one, and of being an RfC where some people (myself included) didn't participate because no one thought that substantive changes to things that were not RfA would be proposed there.

The differing statements method works well when you have a clearly defined controversial issue that there's agreement something should be done about but no one proposal has received consensus in the past. Things surrounding removal and return of permission is one of them where its worked in the past, imo. TonyBallioni (talk) 05:45, 20 April 2023 (UTC)

Resysop 2019 worked because once the first consensus was found, that it should be tightened, there was a somewhat limited number of ways so consensus could be found. I absolutely agree with EW that this is far more likely to turn into RFA21 where people opposed to community desysop will find flaws with every proposal, not in bad faith but because they genuinely have issues with the concept, as will people who are actually concerned about some specific of that proposal. Best, Barkeep49 (talk) 07:37, 20 April 2023 (UTC)

And there'll be people who don't participate in this RfC, who will then turn out to obstruct anything that by some miracle passes. If WP:RFA2021 didn't teach us that this format doesn't work, WP:ACAS should have. – Joe (talk) 04:39, 26 April 2023 (UTC)

Yeah that's a second reason Resysop 2019 worked: It didn't require on consensus to implement. Rather it empowered (required) a specific group of people to act so people who were unhappy with the result couldn't create a WP:LOCALCONSENSUS during implementation. Best, Barkeep49 (talk) 14:52, 1 May 2023 (UTC)

Yeah, let's not fall into the politician's fallacy, requiring that "something" be done just because it's something. Anomie⚔ 14:56, 29 April 2023 (UTC)

• I wrote up WP:RRA awhile back. It's a process for the community to review an admin's actions and potentially remove the tools. It was designed to reflect and work with all the current policies/processes. If there's interest, I'm happy to start an RfC on it. - jc37 04:49, 20 April 2023 (UTC)
• If finding a good process were as easy as telling the community to come up with a process, we would already have come up with a process.... Dekimasuよ! 13:18, 25 April 2023 (UTC)
• What is this meant to actually achieve? Say there is consensus for this proposal: what then? I don't see how this gets us any closer to coming up with an actual workable implementation of community-based desysop which can in fact gain consensus. Caeciliusinhorto-public (talk) 15:28, 25 April 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.

Admin block history

I was curious how often admins get blocked, so I did a little data mining. I parsed all the per-year subpages of WP:Successful requests for adminship for account names and pulled all their blocks from the logs. I'm sure there's edge cases I didn't handle correctly; any admin who was renamed won't be handled correctly, for example. And I made no attempt to figure out of the blocks happened while the user held the sysop flag. But it should give you some idea of how often it happens. See User:RoySmith/admin-blocks. -- RoySmith (talk) 18:09, 20 April 2023 (UTC)

@RoySmith Your list currently makes no distinction of blocks vs unblocks, just if it was in the log. Is there a way to check that? Or at least, note the change properly instead of marking unblocks as "indef" Soni (talk) 18:14, 20 April 2023 (UTC)

Good point. I uploaded a new set of results, with the unblocks filtered out. -- RoySmith (talk) 18:38, 20 April 2023 (UTC)

Thank you for this great data. I know it took time, and I appreciate it. How many of these are mistakes? Many admins have accidentally blocked themselves. In the admin interface a block link appears next to every username, including one's own. What about mistaken blocks like this bonehead move which I reversed? Clicked wrong link. What about admin accounts that get blocked after the account no longer has admin rights (the unfortunate downward spiral some have experienced). I think the number of long blocks on current admins is so small that it can be handled bespoke by ArbCom. Jehochman ^Talk 19:27, 20 April 2023 (UTC)

@RoySmith thanks for that, but would it be possible to get it in a table format so it can be sorted by other things than just username? Maybe also filter out blocks with a duration of less than 1 day (most likely tests) or which were reversed after less than a day (more likely errors)? Thryduulf (talk) 19:36, 20 April 2023 (UTC)

No good deed goes unpunished :-) I'll see what I can do, but I was hoping not to turn this into a major project. The script that does this is 24 lines of python that calls the pywikibot library. If there's any pyhonistas who want to hack on it, it's at https://github.com/roysmith/rfa-stats/blob/main/go.py -- RoySmith (talk) 20:01, 20 April 2023 (UTC)

RoySmith As Thryduulf says, you'll want to ignore admins blocking themselves. It's unlikely to happen these days as Special:Block is far more user-friendly, but it used to be embarrassingly easy to make that mistake, as I have ... twice. Black Kite (talk) 20:32, 20 April 2023 (UTC)

I was "this close" to writing the perfect Quarry Query for this, except my query both started sputtering in the middle bad, as well as having no clear way to handle short term blocks (like 30d etc).

Otherwise I would have just done some form of "Sum of unblock timestamp - Sum of block timestamp" to figure out how long people stayed blocked for. (probably like Now - Unblock timestamp or something using DATEDIFF).

Anyway, I pasted the query link, just in case someone optimises the final bits enough to make it consistently work below 10 mins. Then we can get a CSV of everything we need + summaries (block/unblock times for each admin etc). Soni (talk) 21:39, 20 April 2023 (UTC)

Ha! I was literally blocked one time, for one minute, in 2009, just to get my attention when I was on an AWB run. I imagine this was in the days before AWB would automatically stop when you got a talk page message. BD2412 T 21:49, 20 April 2023 (UTC)

I was blocked for WP:NOTHERE. -- RoySmith (talk) 22:20, 20 April 2023 (UTC)

From the timing I'd have to think this was an April Fools joke. BD2412 T 22:53, 20 April 2023 (UTC)

Worth pointing out, I know admins used to block each other to test how it worked and also for fun way back when. Hiding T 22:42, 20 April 2023 (UTC)

Gathering the data was a good idea, but unfortunately not filtering for whether the user was an admin at the time is an issue also. There are users with multiple blocks after they were desysopped. --RL0919 (talk) 23:16, 20 April 2023 (UTC)

1,882 admin blocks? Wow, way more than I thought. For some reason I had the idea that admins blocking admins was rare. –Novem Linguae (talk) 04:34, 21 April 2023 (UTC)

That's not really an accurate figure. Circa 277 are explicitly tests (include the word "test"), another circa 35 are for wikibreaks and the data also includes errors and blocks from before and after the blockee was an admin. Even then as the data goes back to December 2004, and almost all of them were over a decade ago:

Year	Blocks
2004	10
2005	324
2006	376
2007	299
2008	195
2009	122
2010	112
2011	76
2012	37
2013	38
2014	27
2015	51
2016	31
2017	32
2018	47
2019	33
2020	18
2021	27
2022	26
2023	1

Figures found using find and replace, so may not be completely accurate. The one block this year was Barkeep49 partially blocking Geometry guy from WP:BN for 31 hours, after they were desysopped for inactivity. There is no easy way to see how many others were partial blocks. Thryduulf (talk) 09:49, 21 April 2023 (UTC)

I've now looked at all the entries on that list from 2022:

• 9 were of former administrators (7 different blocks)
• 6 were testing (3 editors)
• 5 were mistakes (3 editors, Materialscientist managed to accidentally block themselves 3 times)
• 1 was a compromised account, subsequently resolved
• 5 entries relate to Athaenara who was subsequently desysopped (see Arbitration case)

details of blocks of (former) administrators made in 2022

Former administrators: 1 72-hour partial block for edit warring (William M. Connolley, desysopped by arbcom in 2009) 1 self-requested block after resigning as an admin (AustralianRupert) 1 block (2 entries) indef ("WP:BLOCKNAZIS"), followed by community ban (Bedford desysopped by Jimbo in 2008) 1 block (2 entries) for 12 hours for violating a community sanction, talk page access subsequently revoked (BrownHairedGirl, Desysopped by arbcom in 2020) 1 indef partial block from 1 page, overturned at ANI after ~3 hours (Fram, desysopped in 2019) 1 indef partial blcok from article and draft namespaces for copyvios (Gryffindor, resigned adminship in 2018) 1 24-hour block for edit warring (Kwamikagami, desysopped by arbcom in 2012) Testing blocks: 3 1-minute self-blocks for testing purposes by Cryptic 2 blocks of own alt-account (that was the former main account) for testing purposes (1 indef unblocked after 2 minutes, 1 24-hours unblocked after ~90 minutes), AmandaNP/DeltaQuad 1 self-block for testing by Samwalton9 Mistakes: 1 mistake fixed after 7 minutes (Izno blocked L235 when attempting to block a vandal on L235's talk page.) 3 mistaken self-blocks by Materialscientist, all reversed after 0-1 minutes. 1 mistake fixed after 2 minutes (Gadfium blocked RoySmith when attempting to block someone else) Other: 1 compromised account (Staxringold) 5 blocks of Athaenara who was subsequently desysopped, see Arbitration case

Thryduulf (talk) 10:43, 21 April 2023 (UTC)

@Thryduulf: I'm not sure what of my actions is being questioned or talked about here. If you need some sort of response from me, please ping again with some additional clarity. Thanks, -- Amanda (she/her) 22:48, 21 April 2023 (UTC)

@AmandaNP: none of your actions are being questioned. This is just a factual list of all the times an account that has or had the admin bit was blocked in 2022 (I've improved the formatting to hopefully make that clearer). Your testing blocks (like the other testing blocks) were completely unproblematic. Thryduulf (talk) 23:00, 21 April 2023 (UTC)

Next time you might use the "noping" template as it links to the username without actually pinging them, since a ping could indeed be considered equivalent to "explain yourself." ⛵ WaltClipper -(talk) 17:46, 23 April 2023 (UTC)

If you do get the information to exclude test, self, and AFD blocks, it would be interested to see which admins placed the most such blocks. Jclemens (talk) 04:33, 25 April 2023 (UTC)

I've looked through the list above and the following is a summary of all the blocks of then-current administrators since 2019 (I've run out of time to look further now, I may do more later if there is interest). Reason is a breif summary, the block log usually contains more detail.

The list excludes: partial blocks, errors, testing, and self-requested blocks.

It includes: blocks that occurred at approximately the same time as a desysop, and blocks that were subsequently reversed (for any reason).

Date	Performer	Target	Reason
2019-03-02	GeneralizationsAreBad	Bogdangiusca	Compromised account
2019-03-24	Fuzheado	Necrothesp	Compromised account
2019-05-14	KrakatoaKatie	Jerzy	{{ArbComBlock}}
2019-06-05	(vanished user)	Od Mishehu	Sockpuppetry
2019-06-10	WMFOffice	Fram	Office Action
2019-06-12	WMFOffice	Fram	Reinstating Office Action
2019-08-09	Huon	Ritchie333	Violation of IBAN
2019-10-16	Premeditated Chaos	Ritchie333	Violation of IBAN
2019-11-17	Diannaa	BrownHairedGirl	Personal attacks
2019-12-05	KrakatoaKatie	Edgar181	{{ArbComBlock}}
2021-09-28	Ymblanter	JGHowes	Deceased editor
2021-11-20	Drmies	Epbr123	Compromised account
2022-09-10	Paul Erik	Staxringold	Compromised account
2022-10-11	Floquenbeam	Athaenara	Hate speech or compromised account
2022-10-12	TheresNoTime	Athaenara	Reinstate block

In that time period the only editors to have placed two intentional, non-self-requested blocks on administrators for purposes other than testing are KrakatoaKatie (both were in their capacity as an arbitrator) and WMFOffice (both blocks part of WP:FRAMGATE). Thryduulf (talk) 17:40, 25 April 2023 (UTC)

Maybe I have missed something, in which case feel free to deliver the trout of your choice, while pointing me to the thing I missed, but for what reasons would an admin reasonably be blocked for a month? Would any of thesese potential reasons not involve a breach of trust? I have not read everything here: TL,DR would be an understatement, and my head started to hurt about halfway down, but it seems an important thing to consider. Cheers, · · · Peter Southwood ^(talk): 14:16, 3 May 2023 (UTC)

@Pbsouthwood: an admin may be blocked for a month for (pretty much) any of the reasons a non-admin might be. In at least most cases I would say that a situation rising to that level and the block not being lifted before the end of the month does demonstrate a lack of trust. The only contrary example I can think of would be where the block was very controversial and was still being discussed but there was no neither consensus to unblock nor anyone willing to unilaterally unblock; however if that situation has lasted a month without resolution then it's almost certainly something that's going involve arbcom sooner or later - and they are likely to (partially) unblock them to allow them to participate in a case. Thryduulf (talk) 21:32, 6 May 2023 (UTC)

@Pbsouthwood: I don't think you've missed anything. This discussion has been a waste of community resources and time. Looking at the block logs of current administrators, the three longest blocks (85.3, 79, and 78 days) were self- or self-requested blocks. I don't think we want to desysop for taking a wiki-break unless it extends into our established inactivity criteria. The next two longest blocks (17.2 and 16.2 days) were for compromised accounts. While these were resolved well within 28 days, I don't think we really want to desysop someone whose account is compromised when they're on a wiki-break. Here's your edge case: SarekOfVulcan was blocked by Courcelles for 13.9 days in December 2011 for edit warring: Per e-mail communication. Sarek was initially blocked for 21 days, but was unblocked for time served. So if we want to give this teeth, the 28-day limit would need to be at least cut in half. – wbm1058 (talk) 14:58, 9 May 2023 (UTC)

Actually, if memory serves, I initially blocked for a week and only extended it upon Sarek's request. (I also believe I unblocked based on another request from him, well after the initial week I had felt justified had passed). Going off memory here, as there's nothing important enough here to spend the time sorting through 12 year old emails! Suffice to say, I agree this proposal would have had absolutely zero historical impact. Courcelles (talk) 15:49, 9 May 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.

Handling and interpreting the globalize template

I apologize if I have placed this in the wrong area. I welcome anyone to move it, if they wish to do so.

I think that the Globalize template is of very little value to Wikipedia and is in some ways a negative influence. I am not trying to antagonize anyone who has placed Globalize templates. Unless other edits show otherwise, I believe that they all acted in good faith and that they were genuinely trying to help. I have never found anyone who was acting in bad faith in regard to this template, or any template that does not deal with article deletion. However, in all of my time on Wikipedia, I cannot remember a single time when the person who placed the globalize template actually did work on the article to help with globalizing the article. I can remember them doing some minor edits, sometimes (a couple of wording changes to the document that indicate that the article refers to how things are done in a specific country, not the world), but not anything else. It is possible that many of the "taggers" did substantial work on the article, and I have just missed it (taggers is not meant to be a derogatory term, here, it is just easier than "editor who placed a globalize template" and I use it to describe all templates, and I call them all "tags" for short). Although, I always check to see if they have done additional work, and I also check to see if they posted on the talk page to explain why the globalize template is there. From my experience (anecdotal evidence, the worst type of evidence because it is so prone to bias of the person, as well as sampling bias, and the huge problem of relying on human memory), I would say that over 90% of the tags were placed with no explanation on the talk page or the edit summary* about why it was placed and no change made to the article besides the tag, and I think that is a very conservative estimate (I do not count putting the word "globalize" or "globalization" in the edit summary to be an explanation). However, the articles I read and edit may be unrepresentative of the use of the tag as a whole. Again, in my personal experience, I would say that perhaps half of the users of the templates put "globalize", or something to that effect, in the edit summary, while the rest were blank. In my opinion, that is insufficient unless the state of the article and the subject matter is such that the need for globalization is essentially self-evident. I believe that globalization tags have been added to articles inappropriately in some cases. If one cannot voice how an article should be globalized on the talk page, I do not think that the tag should be placed.

In addition, true globalization in an article is a completely ridiculous standard, if one thinks about it. There are close to 200 countries in the world (the precise amount varies with what one is willing to call a country, personally I do not think Monaco, Andorra, The Vatican, and other micronations count, unless you have a separate micronations category, but that is another issue). It is completely impossible to come up with articles that cover even simple issues in every country, let alone complex ones. There are also regional variations within countries to consider for some topics. To write such an article would be a monumental task. It might be something that a college could do with all of its majors in one subject making a contribution, but that would be a single article. There are thousands of articles with the globalize tag. Even if one such article were written, it would be far too long. Then, even if it were not too long, it would be impossible to keep such an article up to date, with fast-moving topics being a dozen times more impossible.

Another problem is that some topics are not covered by developing nations, as they are currently having problems with things like extreme poverty, natural disasters, rampant corruption, murder squads, impoverished locals selling drugs to rich nations and drug cartels murdering anyone who gets in the way. Their nations do not have people documenting the use of braille by their citizens, and even when they do, they usually only publish the books and articles in their own languages.

In my opinion, Wikipedia should come up with a more reasonable standard for presenting an international view of topics. As an English language encyclopedia, I suggest that we try to get the situation in English speaking countries first (U.S., UK, IR, CA, NZ, AU, IN – I think those are the right codes for Ireland, Canada, Australia, and India) and to make some more sweeping generalizations for certain areas, like regional things – Latin America, North Africa, Sub-Saharan Africa, Middle East, Western Europe, Eastern Europe, Central Asia… and so on. I mean no offense to the non-English speaking world. I am just trying to be realistic. No one would like an article that actually covers a topic on a global scale more than I would, even if it is twenty pages long. My perfectionist heart is currently breaking, but this task is simply impossible. There are over 5,000 articles with the globalize template on them. It would require the effort of many times the number of editors that we currently have to handle such a project. You would have to assign a scholar to a couple of topics, and depending on the nature of each topic, have him or her be assisted by students, as I suggested. For some topics, you could go 10 to 40 years without needing to do it again. However, some would have to be done every three to five years. If something is on the three year side, it is essentially a never ending project.

I have not been able to express things as elegantly as I would have liked. However, I hope that my issues have been understood despite that. I will try to get back here in case anything needs clarification, but I pretty much said what I wanted to say. I warn you that it can be days before I am able to come back to Wikipedia, sometimes longer. If that is the case, I hope that you can be patient with me and I apologize for the delay in advance. -- Kjkolb (talk) 03:02, 26 April 2023 (UTC)

Globalize doesn't mean "cover every aspect of the topic in every country". It means "don't present the U.S. aspects as if they're universal or the only ones that matter". Thebiguglyalien (talk) 05:45, 26 April 2023 (UTC)

Although the US is the most common single country used, it is not the only one and globalisation can apply equally to articles that are United Kingdom-centric, Europe-centric, Hong Kong-centric, Anglosphere-centric, etc. Thryduulf (talk) 09:06, 26 April 2023 (UTC)

This issue is exactly the one we had with {{Expert needed}}, namely editors tagging articles without providing any context or reason, leaving it to others to work out what the problem is and to put in the effort to fix it. Following a 2021 TFD, it was agreed to formally deprecate {{Expert needed}} if the reason= parameter was not filled in. Something similar might help here, as it would make it clearer that unexplained Globalize tags either need to be expanded or can be removed without the removing editor needing to get into arguments about whether the (unstated) reason was 'evident'.

The meaning of the tag also needs clarification. Many editors think it means "please add information about other regions or countries", unsurprisingly given the tag name and the wording "this article may not represent a worldwide view of the subject". But that's not an easy thing to do, with the result that many such tags languish for years. Better might be to change (or clarify) the meaning to "this article includes information that is wrongly stated or implied to be universal or applicable over an excessively wide geographical area. Please either provide additional examples covering other countries or regions, or clarify the geographical area to which the text applies." That's much easier for later editors to deal with, very often by adding some sort of limiting text such as "In the United States, ...". MichaelMaggs (talk) 12:53, 26 April 2023 (UTC)

The globalize template can already be removed if no reason is provided. From Template:Globalize:

• Please explain your concerns on the article's talk page and link to the section title of the discussion you initiate. Otherwise, other editors may remove this tag without further notice.
• This [template]...assumes that you will promptly explain your concerns on that article's talk page in a new section titled "Globalize." (specifically referring to use of the syntax {{Globalize|date=April 2023}})
• If you do not explain your concerns on the article's talk page, you may expect this tag to be promptly and justifiably removed as "unexplained" by the first editor who happens to not understand why you added this tag.

--Sunrise (talk) 03:14, 27 April 2023 (UTC)

I think the meaning of the template is pretty clear. It is as User:Thebiguglyalien says above. If an article only covers one or a few countries then that should simply be made clear. As with most templates that are put on articles the reason for placing it is simply that an editor has seen the issue but doesn't have the time or the ability or the inclination (we are all volunteers) to fix it. If the issue is not clear then people who remove templates should not be treated any worse than people who place them. Phil Bridger (talk) 17:29, 26 April 2023 (UTC)

Indeed, if it isn't clear to you why an article has a particular template then, unless it's clearly incorrect (e.g. [2]), the best thing to do in most circumstances is ask on the talk page and/or ask the editor who placed the template. If other editors can explain the issue then all is good, if they can't then that's very likely consensus to remove it. Of course in some situations some aspect of the topic does apply only to one part of the world (despite a non-expert's gut feeling that it is more widespread than that) and it can't be globalised. In that case the section should be reworded to make that clear that it's a local issue and/or spun off into it's own article. Thryduulf (talk) Thryduulf (talk) 19:11, 26 April 2023 (UTC)

Just to refocus this. Providing a "global perspective" doesn't mean "provide 200 different individual perspectives". It means provide a more general and universally applicable perspective rather than one focused on individual geographies. The main way should write is "Here's the basic idea (and here's a some representative places where some differences from the basic idea vary)." That's the correct way to write an article. It shouldn't be "Here's what happens in country 1. Here's what happens in country 2. Here's what happens in country 3." That's bad writing. --Jayron32 19:18, 26 April 2023 (UTC)

IR is Iran and IE is Ireland :p

Also, I concur with the replies above: globalization isn't providing one separate perspective for each country, to the contrary, it is providing a higher-level reporting of the situation free from national bias. Chaotic Enby (talk) 13:10, 13 May 2023 (UTC)

And besides there being no such thing as true globalization, often it should not be expected (such as on inherently local topics) I think that the good use of the template is when the article has a particularly narrow (e.g. single country) perspective and is on a topic where such should not be the case. Maybe the template could be tweaked along those lines. North8000 (talk) 20:26, 26 April 2023 (UTC)

I've suggested some wording above. Is the tweaking you suggest the same, or something different? Trying to find an actionable suggestion here. MichaelMaggs (talk) 21:21, 26 April 2023 (UTC)

Assuming your suggestion is the green text, that doesn't cover all the uses of the template. See for example Bus stop#Regulation where the geographical scope of the content we have couldn't be clearer, but it relates to only part of one country while the topic (regulation of bus stops) is much wider. Thryduulf (talk) 00:18, 27 April 2023 (UTC)

If the topic has no global perspective, perhaps it should be broken up into separate topics per geography. --Jayron32 11:43, 27 April 2023 (UTC)

I can give an example from the world of cars (where this comes up a lot). Sales of the Toyota FJ Cruiser was discontinued in the US at the end of their 2014 model year but it continued being sold in other markets. Their local news sources almost universally reported it as "discontinued", not "discontinued in the US". Therefore, for years yanks would come along and change the article text and its infobox to say that production finished in 2014 - with no qualification. And this was in spite of hidden comments in the article explicitly warning that it was still being sold in other countries. This was a prime example of Americans writing what was true for them but not realising that it was not true for many other countries.  Stepho  talk  01:15, 28 April 2023 (UTC)

Well, then you fix the problem. People who don't read policies also don't read policies when you change them. You can't do anything to stop this from happening, you can only clean up when it does. Sorry for the bad news, but "being diligent and fixing mistakes other people make yourself" is the only reasonable solution. Everything else is meaningless and will have no effect on the problem. --Jayron32 12:25, 2 May 2023 (UTC)

@Kjkolb, do you remember seeing various versions of this tag?

The tags may be appropriate, and it's even possible that they might occasionally result in improvements to the articles (although AFAICT that's never been proven). But it's probably not realistic to expect the editors who tag the articles to contribute to improving the articles. WhatamIdoing (talk) 01:58, 13 May 2023 (UTC)

Examples

Whether one is dealing with a country by country situation or whether you need to take a wider look would seem to depend on the topic. For example, how would you handle topics like the following. Just come up with what your very basic plan for the article would be in a few words. Also, no need to do them all, just pick a couple:

• Appellate court
• Borough
• Bioterrorism (getting sources from many countries will be impossible and many countries do not do research on bioterrorism, which is the part of the article tagged)
• Cable television
• Divinity
• Door (standard door size subdivision is tagged. do standard door sizes outside of North America and Europe even exist and where do you get references?)
• Dominatrix (good luck getting reliable sources for Latin America, Africa, Middle East, China)
• Flirting
• History of science and technology (unless you say that it is the United States or the Western World in the title, this one is asking for problems)

For "appellate court" and similar articles, like Supreme Court, it seems like the only solution is a country by country article, with some grouping by type, like common and civil law, just as the article does.

The following is not sarcastic, despite how it might seem. I suggest that examples of previous success stories of the globalize tag could be given to prove that it is more useful than a regular, general tag. They would also give guidance on how to properly address the issues in the articles that have yet to be fixed. The globalize template has been around in some form since 2004, which is more than enough time for it to have some successes. We could see which articles that it has been removed from and exclude the articles that should not have been tagged in the first place. At least a few of the rest should be success stories. If there are slim to no success stories, then perhaps the tag should not be added to more articles until we decide what we are going to do with the ones that are currently tagged.

Note: Removed list of "why" tags. --Kjkolb (talk) 21:55, 29 April 2023 (UTC)

If a global view exists, describe the global view. If multitudes of highly different individual views exist, the main article should be a DAB page (or nearly so) and the bulk of the information should be in their own articles. Borough could be done a lot better with a simple dictionary definition, then it could be broken out into separate articles on each type of Borough, for example. --Jayron32 12:23, 2 May 2023 (UTC)

Here's a reference for standard door sizes in a bunch of countries (especially non-Western ones): here!

And here's another one!

I don't have the names of the specific regulations establishing each of these, but they should be feasible to find too. In any case, yes, standard door sizes exist outside of NA and Europe.

For articles like Divinity, it's obvious that adding context from other religions and beliefs systems than Christianity (with their own relationships with the divine) would be what's needed. Chaotic Enby (talk) 13:18, 13 May 2023 (UTC)

Can we promote WP:Prodigy to a guideline?

This popped up because of a recent edit and I realized that this has been sitting as a draft for a very long time. There has been no substantive discussion of it in a while either, so I would like to propose that it be made a guideline as is. Mangoe (talk) 03:43, 28 April 2023 (UTC)

I have no strong opinion about this either way, but this thread reminded me of an old situation and encouraged me to put together this RFD. Graham87 08:57, 28 April 2023 (UTC)

This seems like a very specific circumstance to have its own guideline. If this is a recurring problem (which apparently it is), the best approach might just be to enforce existing policies like WP:BLP and WP:NBIO, which seem to cover this. Things like WP:PRODIGY work better as essays that interpret policy rather than becoming P&G in their own right. WP:NEXTBIGTHING comes to mind as a similar example. Thebiguglyalien (talk) 15:37, 28 April 2023 (UTC)

I would second this, with the thought that perhaps it could be linked to within the appropriate policy articles. Nerd1a4i (they/them) (talk) 03:44, 1 May 2023 (UTC)

Meh. I'm not sure it's particularly needed. Wikipedia covers articles on children who meet the same guidance as adults. There are dozens of articles about children Edward V of England, Tad Lincoln, Nandi Bushell, Gavin Warren, etc. and I'm not sure we need special rules for "child prodigies" vs. other children. Why does one need special protection because one was a prodigy? --Jayron32 16:17, 28 April 2023 (UTC)

Child prodigies need special protection because of the publicity hype about them often generated by the media and by ambitious and unscrupulous parents. There have been several examples in the last ten years. I should like to see this as a guideline or an essay. Xxanthippe (talk) 04:12, 1 May 2023 (UTC).

I mean, if you want to write an essay, write it. No one has to agree with an essay. --Jayron32 11:02, 1 May 2023 (UTC)

Discussion here appears to have died. I've tagged it as an essay, feel free to revert. casualdejekyll 20:50, 11 May 2023 (UTC)

What is and isn't part of a country on Wikipedia?

I notice that Crimea is considered a Ukrainian territory on Wikipedia, as the United Nations voted to not recognize Russia's land grabs.

Yet at the same time, the first line on the Taiwan article is "Taiwan is a country", while Taiwan is not recognized as such by the UN.

Why is that? Synotia (moan) 16:56, 28 April 2023 (UTC)

The stance of the UN is one factor that might be considered, but it's not a deciding factor. We go by what the mainstream position is in WP:reliable sources. If you look at the footnote next to "is a country", it lists several reliable sources that describe Taiwan as a country. Thebiguglyalien (talk) 17:06, 28 April 2023 (UTC)

I suspect that if you looked for Chinese-language sources, the opposite would be the consensus. You might understand what I mean? Synotia (moan) 17:07, 28 April 2023 (UTC)

Not really a policy issue, this. Selfstudier (talk) 17:10, 28 April 2023 (UTC)

Because other stuff exists, and WP:CONSENSUS. Each situation is determined individually, and there have been discussions on both individually have led to the current texts on Wikipedia. If you wish for one to be consider as another for either one, it is best to open a discussion on talk page of the article of the one you want to change. – robertsky (talk) 17:11, 28 April 2023 (UTC)

I would also note that we have articles on both the Russian province of Crimea (Republic of Crimea) and the Ukrainian province of Crimea (Autonomous Republic of Crimea) in the same way we have articles on the province of Taiwan in the ROC (Taiwan Province) and the province of Taiwan in the PRC (Taiwan Province, People's Republic of China). There is also a fundamental difference between the two disputes you list, in that Taiwan claims itself to be an independent nation while Crimea does not. Curbon7 (talk) 17:28, 28 April 2023 (UTC)

Because you can't backdoor your way into overriding consensus by trying to invent a rule. If you think the wording of an article should be changed, get your evidence together, go to the article talk page, lay out your evidence, and let others do the same. If other people have stronger evidence than you do, there's no rule or policy that should change that. --Jayron32 18:35, 28 April 2023 (UTC)

As others have pointed out, this is a really complicated question, with no universally correct answer. I used to work for a network management company. Our product was the kind of thing that put up a big world map showing the status of all your data centers, communication links, etc. We had multiple versions of the base map, showing countries labeled in whatever way was not going to offend a particular customer. -- RoySmith (talk) 16:36, 30 April 2023 (UTC)

Toponymy is the politics of naming and often different state/actors have competing interests. Wikipedia doesn’t take a position but tries to summarise different non-fringe/authoritative sources. Happy editing! ~ 🦝 Shushugah (he/him • talk) 12:45, 1 May 2023 (UTC)

Without commenting on the specific geopolitical issues raised here, I'll point out that in general, although we aim for NPOV, we do not always achieve it. Our articles often reflect an American or Western European point of view, because of our systemic bias. —Mx. Granger (talk · contribs) 13:17, 4 May 2023 (UTC)

There has been a peaceful status quo in the dispute between the PRC and the ROC for over 70 years, and the Wikipedia article generally reflects that. There is a hot war in Ukraine, and the Wikipedia article reflects the status quo ante of the conflict. I don't see any contradiction here. Walt Yoder (talk) 19:41, 6 May 2023 (UTC)

RfC about WP:COP-HERITAGE

See Wikipedia talk:Categorization of people#RfC about WP:COPHERITAGE

WP:FORUMSHOPPING to overturn prior Categories for Discussion results concerning overcategorization by ethnicity. This would change to "at least one" (from zero or one), a major shift for descent and diaspora categories contrary to 18 years of documented guidelines. Most biographies should have zero descent categories, as Wikipedia:Categorization of people#By nationality and occupation are sufficient. Some may have one, but there has never been a documented need for two or more, and certainly never "at least one". It could explode the number of such categories.
William Allen Simpson (talk) 07:34, 5 May 2023 (UTC)

WP:CRIMINAL

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

---

Note: A living person accused of a crime is presumed not guilty unless and until the contrary is decided by a court of law. Editors must give serious consideration to not creating an article on an alleged perpetrator when no conviction is yet secured.

The problem with above policy is that. All crimes are not of similar nature. Like say a retired university teacher, winner of several awards, from Nice, France accused of murdering his wife. An actor, film director accused of rape in Los Angeles.

The policy is suitable for above people.

But if we expect a Taliban terrorist is not terrorist unless he is convicted. In lawless areas of Pakistan, India, Afgjhanistan, Nigeria, Somalia, Columbia, Mexico, if a gangster, mafia don turned politician, dictator, powerful caste leader, maoist, cruel military general how can Wikipedia expect that these types of people will be convicted?

in large countries like Pakistan, the Islambad city area will have better law and order than Peshawar, Khyber Pakhtunwala, Waziristan area. In India, Kolkata, Chennai, Hyderabad city areas will have better law and order than crime areas of Bihar, Bangladesh border districts, Maoist areas, Chambal areas.

Do you expect that entire Pakistan has strong law and order that will convict a Muslim of killing Christians, converting Hindu girls?

There are many politicians who are above law in India as they are gangsters, mafia dons who contest elections to control police. They are called "bahubali politicians"(google)

Taliban government will not convict a Taliban. Pakistani police, judges do not punish many Muslims who rape and convert minor Hindu, Christian girls.

If a Mexican gangster, Columbian drug lord, Puerto Rican, El Salvador criminal gang leader is not arrested due to corrupt police, then he is innocent?

If multiple reliable sources, mention someone as a gangster, drug lord, mafia don, terrorist leader,communist dictator, military junta- for few years, then Wikipedia must accept such terms whether they get convicted or not convicted. 2409:4088:9C83:FD63:2D8F:72E9:3B29:768F (talk) 09:48, 5 May 2023 (UTC)

"If white and respectable, presume innocence. If brown, and someone we don't like for religious/political/whatever reasons, presume guilty." AndyTheGrump (talk) 09:59, 5 May 2023 (UTC)

As a brown-skinned Indian, I'd say that the IP is correct in the sense that a lot of crimes by powerful people here and neighbouring countries go unconvicted. Whether or not a policy change is required is up for debate. But Andy's response completely misses the point. Did the IP ask you to label all Indians, Pakistanis, etc. as criminal, no they don't. It's for the cases wherein conviction does not occur even though literally everyone knows who the culprits are. —CX Zoom[he/him] ^{(let's talk • {C•X})} 11:15, 5 May 2023 (UTC)

It is not our place as Wikipedia editors to determine guilt or innocence, or whether someone guilty of a crime is avoiding conviction because of power, connections, corruption, etc. The guideline (it is not a policy) should stand as is. - Donald Albury 11:57, 5 May 2023 (UTC)

Many gangsters, mafia dons, drug lords, terrorist leaders, dictators, corrupt political leaders, crime kingpins(of all races) are not convicted properly due to many reasons. Yes, Wikipedia cannot determine guilt. But if reliable sources mention that for few years, then what is wrong in accepting that, when it is implied that the accused is powerful enough that can threaten witness, purchase corrupt cops, threaten government lawyers, bribe judges, has political power? 2409:4088:9D94:2912:95F:E4FB:59D2:B7A3 (talk) 12:19, 5 May 2023 (UTC)

• Do you expect that entire Pakistan has strong law and order that will convict a Muslim of [...] converting Hindu girls, Pakistani police, judges do not punish many Muslims who rape and convert minor Hindu; By including references to an Islamophobic conspiracy theory, I cannot assume that this proposal is in good faith. This feels like a coded way to include Hindutva propaganda. Curbon7 (talk) 12:32, 5 May 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.

RfC: Non-free licensed files

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

---

Should full-size Creative Commons NC, ND, or NCND, or compatible, licensed files be allowed?

Context

Some files are classified as non-free by Wikipedia standards but are available under a license that permits educational, personal, or otherwise non-commercial use and/or prohibits derivative works. These include certain Creative Commons licenses.

The policy, as currently written, has a number of criteria that must be met in order for a non-free file to be used. One of these is the minimal extent of use which is further specified as "including usage of low-resolution, rather than high-resolution/fidelity/bit rate (especially where the original could be used for deliberate copyright infringement)". Bots enforce this provision by automatically resizing any files deemed too large.

The wmf:Resolution:Licensing policy is the ultimate authority in copyright matters. It authorizes projects to develop and adopt an Exemption Doctrine Policy consistent with the resolution, permitting "the upload of copyrighted materials that can be legally used in the context of the project". The proposed change is fully compatible with the resolution.

This proposal was discussed before here.

Rationale

Low-resolution requirement is in the policy solely because fair use compliance so requires. It is intended to reduce the reusability of the file, and so any adverse commercial impact our use would cause to the copyright holder. However, under these licenses, no fair use considerations are required.

We should always use free files when available, and this change would in no way affect that requirement. However, when we are given the option to either use the file under a claim of fair use and reduce its quality, or use it under a non-free license, we should choose the less bad alternative. To do otherwise would be a disservice to both our readers and re-users.

It would also better respect the wishes of the copyright holders: they want (and in case of ND explicitly require) us (and the general public) to use their works in their original form, but we are in fact forcibly altering them to a worse quality. I don't think we can even claim our use to be fair if, given the option to use unaltered files, we choose to alter it anyway and misrepresent its quality.

Best, CandyScythe (talk) 10:25, 6 May 2023 (UTC)

• No. The WMF Resolution on non-free images uses a definition of "free" that requires us to allow end users to redistribute and modify images regardless of their type (commercial or not). While we could use licenses like CC-ND or CC-NC at full size, end users cannot. So we have to treat these as non-free and offer low resolution versions that end users likely have a better chance to use under a fair use allowance on their end. --Masem (t) 13:52, 6 May 2023 (UTC)

  We really have to balance the interests of our readers, different types of re-users, and copyright holders. I think it's undisputed that readers come first, and that they would be better served with higher-quality files. Non-commercial re-users would also benefit. What is fair use for Wikipedia is most often not for a commercial re-user, so most of those would already be unable to use those files. In the rare case that someone would be unable to legally re-use files because of their high quality, re-sizing them like we already routinely do would be trivial for them. It would be strange to sacrifice all the potential benefits to protect a small subclass of our re-users from minor inconvenience. The WMF Resolution does in no way force us to do it, as it explicitly authorizes use of non-free files under an applicable rationale. Best, CandyScythe (talk) 14:37, 6 May 2023 (UTC)

  We have effectively "marching orders" from the WMF here. Unless you want to run your own servers and set the rules on what content we allow, we have to follow the resolution here and what counts as free or not. You're also effectively asking to create a third class of images outside free and non-free, and that would become a mess in creating all the necessarily policy and procedures for under the resolution. Masem (t) 15:18, 6 May 2023 (UTC)

  I think that you're confusing and diluting your your good explanation with the "Because WMF said so". If that were the only reason, then we'd need to tell WMF to change that. North8000 (talk) 17:18, 6 May 2023 (UTC)

  They own and pay for the servers. They get to make the rules here. Masem (t) 02:37, 7 May 2023 (UTC)

  Importantly, I believe it could not merely affect operation of servers, but interfere with contracts the WMF has with commercial partners (Google is paying the Wikimedia Foundation for better access to information – the Verge). — HTGS (talk) 05:59, 7 May 2023 (UTC)

• No It is a disservice to our readers and downstream users to create content that is not available under a fully free license. We are not the somewhat-free-encyclopedia. This would undermine the very idea of the free culture movement and make our licensing situation considerably more restrictive rather than permissive. We already have north of 700 thousand non-free files on this project. We don't need another category of somewhat-free files that will very likely balloon to such a huge figure itself. Absolutely not. --Hammersoft (talk) 15:06, 6 May 2023 (UTC)
• No Commercial uses are still uses, so non-commercial licences are a restriction on our users akin to fair use. – John M Wolfson (talk • contribs) 16:09, 6 May 2023 (UTC)
• No Per reasons given by others. But thanks for the thought and bringing it up. North8000 (talk) 17:20, 6 May 2023 (UTC)
• Yes NC images are a good resource for our purpose and we should not hinder or obstruct their use in any way. It's best to capture the entire image in case the original should go down and be lost. I was looking for the source of an image the other day and found it had gone offline. Andrew🐉(talk) 17:50, 6 May 2023 (UTC)

  Wikipedia is not archive.org, archive.is or other archiving service. Use one of those to preserve the original of non-free images if they have not already done so. Doing so matches directly their mission and they have the infrastructure, policies, etc. in place to deal with such tasks better than we do (because it's only a tangential part of our mission). Additionally you can use them to preserve far more images more reliably than you could on Wikipedia, because images can and do get deleted here for many reasons. Thryduulf (talk) 20:42, 6 May 2023 (UTC)

• No per Masem's first comment. Files that have restrictions on commercial use and/or derivatives are not Free in the sense we use it on Wikipedia, and I see no benefit to creating a class of slightly less non-free images with all the added complexity, bureaucracy, policy and maintenance overhead that would entail. Thryduulf (talk) 20:38, 6 May 2023 (UTC)

  The only change required would be that if tagged with a "Non-free with NC and ND" template, it would also tell bots not to resize that file. I don't really see the bureaucracy argument. Best, CandyScythe (talk) 20:46, 6 May 2023 (UTC)

• No per others above. NC and ND conditions are not considered sufficiently free under the WMF resolution and so they should be treated under the same non-free content policy as other non-free images for reasons outlined above. -- Whpq (talk) 21:21, 6 May 2023 (UTC)
• No, per Masem et al. Boing! said Zebedee (talk) 06:11, 7 May 2023 (UTC)
• No (or Oppose) mainly for the reasons given above, but also because this seems to be trying to carve a general exception to WP:JUSTONE for certain types of images when such a thing isn't really necessary. While it's true that WP:NFCC#3b (WP:IMAGERES) does require that non-free images, in principle, be "rescaled as small as possible", it does qualify that with "to still be useful as identified by their rationale, and no larger". This seems to allow for the possibility of a non-free image either not being fully rescaled or rescaled at all when doing so is deemed necessary to preserve it's encyclopedic value to readers. A file could be tagged with Template:Non-free no reduce if the uploader feels the any rescaling is not needed. The uploader could also rescale the image themselves to what they feel is the appropriate size before uploading it and then add the aforementioned template to prevent any further rescaling. There's also Template:Non-free manual reduce that can be used when excessive rescaling by bots is a concern. In any of these cases, there's no reason why disagreements over rescaling or appropriate image size can't be resolved through discussion at WP:FFD much in the same way that disagreements over the application of any of the other NFCCP are often resolved. For sure the burden would fall upon the uploader or whomever wants to image to remain at a certain size to establish a consensus in support of their position, but that's no different from how things currently are per WP:NFCCE. When it comes to free image licensing, Wikipedia for the most part seems to pretty much follow c:COM:L and c:COM:LJ, except it does so on a local level. Wikipedia and several other of the local Wikipedia's do allow some fair use content to be uploaded and user, but many others are like Commons and allow no fair use content at all. What this RFC is proposing (at least in my opinion) is to create a new category of image licensing that lies somewhere in between what would be considered free licenses and non-free licenses; in other words, a sort of hybrid-license that tries to apply parts of both WP:COPYOTHERS and WP:NFCC. That (at least in my mind) involves something much more that telling bots not to resize a file (which already can be done to some degree), and might even require running things pass the WMF to see whether it is OK with this new category of licensing. -- Marchjuly (talk) 11:41, 7 May 2023 (UTC)
• No The point of disallowing these licenses is that Wikipedia should be as free as possible to any downstream reuse while still respecting the creators. CC-BY-SA attributes the creators and allows unlimited downstream reuse so long as attribution is maintained. Once you put restrictions on reuse like NC or ND, that has unintended knock-on effects. --Jayron32 13:37, 9 May 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.

RFC: MOS:GENDERID and the deadnames of deceased trans and nonbinary persons

This RFC covers 3 questions pertaining to the treatment of deceased trans or nonbinary persons' deadnames.

1. What name should articles principally use to refer to a deceased trans or nonbinary person?
2. When should Wikipedia articles include the former name of a deceased trans or nonbinary person who was not notable prior to transitioning?
3. How often should Wikipedia articles mention a deceased trans persons former name?

--Jerome Frank Disciple 18:46, 6 May 2023 (UTC)

Background

In the recent past, there have been several discussions and RFCs concerning the deadnames of deceased trans and nonbinary persons. Though other policies and guidelines have been invoked, these debates have generally revolved around MOS:GENDERID. But, currently, GENDERID only expressly considers the "deadname[s]" of living trans persons:

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.

Many have argued that other paragraphs within GENDERID have relevance for the aforementioned questions, and other Wikipedia guidelines/policies that have been thought relevant include MOS:CHANGEDNAME ("A person named in an article of which they are not the subject should be referred to by the name they used at the time being described in the article."), WP:BDP, and, particularly when a majority of reliable sources refer to person by their former name, WP:DUE/WP:NPOV.

This RFC is not intended to determine the present meaning of those policies—though editors have, often fiercely, disagreed as to their interpretation and effect. In order to properly structure future discussions, these proposals are meant to provide increased clarification through new guidance.

Topic 1: What principal reference? (MOS:GENDERID 1st paragraph)

Should Wikipedia articles always principally refer to deceased trans and nonbinary persons by their most recently preferred name of choice, as reported in reliable sources?

Proposed alteration (changes bolded)

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 gender 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.

Support (MOS:GENDERID topic 1)

• Support as proposer. In my view, GENDERID's failure to explicitly address the treatment of a deceased person's deadname has led to unnecessary confusion and unnecessarily repetitive discussions. Whether or not enshrined in policy (and I think it should be), this particular proposal is, to my knowledge, already standard practice.
  I'd also emphasize that this proposal only applies if reliable sources do indicate a most recently used gender identity. As such, "but what if reliable sources disagree as to the most recent self identification?" isn't, as I see it, a valid reason to object to this policy. In cases where reliable sources disagree, a case-by-case examination will, of course, be required. But the proposed guidance is explicitly not meant to cover those cases—it's meant to standardize practice when there is agreement as to the most recently used self identification.
  Finally, in terms of the argument that we must follow the majority of reliable sources, I'd point out that MOS:GENDERID already rejects that argument as to pronouns (and the deadnames of living transgender and nonbinary persons). Ultimately, this proposal—unlike the other proposals—is a style issue, not a content inclusion issue.--Jerome Frank Disciple 19:01, 6 May 2023 (UTC)
• Support Full disclosure, I assisted Jerome Frank Disciple with drafting these questions. I agree with Jerome Frank Disciple. In the discussions at WT:MOSBIO that preceded this, some editors expressed confusion over when to use a trans or non-binary person's deadname, especially when that person is deceased. The standard practice in my experience across many biographies is that we use the name that reflects that person's most recently expressed gender identity, and this small change to the first paragraph of MOS:GENDERID codifies and clarifies this. It should be an uncontroversial measure of respect that regardless of what phase of life a person is in, including death, we use both the name and gendered words that reflect who they perceived themselves to be. Sideswipe9th (talk) 19:42, 6 May 2023 (UTC)
• Support: this is a natural extension of existing guidelines and good style guide practice. It is often irrelevant after the first mention of an individual as we refer to people by their surnames, which often won't change in this case. — Bilorv (talk) 20:17, 6 May 2023 (UTC)
• Support I think this is a no-brainer. I like the "any phase of the person's life" bit. That pre-empts and precludes the sort of trolls who might think that it was funny to try to insert wording like "when he was a girl". The only thing I think it would be good to add is an explicit explanation of how to handle situations where WP:COMMONNAME might conflict. DanielRigal (talk) 20:24, 6 May 2023 (UTC)
• Support per everyone above. This is how I've always interpreted the intent of GENDERID, and how most (but not all) people have interpreted it in at least most (possibly all) discussions about it I have been involved with. Making this explicit has no downsides that I can think of, particularly given the "unless they have expressed a preference otherwise" language. Thryduulf (talk) 20:55, 6 May 2023 (UTC)
• Support: Like everyone else is saying, this one is really a no-brainer. It just clarifies what was always the obvious intent of this paragraph anyway. Loki (talk) 21:00, 6 May 2023 (UTC)
• Support. A change to the fourth paragraph "In articles on works or other activity by a living trans or non-binary person before transition, use their current (or last, if deceased) name as the primary name..." should also be made.--Trystan (talk) 21:03, 6 May 2023 (UTC)

  I've expanded on this point under Topic 3 (Option 3a), below.--Trystan (talk) 21:33, 6 May 2023 (UTC)

• Support, but... After death, the most recent expressed gender self-identification becomes locked-in forever. In the hypothetical scenario where reliable sources overwhelmingly conclude that a transgender identity was actually disingenuous, we would be prevented from writing an accurate article. I would hope that in such exceptional cases WP:IAR would suffice to do the right thing. Barnards.tar.gz (talk) 21:04, 6 May 2023 (UTC)

  Agreed; the phrasing of this shouldn't be read to imply as "we need to take trolls seriously" and if it becomes a problem I'd support adding "sincere". But I think this is uncommon enough that we can go on WP:IAR for now. Loki (talk) 21:13, 6 May 2023 (UTC)

  After death, the most recent expressed gender self-identification becomes locked-in forever. Though rare, this isn't always the case, at least for the purposes of writing content on Wikipedia. Quentin Crisp is a pertinent example here. Crisp died in November 1999, however at around that same time Crisp was working on an autobiography that ultimately wasn't published until 2017. In that book, among other untold stories, Crisp described the realisation that occurred some time in 1998/99 that they were a trans woman and not a gay man. The book itself is a very personal insight into Crisp's early life, and how because of the time in which they were born (1908) they didn't have the vocabulary to express their gender identity. Sideswipe9th (talk) 22:13, 11 May 2023 (UTC)

• Support. Principally refer to them as their most recent used name and expressed gender identity. I agree that it really should just be policy at this point. I feel there is such a strong sentiment towards this. (I've never seen or heard of an instance where the current name and gender identity wasn't the primary referrer here.) SWinxy (talk) 23:42, 6 May 2023 (UTC)
• Support Names are gendered so this is a natural extension and is already practice. Galobtter (talk) 01:57, 7 May 2023 (UTC)
• Support as long as the individual’s expressed identity is sourced reliably. Primary sources, as per WP policy, should be avoided, as it may constitute original research, which isn’t allowed on WP. Yasslaywikia (talk) 02:42, 7 May 2023 (UTC)
• Support going with what RS say is their self identification seems very reasonable and like general best practice, exactly the type of guidance that should be in a MOS.TulsaPoliticsFan (talk) 04:39, 7 May 2023 (UTC)
• Support Seems reasonable, with standard WP:IAR exceptions. --Jayron32 14:10, 8 May 2023 (UTC)
• Support. This amendment is both reasonable on its own merits and a useful clarification of the already-existing spirit of the guideline. ModernDayTrilobite (talk • contribs) 16:23, 8 May 2023 (UTC)
• Support: The proposed rule is reasonable, concise and clear, and comports with the spirit of MOS:GENDERID. voorts (talk/contributions) 21:30, 8 May 2023 (UTC)
• Support That has always been the common and proper way of doing things, deferring to the most recent known usage by the individual. Silverseren^C 22:02, 8 May 2023 (UTC)
• Support as a general rule, seems quite sensible, as long as it admits the possibility of a case-by-case exception such as that mentioned by Barnards.tar.gz. Stifle (talk) 13:56, 9 May 2023 (UTC)
• Support. This is the sensible, most prudent, and reasonable measure to take. Of course, there will be exceptions to this general rule. No one is suggesting that we have to exclusively refer to someone as GodEmperor just because they said that's their name before they died. However, 99% of cases are going to be incredibly straight forward ("I go by Gary even though I wasn't born with that name.") If the guy who said that is dead or alive shouldn't make a difference, we should just call him Gary because that's what everyone else uses to refer to him. –MJL ‐Talk‐^☖ 01:26, 10 May 2023 (UTC)
• Support This is the common usage anyway, so no issue with codifying it a little more clearly. CoffeeCrumbs (talk) 04:19, 10 May 2023 (UTC)
• Support This is both reasonable, respects the wishes and identity of the deceased, and a natural continuation of the current policies in MOS:GENDERID. Chaotic Enby (talk) 14:53, 10 May 2023 (UTC)
• Support Seems reasonable to close this loophole. ser! ^{(chat to me - see my edits)} 18:39, 10 May 2023 (UTC)
• Support In those rare cases where RS indicate that a declaration of self-identification was disingenuous, well, we'd follow RS in saying that it was disingenuous. XOR'easter (talk) 18:56, 10 May 2023 (UTC)
• Support sensible for the context. Aza24 (talk) 05:39, 11 May 2023 (UTC)
• Support, especially given that all rules, policies, guidelines etc allow for the application of common sense where blindly following the rule would clearly be the wrong decision. I can believe that there are certain edge cases and exceptions, but we're used to handling those in other contexts (via WP:IAR, in the last resort). UndercoverClassicist (talk) 10:24, 11 May 2023 (UTC)
• Support as a natural extension of the existing guideline.— Preceding unsigned comment added by Rutebega (talk • contribs) 16:22, 11 May 2023 (UTC)
• Support This is a logical extension of the current guideline, and I assumed it was already standard practice. TheCatalyst31 ^{Reaction•Creation} 00:33, 12 May 2023 (UTC)
• Support It does not make sense for the guideline to only apply to living people. Tekrmn (talk) 21:24, 11 May 2023 (UTC)
• Support. We need a rule for this, to avoid sterile arguments, and the proposed change is fine. Herostratus (talk) 03:14, 12 May 2023 (UTC)
• Support – absolute no-brainer. Sceptre (talk) 16:27, 13 May 2023 (UTC)
• Support - no-brainer. Reflects current practice. TrangaBellam (talk) 22:05, 13 May 2023 (UTC)
• Support; this is standard practice and best practice; to the extent people sometimes argue the guideline doesn't cover names, it's good to implement clear language. In pre-RFC discussion, it was noted MOS:SURNAME obviates most problems, but it doesn't cover first use, and some trans people change surnames as part of transition, not just in cultures with gendered surnames but also e.g. Fallon Fox, so it's good to close this loophole since we see that this is a topic area where loopholes are gamed. (Re the point above about trolls: that's independent of this change, as it would also effect pronouns and any of the other things we treat self-assessment as best for, e.g. religion or a person's pronunciation of their name; if it ever becomes a problem, we can IAR or rediscuss.) -sche (talk) 01:23, 15 May 2023 (UTC)
• Support. For me, the deciding factor is that the language specifies that this is the self-expressed preference indicated by reliable sources – not something that present-day editors would determine via original research. If the deceased person indicated that preference while alive, then that's that. --Tryptofish (talk) 22:07, 18 May 2023 (UTC)
• Support. Absolutely reasonable proposal. Bastun^{Ėġáḍβáś₮ŭŃ!} 22:12, 18 May 2023 (UTC)
• Support, with a significant caveat that it apply only to WP:BLP subjects. This could necessitate some housecleaning and pedantic disputes now and again, but it seems consistent with the rational underpinning our general GENDERID framework: i.e., putting a premium on respect for self-identification. However, it could be be deeply problematic for historical trans figures, or those historical figures regarded as trans or possible trans by legitimate historical research, where "the most recent" source purporting to indicate the individual's preference could be leveraged to force the use of pronouns not consistent with contemporary research. I don't even contribute heavily in this area (outside of occasional RfCs) and yet even I am aware of at least a handful of articles about historical figures who assumed a gender role separate from their sex, only to be pressured in the frailty of old age back into their birth gender. For this and other compelling editorial reasons, I think it would be an issue if policy didn't retain a distinction between living, contemporary figures living in the social and linguistic context we do, and long-dead figures whose cases require a lot more nuance to parse, including in situations where we have concerns for faithfully reflecting their genders. SnowRise ^{let's rap} 06:51, 19 May 2023 (UTC)

Oppose (MOS:GENDERID topic 1)

• Weak Oppose - I agree that MOST of the time we would and should use the name that the subject prefers… but, if an overwhelming majority of sources use some other name, then so should we. It will be extremely rare for this to happen, but we should not box ourselves into corners. Blueboar (talk) 01:04, 8 May 2023 (UTC)

  That is an argument for inclusion of the deadname in the article, not for principally referring to them by that name (which is what this proposal is about). Thryduulf (talk) 09:29, 8 May 2023 (UTC)

  I don’t see the word “principally” in the proposal. In any case, my weak opposition stands. I prefer to give editors flexibility when it comes to what names to use in an article, and this proposal is too rigid. Blueboar (talk) 10:36, 8 May 2023 (UTC)

  Unless the person has indicated a preference otherwise, why would we refer to the person using multiple names outside of, where encyclopaedically justified, required to note the existence of an context for other names? We do not normally do this for maiden names, stage names, or where a person has changed their name for other reasons (see this version of the Roy Chubby Brown article for an example of what a mess chopping and changing causes). Thryduulf (talk) 11:16, 8 May 2023 (UTC)

  Are you sure about that? Hillary Clinton refers to her as "Rodham" in sections about her life before her marriage, and Cat Stevens uses "Georgiou" for times before he took the stage name and "Islam" after his religious conversion and adoption of a new name. Both strike me as clear and well written. Even the article you link seems to suffer more from poor writing than from the use of given versus stage names. But when it comes to MOS:GENDERID, one of the WP:RIGHTGREATWRONGS factions seems to have won the day. Anomie⚔ 11:54, 8 May 2023 (UTC)

  FWIW, articles like Maya Angelou—a featured article, Courtney Love, and Bill de Blasio don't switch surnames throughout the person's life. I'm also deeply skeptical of the RGW invocation as to this proposal, in particular, since this proposal explicitly relies on reliable sources. I think in this context, that invocation is rhetorically equivalent to "The WOKE generation is ruining everything!"--Jerome Frank Disciple 13:59, 8 May 2023 (UTC)

  Sure, WP:OTHERSTUFFEXISTS. And in cases where there's minimal content using a name, particularly when it's only in a short "early life" section, it may make even make sense. On the other hand, were Hillary Clinton to be rewritten as you and Thryduulf suggest is standard, it would come across as pretty strange. As for your aspersion, all I'll say is that I expected as much from the side that won the day. Anomie⚔ 16:45, 8 May 2023 (UTC)

  We do not normally do this for maiden names, stage names, or where a person has changed their name for other reasons — Yes we do. MOS:CHANGEDNAME specifically says "The names should be distributed throughout the lead to mark major transitions in the subject's life" and "A person named in an article of which they are not the subject should be referred to by the name they used at the time being described in the article" Mitch Ames (talk) 13:20, 8 May 2023 (UTC)

  are you saying that we should mention the previous name or that we should use that name in the article in early life sections and such? the first proposal doesn't say we can't mention the previous name, only that we should be using the most recent name when actually referring to the individual. Tekrmn (talk) 01:17, 12 May 2023 (UTC)

• Oppose on the grounds that it is inconsistent. "Gendered words ... expressed gender self-identification" is consistent (in the use of "gender"). "Name ... person's most recently chosen name" would be consistent (in the use of "name"), but "name ... gender self-identification" is not. Names are not always gender-specific, and we should not be making assumptions that they are.
  Also note that this change would affect articles about living people, not just dead ones, contrary to the purported scope of the RFC. The first words of the sentence are "any person", not "any living person", and it is part of Wikipedia:Manual of Style/Biography, not Wikipedia:Biographies of living persons.
  In any case, mandating a particular name would prohibit sensible use of MOS:CHANGEDNAME and unnecessarily complicates MOS:SAMESURNAME. Several supporters have pointed out that the proposed change is common practice anyway, so what problem are we trying to fix, that common sense would solve? Mitch Ames (talk) 14:29, 8 May 2023 (UTC)

  (1) Would it be easier to just take out "gender" from before "self identification"? The guideline already opens, "Refer to any person whose gender might be questioned" ... I'm not really sure what "gender self-identification" as opposed to just "self-identification" adds. (I'm also really skeptical that this would cause any actual confusion.) (2) I believe living transgender persons are already referred to by the name of their choosing per existing passages in MOS:GENDERID—certainly the biographical article is explicitly covered, but I believe non-biographical articles are covered, too, by the subsequent paragraph (which advises, for example, to say "Jane Doe became a parent" rather than "Jane Doe fathered a child").--Jerome Frank Disciple 14:33, 8 May 2023 (UTC)

  I believe living transgender persons are already referred to by the name of their choosing — So what problem are we trying to fix by introducing restrictions and inconsistencies into the policy? Mitch Ames (talk) 14:55, 8 May 2023 (UTC)

  You left off "per existing passages in MOS:GENDERID"? The inconsistency and the resulting redundant discussions that have stemmed from it are addressed above, but if you don't think there's a need, I totally understand! Thanks for participating.--Jerome Frank Disciple 14:57, 8 May 2023 (UTC)

  Would it be easier to just take out "gender" from before "self identification"? Personally, I've always found that bit of the guideline rather clunky. It's a very verbose way of saying ...that reflect the person's most recently expressed gender identity.... While I think there are bigger issues with the guideline, hence why I originally started the discussions that lead to this set of RfCs, one thing I'd be tempted to discuss at some point after this is over is changing that to be a little more in line with how gender and gender identities are typically described in scholarly sources. Sideswipe9th (talk) 22:19, 11 May 2023 (UTC)

• Oppose I suspect in most cases the proposed option here is how we will do it. However, this shouldn't be prescriptive, instead it should follow sourcing. For example, if sources are mixed in their use after the subject's death then we should be more careful. Additionally, if there is any reason to think the proposed names/gender etc are disputed we shouldn't then assume one vs the other. Basically this should be handled on a case by case basis. Most of the time it will probably result in an outcome that is compatible with the support option but we shouldn't dictate it. Springee (talk) 16:42, 8 May 2023 (UTC)
• Oppose We should use the name most commonly used in reliable sources, like we do for everything else. 𝕱𝖎𝖈𝖆𝖎𝖆 (talk) 13:31, 9 May 2023 (UTC)

  We should use the name most commonly used only in reliable (inc. ABOUTSELF) sources published after the name change, as those from before do not indicate the standard going forward and will inevitably lead to use of the dead name in the article if the change of name was recent and they are still in the majority, even if the dead name is no longer the most generally used. This is especially true with deceased persons, since it can be almost guaranteed that the name will not change any further. In the current political climate, sources that choose to continue using the dead name after a change are often doing so to inflame or make a point, so we should consider whether they can be considered neutral sources for names at all. small jars tc 12:34, 10 May 2023 (UTC)

• Oppose per Ficaia, Springee and Mitch Ames. starship.paint (exalt) 09:53, 10 May 2023 (UTC)
• Oppose, better to take this on a case by case basis than to try and pigeon hole an all-inclusive "rule" that may fail WP:NPOV. —Locke Cole • t • c 04:44, 12 May 2023 (UTC)
• Oppose. If used mechanically it can confuse the reader. No arguments have been presented that the current default policy causes any issues. Alaexis_¿question? 11:48, 14 May 2023 (UTC)
• Weak Oppose This looks like a solution in search of a problem. For the most part this is already standard practice. However the ultimatenauthority is relaible sources. We follow their lead. -Ad Orientem (talk) 23:06, 14 May 2023 (UTC)
• Oppose per Ficaia. Some1 (talk) 01:43, 15 May 2023 (UTC)

Discussion (MOS:GENDERID topic 1)

Nobody has been opposing this. There is no reason to include this in the RFC. Cuñado ☼ - Talk 04:30, 7 May 2023 (UTC)

I assume you mean "there was no reason", so allow me to explain my logic. Even though this does, as I said, capture what the current practice is, I see no harm and in fact think there's benefit to enshrining that practice in a guideline. Perhaps I could have just edited that guidance myself and seen if anyone would revert, but, even though it has yet to receive an oppose vote here, I have in fact seen editors deny that such a practice is endorsed by the guidelines and dispute whether it should be done. Frankly, in terms of whether it's required by the existing guideline, I see why that guideline can seem ambiguous: "gendered words" is explained with an e.g. parenthetical that does not include proper names, and deadnames are only explicitly addressed as to living trans and nonbinary persons. Of course, if you're opposing it on WP:CREEP grounds, I understand, but I think the support so far indicates others agree this should be here.--Jerome Frank Disciple 13:06, 7 May 2023 (UTC)

"Nobody has been opposing this." There was in fact opposition raised when this change was proposed at WT:MOSBIO. Given how contentious changes to this guideline inevitably are, an RFC confirming the change before implementation is the prudent course of action.--Trystan (talk) 16:19, 7 May 2023 (UTC)

The beauty of this format of being three separate but related RfCs, is that if/when we get to WP:SNOWPRO territory, it can be closed independently of the other two sections. Ideally it should run for another few days first, as Trystan is correct in that some editors did object when it was first proposed at WT:MOSBIO and those editors may wish to opine on it here. Sideswipe9th (talk) 16:53, 7 May 2023 (UTC)

Ideally it should run for another few days first, ... editors may wish to opine on it here. — I'm waiting for options on all the topics to stabilise before I !vote. Given that all three are related, I suggest not closing Topic 1 early, SNOW or not. Mitch Ames (talk) 23:59, 7 May 2023 (UTC)

Apparently this RFC is only for editors who agree with Sideswipe9th and Jerome Frank Disciple, so I wouldn't hold out much hope of getting more options. There's already been an edit war over the inappropriate removal of an option, and then a subsequent hatting of the discussion around it. At the end of the day, WP:NPOV is non-negotiable, and WP:NOR is policy, so these style guide changes will always fail ("consensus" or not) when our sources skew the "wrong" way. I see from other replies below we're still engaging in personal attacks against anyone with the wherewithal to even think of opposing the righteousness of the crusade some editors are on. —Locke Cole • t • c 00:45, 8 May 2023 (UTC)

The removal of the additional option was done not for ideological reasons but because there was clear consensus in this discussion, and in the pre-discussion, that it was off-topic. All views are welcome in the RfC, but it is natural that when people have strong feelings about an issue that they will robustly argue those views - especially when some opposing views are seen as offensive to them personally. Obviously all sides should do that without resorting to personal attacks (and I can't immediately see any in this RfC). Thryduulf (talk) 09:42, 8 May 2023 (UTC)

There was no such consensus. Some editors didn't like the option, and strongly opposed it, but it had significant support and there was no consensus to exclude it. The fact that a small group of editors chose to do so, and then edit warred to keep it out, raises WP:RFCNEUTRAL issues. BilledMammal (talk) 10:19, 8 May 2023 (UTC)

The only editors who came close to supporting your proposed option 2a all agreed that because the scope of it would have an effect on the guidance with relation to living trans and non-binary individuals, it was out of scope for this set of RfCs which are focused on the scope of guidance for deceased trans and non-binary individuals. The advice given by those editors, and advice that I would echo is that if you wish to see that change made, make your own RfC about it.

Having re-read RFCNEUTRAL multiple times, I fail to see how the exclusion of an option that was outside of the scope of the question would inherently make the question itself non-neutrally worded. RFCNEUTRAL pretty clearly applies to the RfC statement and heading, as that is what gets transcribed by Logobot, and not the content after. Sideswipe9th (talk) 20:36, 8 May 2023 (UTC)

When I refer to support, I refer to the RFCBEFORE discussion where there was significant support for a position like this. Neutrality in RFC's are also related to the scope of the question; it isn't neutral for editors to exclude an option they dislike, as it restricts the ability of the community to consider that option.

The advice given by those editors, and advice that I would echo is that if you wish to see that change made, make your own RfC about it. To make sure that I have understood you, neither you nor Jerome Frank Disciple would object to a second RfC being opened on this topic, despite the fact that it would overlap with this one? BilledMammal (talk) 20:41, 8 May 2023 (UTC)

would object to a second RfC being opened on this topic, despite the fact that it would overlap with this one? That is what I said yes. While I have an opinion on the proposal that I shall reserve for such an RfC, I have no objection to such an RfC occurring. Whether you wish to hold it concurrently with the three that are already open, or at some point after they are closed, is up to you to decide. Regardless I would support you holding such an RfC. Sideswipe9th (talk) 20:46, 8 May 2023 (UTC)

I absolutely wouldn’t object to a separate rfc covering living trans persons. (To be clear: I don’t take you to be asking whether or not I would be in favor of your proposal—I’d have to read it and your background section & probably see some of the opinions of others first—frankly, very few of the articles I’ve worked on involve living trans and non-binary persons, so I’m not that familiar with the discussions. (To be even more clear: most of the articles I work on don’t involve trans persons at all, but I came across a few that did, and reading the debates as to naming, thought these RFCs might help)—Jerome Frank Disciple 20:58, 8 May 2023 (UTC)

Context/Responses to the above characterization of what happened ... in the below discussion section

Hi! So, I do find it a bit ... fascinating ... that this discussion is happening under topic 1 even though it doesn't at all relate to that topic, particularly given that the discussion below is being mischaracterized. I'll be relatively brief: First, @Locke Cole is wrong, there was not an edit war over the removal of @BilledMammal's proposal, which expanded the scope of this RFC to cover living trans persons. BilledMammal and I, regrettably, did edit war over its placement before reaching a tentative compromise—if you look at Topic 3 now, you'll see, roughly, how this compromise looked. Or, see it for yourself. Second, several editors subsequently expressed agreement that BilledMammal's proposal belonged in a separate RFC. Here's the discussion below for anyone who wants to see for themselves. BilledMammal says his proposal was receiving "significant support". That's also not true. Not including myself, six editors expressed an opinion. One declined to change their vote because, they said, living and deceased trans persons should be treated distinctly. Five others said the option should be removed. Another editor (not myself) removed the option, and it was then placed in the discussion section, as you can see. I'm honestly baffled as to why BilledMammal hasn't started a separate RFC. I don't think it's worth discussing anything further here, particularly given one of these editors is disclaiming wanting to participate while also ... participating through discussion. Locke Cole, I understand your position is that, regardless of the guidelines or the consensus on an article, you'll appeal these issues to as high a court as you can, on NPOV/NOR grounds. Many have explained to you why they disagree with your analysis of NPOV. I guess you think if you go up high enough, you'll find support. Good luck.--Jerome Frank Disciple 13:43, 8 May 2023 (UTC)

I don't think it's worth discussing anything further here, particularly given one of these editors is disclaiming wanting to participate while also ... participating through discussion. Who and what are you talking about here? —Locke Cole • t • c 04:47, 12 May 2023 (UTC)

Comment: there is probably a little bit of overlap between the discussion here, and around article titles. We are specifically talking about how to refer to people, which can obviously mean the article title as well. I do fear a fight between COMMONNAME and this proposal. For instance, we don't change people's article title based solely on what they want to be called (a person going by a stage name e.g. Vic Reeves who no longer wants to go by that name doesn't get to just chose to have their article at their own names). I'm sure there are articles out there that have a performer (or otherwise) only known a name that is a type of deadname (whether that be a stage name or otherwise). In those cases, do we stick with COMMONNAME, or change the name to the gendered full name (that might not be well known)? Lee Vilenski ^{(talk • contribs)} 12:29, 14 May 2023 (UTC)

Hi! It's a great point, and I think it was best touched on by a recent closing editor's closing summary: So, first, WP:COMMONNAME refers to article titles, which means it's almost invariably restricted to biographic articles. And, critically, COMMONNAME includes a proviso that "[a]mbiguous or inaccurate names for the article subject, as determined in reliable sources, are often avoided even though they may be more frequently used by reliable sources". As that closing editor said, that proviso has, historically, been read to allow for GENDERID's instructions (e.g., Elliot Page or, indeed, the page on which the discussion occurred, Gloria Hemingway).--Jerome Frank Disciple 14:18, 14 May 2023 (UTC)

In those cases, do we stick with COMMONNAME, or change the name to the gendered full name (that might not be well known)? The only example of a living trans or non-binary person that I'm aware of where we've stuck with the deadname/stage name over the subject's current name is Suzy Eddie Izzard. The close of the recent move request for that article touches on the interplay between GENDERID, MOS:STAGENAME, and though unsaid COMMONNAME. Sideswipe9th (talk) 16:59, 14 May 2023 (UTC)

I never thought about Izzard, but it makes a lot of sense it would have been discussed there. I doubt it comes up much, but I don't think GENID should trump an obvious COMMONNAME, unless that COMMONNAME is specially a deadname. I'm sure it's a case-by-case thing, but I'm not sure this particular policy should be used to have people known by a new gendered name if they have had a stage name that has been commonly associated with the act (in that, we shouldn't use a person's name as their article title if they aren't known by that name). It does look like that has been addressed, so it's all good Lee Vilenski ^{(talk • contribs)} 17:45, 14 May 2023 (UTC)

As I see it, Izzard's article would comply with the above proposals, as the above proposals don't really touch on article titles. In Izzard's article, she is principally referred to as "Suzy Eddie Izzard".--Jerome Frank Disciple 17:50, 14 May 2023 (UTC)

I doubt it comes up much Yeah, as I said the only living example I'm aware of where it's ever came up is Izzard's article. There are some less obvious counter examples where GENDERID has been an obvious trump to COMMONNAME; Elliot Page's former name is somewhere adjacent to a stage name as the name by which he was credited and known was not his birth name (it was close to it though), Abigail Thorn's former name was also (as far as we're aware) a stage name. In both of those cases the articles were moved shortly after the subjects came out as trans and their new names became known.

It's a tough one to balance, but it's such a rare occurrence that it's (in my opinion) best handled by WP:IAR, with the primary guideline covering the more common transition of John Doe -> Jane Doe or vice versa. . Sideswipe9th (talk) 18:03, 14 May 2023 (UTC)

Topic 2: When to mention deadnames? (MOS:GENDERID 2nd/3rd paragraphs)

If a deceased trans or nonbinary person was not notable prior to transitioning, when should an article mentioning that person include their deadname?

Option 1: Always (3rd paragraph—changes bolded)

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. The birth name or former name of a deceased trans or nonbinary person should always be included in the article. Introduce the prior name with either "born" or "formerly". For example:

Option 2: Sometimes—WP:PLA / majority of sources (New paragraph after 3rd paragraph)

Note: All text is new (bold omitted). For a deceased trans or nonbinary person, their birth name or former name should be included in an article if they were notable under that name or if such inclusion would satisfy the principle of least astonishment, particularly considering the majority of reliable sources discussing said person. Introduce the prior name with either "born" or "formerly". For example: From Leelah Alcorn: Leelah Alcorn (November 15, 1997 – December 28, 2014) ... Note: Alcorn was not notable prior to transitioning, and the majority of reliable sources used her chosen name. 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.

Option 3: Never—Remove "living" from the current policy (2nd paragraph—changes bolded)

If a living transgender or non-binary person was not notable under a prior to transitioning, their former name (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. For example:

Option 4: No change

!votes (MOS:GENDERID topic 2)

• Option 3. Skyerise (talk) 19:00, 6 May 2023 (UTC)
• Option 2 (proposer): I do think it's fair to say that a reader who's seen a name widely reported in the media will be thrown by its absence in an article—that could be true especially if there's initial media confusion about how a person identified. That said, particularly when it comes to individuals whose deadnames are never widely reported, there's no reason to include the deadname. A name isn't in and of itself telling. In these cases, it's, effectively, a piece of trivia. I would secondarily support Option 3. --Jerome Frank Disciple 19:32, 6 May 2023 (UTC)
• Option 3 Full disclosure, I assisted Jerome Frank Disciple with drafting these questions. Option 3 for me is the neatest, simplest, and best way to handle this. As Jayron32 eloquently put on 6 April, treating people with respect and decency doesn't stop at the moment they die. At present, because the second and third paragraphs of MOS:GENDERID restrict the guideline to apply only to living trans and non-binary people, our basic respect and decency actually stops at roughly the moment they die (WP:BDP not withstanding), as at that time the second paragraph of GENDERID ceases to apply and editors can seek consensus to include that person's deadname. In practice, what the changes in option 3 will mean is that when a notable trans or non-binary person who was not notable prior to their transition, like the named examples in the existing guideline of Laverne Cox and Rachel Levine, dies, editors will not be able to insert their deadname simply because that person is now dead. If the article said Jane Doe (born 1 January 1990) today, and Jane died tomorrow, then the lead would read Jane Doe (1 January 1990 - 7 May 2023).
  Some may ask, why is this necessary? If reliable sources call Jane Doe Jane today, won't they continue to call her Jane when she dies? Unfortunately this is not always the case. It is a sad fact that right now, I can go on Google, type in the name of a famous living trans or non-binary person, and usually find at least one reliable media source that has published their name. Typically the only sources to do this are those with a strong socially conservative bias in their reporting, though there are some exceptions. Because of this and the current phrasing of our guideline, when a notable trans or non-binary person dies, it's not inconceivable that WP:V could be met for including that person's deadname. There are also cases where a trans or non-binary person's deadname was never published by a reliable source while that person was alive, but their deadname is published in an obituary. This is most typically done when that trans or non-binary person's family members were not supportive of their transition and denied them agency over their gender identity.
  On the other options, I would strongly oppose option 1, for much of the reasons why I support option 3. For the purposes of aiding in consensus determination, I would also weakly support option 2 but only if option 3 fails. I do have a concern about option 2, that because satisfying the principle of least astonishment is, in many borderline cases, a matter of editorial consensus, it will in practice result in lengthy and occasionally contentious discussions on inclusion versus exclusion of the name after death. Sideswipe9th (talk) 20:13, 6 May 2023 (UTC)
• Option 3: though the guidance has so far been for BLPs, where the situation is particularly sensitive, arguments translate across well enough to apply to dead individuals. It is poor reporting practice to include deadnames, can offend those who knew the subject and is not necessary if the individual was not notable. — Bilorv (talk) 20:17, 6 May 2023 (UTC)

  If deadnames can offend some of those who knew the dead individual, then the new name can also offend some of those who knew the dead individual. The offense can be considered to be either balanced out or impossible to quantify. Thus offense should not be considered as a factor. starship.paint (exalt) 14:01, 8 May 2023 (UTC)

• Option 3. I see the appeal of option 2 but I don't want us to get bogged down in arguments over what is "least astonishing" when some of the people arguing are likely to trolls who will pretend to be astonished just to be disruptive. Option 3 doesn't stop us mentioning previous names so long as they were genuinely notable under those names, so there is no risk of anybody looking for an article under one name, finding the article under a different name and and not being sure whether this refers to the same person. That is the only legitimate purpose for including a deadname. If a subject was not notable under their deadname then adding it helps nobody to find or understand the article. In addition, I strongly agree with Bilorv's comments about the risk of offending friends and relatives of deceased subjects. DanielRigal (talk) 20:38, 6 May 2023 (UTC)

  There is equally a "risk of offending friends and relatives of deceased subjects" even when using the last preferred name. starship.paint (exalt) 14:04, 8 May 2023 (UTC)

  That's true! I agree in principle here—the "friends and family" argument doesn't have much purchase with me, because, hey, even friends and family can be bigots! I think Folly Mox is correct that, in terms of respect, the issue is respect for the transgender community.--Jerome Frank Disciple 14:12, 8 May 2023 (UTC)

  My respect for the transgender community does not exceed adherence to widespread reliable sourcing. Seems clear that plenty of editors disagree, but it's looks like WP:RGW to me. starship.paint (exalt) 14:18, 8 May 2023 (UTC)

  I'm not sure I'd agree that every fact that gets repeatedly mentioned in reliable sources is inherently worthy of inclusion, but it sounds like you're for option 2?--Jerome Frank Disciple 14:20, 8 May 2023 (UTC)

  I've voted down below. I never argued "every fact", the thing is, names are obviously a form of identification, and the lack of identification can be a source of confusion. Omitting hypothetical other facts may not cause such issues. starship.paint (exalt) 14:35, 8 May 2023 (UTC)

  I'm glad your found an option that resonated with you!--Jerome Frank Disciple 14:36, 8 May 2023 (UTC)

• Option 2 or 3: I'm mostly even between these two options because I think they both exclude everything I'd really want to exclude. Option 2 allows for cases where a dead person's deadname became well-known after their death, while Option 3 doesn't. I think there's a reasonable case for either version. I oppose Option 1 since I think there are obvious cases (Leelah Alcorn for instance) where including a dead trans person's deadname would be grossly a case of real-world harm. I oppose Option 4 because its ambiguity as to the case of dead people is what got us into this mess in the first place. Loki (talk) 21:06, 6 May 2023 (UTC)

  FWIW if it comes down to it I think I'd weakly support 3 over 2. But they're both very close for me. Loki (talk) 21:59, 8 May 2023 (UTC)

• Option 2. I don't think PAL or use in a majority of sources is the right test, but it should be included if it is specifically relevant. For example, Brandon Teena mentions several facts about the deadname (its appearance in the paper, its use on the tombstone, its use among a list of other aliases) without stating what it is. At that point, we are clearly writing around a piece of information that would normally be mentioned, in order to avoid offence, which is contrary to WP:NOTCENSORED.--Trystan (talk) 21:10, 6 May 2023 (UTC) edit: Second choice would be Option 4 - no change at this time.--Trystan (talk) 12:50, 8 May 2023 (UTC)
• (edit conflict × 2) Option 3 per DanielRigal, Bilorv and Sideswipe9th. This (like just about every policy on Wikipedia) does not preclude occasional exceptions existing; the only ones that comes to mind are (1) where a person's notability prior to transition is borderline or disputed, and (2) where the person expressed a clear preference for something different. In the case of 2 we should obviously respect that preference, in the case of 1 then I don't see any alternative to an editorial discussion, but that discussion should be framed in terms of their notability under that name and should minimise the use of the name in the discussion. I oppose option 1 as it is very likely to cause real-world harm without any encyclopaedic justification. I oppose option 4 as it will not resolve the issues. Thryduulf (talk) 21:09, 6 May 2023 (UTC)
• Option 2. Always and Never are too prescriptive. There isn't always encyclopedic value in including former names. Conversely, there can be encyclopedic value in including former names. The privacy interest doesn't disappear immediately upon death, but it does fade over time, and eventually the encyclopedic value of including a former name may come to outweigh the residual privacy interest. Barnards.tar.gz (talk) 21:13, 6 May 2023 (UTC)
• Option 4 After reading some of the comments below, I don't believe a change is needed. For living and deceased people, notable deadnames should be included per WP:DUE and WP:NOTCENSORED. For deceased subjects, the inclusion of non-notable deadnames should be decided based on editorial judgment, with no bias towards exclusion. Amending my vote from this. Some1 (talk) 13:42, 7 May 2023 (UTC)

  Small clarification (this was maybe a poor design choice on my part), option 2 would leave the “living” paragraph untouched. It would be inserted below that paragraph. Sorry for the confusion.—Jerome Frank Disciple 21:19, 6 May 2023 (UTC)

• Option 3, weakly 2. Regardless of whether a subject is alive, non-notable deadnames are, by definition, miscellaneous WP:TRIVIA (regardless of how biographically/historically "important" trolls always insist they are), and publishing them (moreover, aggregating and verifying them) imparts little meaningful value to readers except those retrieving them for the sole purpose of causing harm. As Bilorv noted, the potential harm (e.g. to those that love and remember them) of making a trans person's deadname such a readily accessible piece of information (e.g. in the Google Knowledge Graph) does not immediately stop with death. I don't see an especially compelling reason why our criteria for inclusion should expire on a subject's death (certainly, if I were a BLP subject, I would not want that particular sword hanging over my head). –RoxySaunders 🏳️‍⚧️ (💬 • 📝) 22:10, 6 May 2023 (UTC)
• Option 3 I'm not sure why we need to complicate things and create a new standard. Jayron32 puts it well: Treating people with respect and decency doesn't stop at the moment they die. If there's an actual case where someone's deadname only becomes important after their death, we can make an exception in that case/craft a policy exception for those particular cases. Strongly oppose option 1. Galobtter (talk) 02:05, 7 May 2023 (UTC)
• Option 2 as long as it’s relevant to the subject. As per MOS:SURNAME, we should refer to individuals principally by their surname after their full name (and deadname) is mentioned. Yasslaywikia (talk) 02:45, 7 May 2023 (UTC)
• Option 1 or 2 Option 4. The only argument for concealing former names that are reliably sourced would be privacy, and WP:BLP already handles the various concerns around former names and when privacy no longer becomes an issue after death. Former names clearly have encyclopedic value and should only be censored for privacy concerns under BLP. The MOS should not try to decide this issue. Cuñado ☼ - Talk 04:20, 7 May 2023 (UTC)

  Privacy concerns (nor any of the other reasons we don't deadname living people, including basic respect) do not somehow magically disappear after death, they can (and frequently do) impact on family members and friends of the deceased. Thryduulf (talk) 11:04, 7 May 2023 (UTC)

  Which is why our current BLP policy extends privacy considerations to the recently deceased. However, there does come a time when that consideration ends. Blueboar (talk) 11:55, 7 May 2023 (UTC)

  In the case of deadnames and similar, the need for consideration extends for (at least) as long as close friends and family are still living. I also explicitly noted that the reason we do not deadname living people is not solely a privacy matter - basic respect for human beings does not end when someone ceases to be recently deceased. Thryduulf (talk) 16:33, 7 May 2023 (UTC)

  Thryduulf, I'm sure you've seen them, but read WP:GRATUITOUS and WP:NOTCENSORED and tell me how you could justify excluding the former name of a 2-year dead transgender individual because it might offend their living relative? Would you also exclude the images of Muhammad from his bio because it offends some people? Cuñado ☼ - Talk 02:23, 8 May 2023 (UTC)

  Images of Muhammaed have clear encyclopaedic justification, the same cannot be said of deadnames transgender individuals were never notable under. Per Gratuitous and other policies we should never go out of our way to offend people, regardless of why, and that includes never including deadnames without clear encyclopaedic justification. Wikipedia:Offensive material states: Offensive words [...] should not be included unless they are treated in an encyclopedic manner. Material that would be considered vulgar or obscene by typical Wikipedia readers should be used if and only if its omission would cause the article to be less informative, relevant, or accurate, and no equally suitable alternative is available.. This does not make any reference to the time since death - if it is encyclopaedically unjustifiable to include a subject's deadname when they are living or recently deceased, then it is encyclopaedically unjustifiable to do so two years after their death.

  See also Folly Mox's comments in the topic 2 discussion section. Thryduulf (talk) 09:24, 8 May 2023 (UTC)

  That's cherry picking from the policy/guide. WP:GRATUITOUS also says, Wikipedia editors should not remove material solely because it may be offensive, unpleasant, or unsuitable for some readers Former names are not "vulgar or obscene" and they are included in almost every instance whether the former name was notable or not. Former names are "informative", "relevant", and "accurate", and "no suitable alternative is available". WP:NOTCENSORED, Wikipedia may contain content that some readers consider objectionable or offensive‍—even exceedingly so. Attempting to ensure that articles and images will be acceptable to all readers, or will adhere to general social or religious norms, is incompatible with the purposes of an encyclopedia. In this case, arguing to make a special case to exclude former transgender names is trying to make the encyclopedia conform to a social norm from gender theory that suggests it is exceedingly offensive to even mention, informatively, someone's prior name. Wikipedia should not conform. Cuñado ☼ - Talk 17:12, 10 May 2023 (UTC)

• Option 2 or option 4 (in no order). While PLA isn’t the standard I would apply, it is good enough for now. My own perfect version would establish something like: “Mere verifiability is not enough to justify inclusion, but a preponderance of high-quality reliable sources is”. I am also very amenable to letting wiki-biographers of deceased persons decide on a page by page basis. I don’t particularly love the idea that the MOS should rule over any of this (the current deadname guideline is centred on BLP policy, as Cuñado points out), but I do have to remind myself how many pages of discussion we are generating day after day on this stuff. — HTGS (talk) 05:17, 7 May 2023 (UTC)
• Option 4 - no change. Our current policy is good. It respects the subject, while at the same time allowing flexibility in complex situations. “Always” and “Never” are overly restrictive. Blueboar (talk) 11:55, 7 May 2023 (UTC)
• Option 3 or 2. I prefer option 3 as a default, but I think the "always" / "never" words are too strong. We should prefer option 3 in the vast majority of cases, while still allowing exceptions to be made if appropriate for the article in question. stwalkerster (talk) 12:25, 7 May 2023 (UTC)
• Option 2a. I don't understand why this option was omitted from the RfC, but there are circumstances where a living trans or non-binary person was not notable under their deadname, but their deadname should be mentioned in the article due to the level of coverage it has received, such as in the Isla Bryson case. This allowance is also necessary to comply with WP:NPOV and WP:BALASP. I would note that this is already how things should function in practice; as the MOS cannot overrule a core policy, this guideline cannot prevent the inclusion of names which are necessary to comply with NPOV. BilledMammal (talk) 12:34, 7 May 2023 (UTC)

  Happy to explain. This RFC, as the title, questions, and proposals indicate, concerns the deadnames of deceased trans persons.--Jerome Frank Disciple 13:10, 7 May 2023 (UTC)

  This appears to a duplication of our discussion below. BilledMammal (talk) 13:12, 7 May 2023 (UTC)

  Option 4. Thinking further, option 2 or any variant of it is not viable as it can result in WP:BALANCE violations; a name doesn't need to be mentioned in a majority of sources to be due for inclusion under NPOV. It is also impractical, as it is difficult to determine when a name is mentioned in the majority of sources, both due to the difficulty of such a broad evaluation and in terms of determining when a mention should be counted - for example, do passing mentions count? There is also the issue of when a name is mentioned in roughly half of sources; it could result in us switching whether we include the name every time the person is mentioned.

  Option 3 is not an option for the same reason, as well as being a violation of WP:NOTCENSORED. I'll note that for these reasons if there is a consensus for option 2 or 3 it will not resolve anything; as a guideline, MOS:GENDERID cannot overrule a policy (WP:NOT), and there can never be a consensus to overrule a core policy (WP:NPOV). BilledMammal (talk) 01:45, 15 May 2023 (UTC)

• Option 3 - I think it would be good to have this formalized. If that lacks consensus, my second choice would be Option 2, even though I find it tough to imagine a case where the inclusion of a name a trans person was not notable under in an article would assist a reader's understanding of its subject. Hatman31 (talk) 20:51, 7 May 2023 (UTC)
• Option 3. If it's not notable enough to include when they were alive, it doesn't become notable when they die. ℰmi1y_⧼T·C⧽ 05:10, 8 May 2023 (UTC)
• Option 4. I do not think it should be forbidden to include this information for deceased persons. I have not seen any good arguments as to why it should be forbidden; many of the arguments seem to boil down to a plea to impose ideological uniformity. As to whether it's important enough to include, that's an editorial decision at the article level. --Trovatore (talk) 05:19, 8 May 2023 (UTC)
• Option 3 seems the best option. I see nothing magical that happens when a transgender person dies that means we should somehow change the policy at that point. Restricting it to "living" just means that the trolls have a loophole when they can wait until a transgender person dies, and then pounce on the article. We want to discourage that behavior; basically if Wikipedia has determined the information is not encyclopedic for living persons, there's no rationale that suddenly makes it encyclopedic the second they die. Like all policy, I would allow for WP:IAR exceptions where edge cases exist. But for the standard operating procedure, we shouldn't change the way we handle transgender individuals the moment they die. --Jayron32 14:15, 8 May 2023 (UTC)
• Option 2a / Option 2 / Option 4 per Trystan, HTGS, Barnards.tar.gz, BilledMammal and Trovatore. Adding on to their rationale, my thinking is simple - follow the majority of reliable sources. Strong oppose Option 3 as verging on WP:RGW by going against the majority of reliable sources (WP:DUEWEIGHT), and for all those claiming that reasonable exceptions may be carved out - I do not believe it. Far more likely that your proposed MOS:GENDERID will be used as a blunt instrument to prevent any exceptions. starship.paint (exalt) 14:24, 8 May 2023 (UTC)
• Option 4, no change - I do not think there is merit in changing the current policy, which gives the editors flexibility to choose on a case-by-case basis. In particular:
  "Always" and "never" are overly restrictive. (WP:IAR exists, but we should only rarely require it.
  The "majority of reliable sources" is all very well if the majority and minority explicitly disagreed (eg about what the former name was, not whether it existed), but what if 5 sources do not mention the former name but 2 reliable sources do? In that case I think it fair to include the (undisputed) former name. Not everyone who wants to include reliably sourced factual biographical information is a "troll". Our policies, and our discussions, should be assuming good faith.
  WP:PLA is a good policy, but this is not its purpose. It is not intended as a limitation of what we include in an article, which is what option 2 is trying to do. Mitch Ames (talk) 14:57, 8 May 2023 (UTC)
• Option 2 or 3. Multiple participants above have lucidly summarized my thoughts on the matter, especially HTGS (on the strengths of Option 2) and Thryduulf and RoxySaunders (on the strengths of Option 3). ModernDayTrilobite (talk • contribs) 16:23, 8 May 2023 (UTC)
• Option 4 Is this really solving a problem? In the case of living people the BLP protection concerns can be real. However, when dealing with non-BLP cases why not handle it on a case by case basis? As was said above, always and never are overly restrictive and IAR is a rarely used pillar. It would seem that in most cases we are likely to get a result similar to what we get with a BLP case. In the few cases where we don't I would presume there is a good reason why thus we shouldn't prescribe a solution. Springee (talk) 16:51, 8 May 2023 (UTC)
• Option 3: I supported the proposal in topic 1 and I think option 3 best comports with that proposal. voorts (talk/contributions) 21:40, 8 May 2023 (UTC)
• Option 3 If they weren't notable under the prior name, then there's no reason to include it. And this should never have had "living" in it in the first place, because that results in dumb scenarios where the moment one such person dies, then people are free to claim the name should be turned back to their deadname because this policy no longer applied. Which is idiotic. Hence, it should apply to all trans individuals, living or dead. Silverseren^C 22:04, 8 May 2023 (UTC)
• Option 4 I'm not seeing any major reasoning as why we need to be overly instructive when can judge it on a case-by-case basis.  Spy-cicle💥  ^Talk? 02:41, 9 May 2023 (UTC)

  That's fair! I think my concern is that the case-by-case discussions end up looking like policy/guideline discussions. To be sure, there's a tailored option here (option 2), but from looking at a few of these debates, what I've noticed is many people saying "a birth name is inherently relevant" and many people responding by saying "no it's not". Now, we might be having that discussion on a lot of pages, but that doesn't mean we're having a case-by-case discussion. In my best case scenario—the guidance here makes is so that we don't need to repeat policy/guideline debates on article talk pages each time this comes up.--Jerome Frank Disciple 13:13, 9 May 2023 (UTC)

  The "always" option is a red herring. It should have been clarified as something like "never forbidden". It's up to the editors of a particular article to figure out what is and is not relevant in that article. --Trovatore (talk) 17:24, 9 May 2023 (UTC)

  Believe it or not, the argument that a birth name is inherently relevant and encyclopedic isn't all that rare! Though, admittedly, in this discussion, we've only had a couple option 1 supporters—one of whom changed their vote. If you're looking for "unrestricted", the best option is probably option 4.--Jerome Frank Disciple 17:26, 9 May 2023 (UTC)

  I'm on record that birth names are "presumptively" of encyclopedic interest. I see them as on the same level of interest as names of parents, which we routinely report in the "early life" section, and I think the "early life" section is the right place to put birth names as well. But Option 1 is not an option for me — of course it's not the role of the MOS to say birth names should "always" be included. That's an editorial call, not a style issue. --Trovatore (talk) 17:31, 9 May 2023 (UTC)

• Option 1, followed by 4, followed by 2. I don't see why we should have to prove 'a majority of sources' use the person's birth name before we can include it in their Wikipedia article. If a good source reports the birth name, so should we. Most Wikipedia biographies have an 'Early life' section (even though most people weren't notable as children) and information on birth name/s should be included there if there is reliable sourcing. 𝕱𝖎𝖈𝖆𝖎𝖆 (talk) 13:29, 9 May 2023 (UTC)
• Option 4, with option 2 as a best practice. Social mores change, and not everyone who we now call transgender would have thought of their birth name as a strictly private matter, as is common now. (As mentioned below, try writing about the Public Universal Friend without mentioning their former name and see how far you get.) I don’t think wiki policy/style should be strictly dogmatic either way. MarijnFlorence (talk) 13:52, 9 May 2023 (UTC)

  As the person who originally brought up that example I do want to at least mention that there have been versions of the page that did not mention the PUF's former name. I don't think that they were an improvement, but it's definitely possible! Loki (talk) 17:31, 9 May 2023 (UTC)

• Option 2, where the person was notable under a former name it is appropriate that it be mentioned. 4 is a second choice. Definitely not 3. Stifle (talk) 13:58, 9 May 2023 (UTC)

  Clarification: under all the options, where the person was notable under a former name it is appropriate that it be mentioned. The proposals only address what to do as to persons who were not notable under a former name.--Jerome Frank Disciple 14:05, 9 May 2023 (UTC)

• Option 3 If a trans person is not notable under a given birth name, then we don't have any obligation to include it. It's always felt ghoulish to me that we can only consistently apply this principle (under current policy) to living transgender individuals.
  The reason I am against Option 2 is pretty straight forward: All it takes is for one reliable source to exist which says a deadname for someone to try and justify giving it WP:UNDUE weight. A more extreme rule (and yes, I recognize Option 3 might be considered by many to be extreme) is a much easier rule to follow. Here's an example:
  You have a transgender man named Gary Dark, and he dies (rest in peace). Mr. Dark was super popular and lived in a lot of places, so he has 10 different obituaries appearing in regional outlets across his country. 9 of them choose to omit Gary's deadname in his obituary, but the one in his hometown has more relaxed (ie. worse) editorial standards and lets it slip Gary Dark was born Alexa Dark. That one source can then be used to justify including something in our article even if 9 reliable sources made the active decision to omit Dark's deadname.
  Of course, exceptions will exist to this rule, but those can be handled in an actual case-by-case basis. The edge cases shouldn't form the basis for most of our policy ("hard cases make bad law" as the saying goes). In most cases, it's practically never relevant to mention someone's deadname if they weren't notable under that name. If they were notable under their deadname, then Option 3 wouldn't effect them.
  That's my logic, at least. –MJL ‐Talk‐^☖ 01:53, 10 May 2023 (UTC)

  Sounds like you are mischaracterising Option 2, MJL, which says particularly considering the majority of reliable sources discussing said person ... but here you are saying ... All it takes is for one reliable source to exist ... That one source can then be used to justify including something in our article even if 9 reliable sources made the active decision to omit Dark's deadname. starship.paint (exalt) 13:15, 10 May 2023 (UTC)

  @Starship.paint: Option 2 has a large carve out: if such inclusion would satisfy the principle of least astonishment. What that means is going to be subject to endless debate. If, using my example, Gary went to an all-girls high school, would that satisfy the guideline? You could easily make the arguement that a reader might be astonished that Gary Dark went to an all-girls high school.

  I don't think the policy in Option 2 is as clear as it is in Option 3. –MJL ‐Talk‐^☖ 16:43, 10 May 2023 (UTC)

  @MJL: - in this case, with a small minority of sources using Alexa Dark, we could simply write in article text that While still presenting as female, Gary Dark attended an all-girls high school, Stonebridge High School. Wouldn't this be able to solve the problem? Now, definitely, Option 3 is clearer, but clarity is not the only metric that we should be using. I afford weight to.... WP:DUEWEIGHT. starship.paint (exalt) 01:16, 14 May 2023 (UTC)

  IMO that would be ok, but MOS:GENDERID seems to specifically discourage acknowledging that the person ever presented as a gender other than their current identification, recommending ambiguous constructions instead to obscure the issue. Anomie⚔ 12:20, 14 May 2023 (UTC)

  MOS:GENDERID seems to specifically discourage acknowledging that the person ever presented as a gender other than their current identification — I disagree. GENDERID includes (with my emphasis added)

  "Outside the main biographical article, generally do not discuss in detail changes of a person's name or gender presentation unless pertinent. Where a person's gender may come as a surprise, explain it on first occurrence, without overemphasis."

  I.e., it is OK to mention it in the main biographical article, and/or if it would other be a surprise. Mitch Ames (talk) 23:28, 14 May 2023 (UTC)

  The very next sentence after what you quote specifically and directly prescribes the use of ambiguous constructions to avoid "confusion". The example used there seems unlikely to be present outside of the main biographical article (unless maybe it's in an article about a spouse, which raises even more concerns). Anomie⚔ 00:47, 15 May 2023 (UTC)

  [tangent] I have wondered occasionally whether this bit in GENDERID effectively takes a philosophical stand against gender fluidity. We wrote it from the POV that a trans woman was a girl/woman from birth, and so should not be described as a boy who grew up to be a woman. Gender-fluid people do not share that belief (as applied to themselves) and might not appreciate our insistence on the most recent gender as the only "real" one. (I don't know how to fix it without making things worse overall.) WhatamIdoing (talk) 18:37, 15 May 2023 (UTC)

  @WhatamIdoing: I've had that concern as well. Fortunately the guideline as written does allow subjects to "opt out" of the past-pronoun provision, and, while it doesn't have the same clause about deadnames, I honestly think that's more because no one's ever thought to put it in than because there's a strong consensus that trans people can't consent to having pre-notability deadnames used. (I've wavered regarding Sarah Ashton-Cirillo, who fairly frequently mentions her pre-notability deadname, posts pre-transition pictures, etc., and have only held off on ignoring MOS:DEADNAME there for reasons of WP:DUE.) Personally, as an agender person who does not see xemself as having "always been a woman" or anything close to that and whose post-transition name is just a feminized form of xyr pre-transition name, I've jotted down somewhere that if my pre-transition self is ever referred to in mainspace, I don't care what name or pronouns are used. -- Tamzin^{[cetacean needed]} (she|they|xe) 18:49, 15 May 2023 (UTC)

  All it takes is for one reliable source to exist... Sadly this is something that already happens with the current version of the guideline, much less option 2. Earlier this year I created an article about a recently killed transgender teen in the UK. About two days after the teen's death, both the Daily Mail and The Daily Telegraph amended their early reporting to include the teen's deadname. While both papers later removed the deadname after backlash, in the days that followed, a few editors tried to add the teen's deadname citing archived copies of the article from The Times.

  At present, that name can be excluded per WP:BDP, as the teen was not notable prior to transitioning and only achieved notability because of her death. But at some point between now and February 2025, BDP ceases to apply. So what happens then? Under option 2, an editor could make a PLA based argument for inclusion either in good faith or bad to include that teen's deadname, as that teen's killing is being investigated as a possible hate crime due to her gender identity. Even if that discussion is settled by an RfC, because consensus can change, there is always the future potential for another editor to resume or restart the past discussions on inclusion or exclusion of that deadname.

  I'm personally of the opinion that we don't need to ever include that teen's deadname. It's not necessary to understand that she was killed, nor depending on the outcome of the investigation and trial why she was killed. It doesn't add any information that is of encyclopaedic value to the article, and would only serve to intrude upon the privacy of grieving family and friends. But there are editors, both in good faith and in bad, who believe the opposite to myself.

  The problem is that both PLA and WEIGHT is that they are subjective measures, not objective measures. If you ask a hundred editors what constitutes either, you will likely get 100 different answers, because they are both largely defined on individual editorial opinion and discretion. What option 3 provides over option 2 is that option 3 provides both clarity and continuity of the guideline. It closes a loophole in the guidance that currently exists, where upon the death of a trans or non-binary subject who was not notable prior to transition, that name cannot be included solely because of the fact that they are now dead. If the same person was notable prior to transitioning, option 3 would result in no change to the existing guidance, because their deadname would already be included in their respective article.

  Of course, even if option 3 is the version that finds consensus, WP:IAR still exists to handle the small minority of cases where there is a compelling reason to include a deadname after the subject's death that we otherwise could not include during the subject's life. But the American legal maxim of hard cases make bad law is precisely why the guideline should cover the vast majority of articles where (in my opinion) a deadname for a trans or non-binary person who was not notable prior to transitioning should not be considered for inclusion solely because the article subject is now dead. Sideswipe9th (talk) 18:38, 14 May 2023 (UTC)

  So, I'm ... really hesitant to discuss this here, and I've only recently realized it, but it's occurred to me that "notability" might not be the correct test. WP:NOTABLE concerns the threshold for determining who gets their own article. I'm not sure it makes sense to have notability govern deadnames outside of biography subjects.

  Obviously, these cases are rare, but consider a person who commits a high-profile crime, transitions post-sentencing, and then dies. (This is not based on the current high-profile RFC involving a person who transitioned before committing a crime; rather, it relates to another article on WP.) Such a person probably wouldn't be notable, before or after transitioning. Chances are, the crime would warrant an article, but not the person who committed it, per WP:PERPETRATOR (part of the notability policy). But, in all likelihood, the vast majority of articles about such a person would use the person's name at the time of the event, not the post-transition name. That's the type of situation where I think Option 2 has some utility.

  I'm not sure there'd be a serious argument for inclusion of the deadname in the article/situation you mentioned under option 2—by my read, PLA independently wouldn't warrant inclusion, and certainly the "majority of reliable sources" wouldn't, either. Sure, it's a standard rather than a rule, so I guess there's always a chance, but, given WP:IAR, aren't all guidelines and policies standards? Yes, consensus can change and arguments can repeat, but that's just as true regarding a PLA argument as a IAR argument, no? --Jerome Frank Disciple 19:15, 14 May 2023 (UTC)

  To me, the reason for the link between deadname and notability is pretty obvious. Consider that the name of a notable person is very likely going to appear in multiple articles beyond just that person's biography. For example, if the person is a prolific actor, author, musician, or other creative type, their name is going to appear in articles about works to which they contributed. However it's not uncommon for the initial works of a person to be notable long before the person themselves achieves notability. If the guideline didn't link the use of the name with notability, then the primary article about the person might say "Jane Doe (born 1 January 1990), is a [insert nationality here] actress...", while works that involve Jane might credit her as "John Doe".

  by my read, PLA independently wouldn't warrant inclusion Sure, but PLA is pretty subjective, and your or my reading of it is not the only reading. Even majority of RS is somewhat subjective, as some editors will consider that to be 50%+1, while others would require a supermajority of 55% or more.

  but that's just as true regarding a PLA argument as a IAR argument, no? Invoking IAR, whether successfully or not, is a much higher threshold than invoking PLA. In my experience editors would be far more likely to invoke a PLA based exception to an IAR one. With PLA you just need to demonstrate that inclusion of a fact satisfies the base principle, but with an IAR based exception you need to demonstrate how inclusion improves the article in a manner that's currently being prevented by application of a policy or guideline that otherwise prevents it. Those two are not always the same thing. Sideswipe9th (talk) 19:48, 14 May 2023 (UTC)

• Option 2 This approach most harmonizes with our BLP policies. Whether something should be included in a bio should be a basis for a discussion and Option 2 does not *force* this to be included, merely allow a discussion of it. Option 3 basically forces us to censor information even when it's pertinent. Option 1 would be unacceptable for the same reason in the opposite direction. CoffeeCrumbs (talk) — Preceding undated comment added 04:23, 10 May 2023 (UTC)
• Option 2 - The basis of the current status quo is that there is a major privacy value ascribed that overrides aggregating available knowledge. A change to option 3 would ascribe a higher protection than BLP/CRIME. I don't think that comparison holds up, and as such option 2 is best. Nosebagbear (talk) 10:27, 10 May 2023 (UTC)
• Option 3 but... The problem with not mentioning the dead name on grounds of no pre-change notability is that it can become a self-fulfilling prophecy by barring editors unaware of the dead name of the subject from discovering any potential notability established in sources published prior to the name change. We should respect a subject's preferences even after death when it comes to their name, but we should not allow ourselves to sever their identity from their past, which could include possibly notable and contextualising events. The solution IMO is to leave a sourced note of the subject's deadname at the top of the talk page so that anyone looking to improve the article will have access to this information when searching for sources. Redirects from the dead name must also be kept as these allow people with notable information to find the article on which this information belongs. small jars tc 13:09, 10 May 2023 (UTC)
• Option 3 Same as for living people: if the person isn't notable under their deadname, there is no reason to add it. Again, no need to make a special policy against dead people. Chaotic Enby (talk) 14:57, 10 May 2023 (UTC)
• Option 2: I find it hard to say that a person's original name is trivia. That said, we should treat such things with sensitivity and respect which is why I oppose putting any sort of deadnames in the lede or bolding them save for cases where the person was explicitly famous before transitioning. However, with Sophie for example, there are several national-level publications that use her original name, not just a few. For that, I feel that putting her name in the early life section is not any more undue than her exact birthday which has less relevance, less coverage, and is equally as likely to hurt their privacy. And because there is no pushback against exact birthdays for several of the same reasons argued above, it seems that many are here to right a great wrong. (Obviously, the two situations are not the same, but it does help highlight some of why I feel the arguments above are flimsy.) While intentional deadnaming should not be done at all on Wikipedia, and trolls should be banned at the first infraction, Wikipedia is also not censored. Including things that are true, used by reliable sources, and where the person is deceased so as not to get personally denigrated or have their privacy revealed (speaking from a purely pragmatic point) is not offensive in the slightest, especially if it is de-emphasized. (Also, for someone like Sophie that had a small discography under her birth name, I see value in providing the original name. You should not hide a past identity in pursuit of niceness. Note that this proposal is not specific to Sophie, but she provides a nice example of when to oppose.) Why? I Ask (talk) 15:58, 10 May 2023 (UTC)

  Just to clarify: The Sophie example was used in light of the RFC on that page (although I have to admit I missed that there was a no consensus finding there). Obviously the examples should be paradigmatic cases, so if there's a less controversial example, I'd personally be okay replacing Sophie (and given that the examples are meant to illustrate the proposals ... and it's not the case that the proposals are meant to adjudicate the examples ... I don't think such replacement would count as a change to the RFC). That said, I don't really see any evidence of a real controversy concerning the exclusion of Sophie's deadname.--Jerome Frank Disciple 16:45, 10 May 2023 (UTC)

  It's all good, but I think it really shows that there are not a lot of paradigmatic cases. While there are good intentions behind wishing to respect the wishes of the subject to the highest extent, it is often hard to find a case where one transitions later in life and does not already have some coverage of their deadname in their professional career (which, in that case, I would support its inclusion given a verifiable source). I think there are plenty of cases where I would absolutely oppose using the birth name (e.g., Leelah Alcorn or Blake Brockington), but for many (especially in the arts where they may have published under an earlier name), it provides some helpful encyclopedic context. Why? I Ask (talk) 17:05, 10 May 2023 (UTC)

  The examples are, at least for the purposes of this RfC, largely illustrative for how the proposed change would apply. There may well be better examples to use, and those could be substituted in, either now or after the RfC closes if that option finds consensus, without altering the intent of that proposal. Leelah or Blake would probably be a better example than Sophie, and I don't think you'd find any objections to adjusting the example against inclusion of a deadname to use one or both. Sideswipe9th (talk) 19:11, 10 May 2023 (UTC)

• Option 3 per per DanielRigal, Bilorv and Sideswipe9th. ser! ^{(chat to me - see my edits)} 18:37, 10 May 2023 (UTC)
• Option 3 per a mix of the arguments made above. I think the wording about a majority of reliable sources in option 2 is setting out the wrong criterion; deciding how much weight to give any information isn't just about counting how many sources mention it, but also about how much emphasis they each give it and other considerations. XOR'easter (talk) 19:06, 10 May 2023 (UTC)
• Option 3. If someone's deadname wasn't well-known, there's no reason to bring it up in their article, living or dead shouldn't matter. Whether there will be an abundance of clear-cut cases to apply this guideline to is entirely a different matter. TheSavageNorwegian 21:52, 10 May 2023 (UTC)
• Option 4: Options 1, 2 and 3 contradict NPOV, specifically WP:BALANCE, which requires us to treat details proportional to their treatment in reliable sources. None of the proposed texts follow policy. RAN1 (talk) 09:50, 11 May 2023 (UTC)
• Option 3 per Thryduulf, Jayron, and MJL. I'm not entirely against option 2 in principle, but it seems unlikely for reliable sources refer to the subject only by their deadname (thus generating astonishment) unless they were in fact notable under that name. I realize that some editors think this is overly prescriptive, but I agree with those who have argued that additional breathing room is unnecessary and will inevitably lead to disruptive editing. I can't say I support a race to start inserting deadnames to articles six months after trans person dies, followed by incessant wikilawyering over PLA, which was never intended to be a policy or guideline in itself. Folly Mox also makes a salient point: these decisions have broader ramifications than the subject and their family alone, which should not be overlooked. Barring exceptional circumstances, the use of non-notable deadnames is not encyclopedic and would only discredit the project. —Rutebega (talk) 17:07, 11 May 2023 (UTC)
• Option 4, second choice Option 2. We are an encyclopedia; we're here to summarize the world's knowledge. We are not here to make people sad, so we do make compromises to that end, but the dead can not be made sad. Their friends, relatives, and completely unrelated activists can be sad on their behalf, but if we allow everyone and their brother to veto our content, then eventually we will have no content. (Trust me, there are numerous people out there that are eager to say: the very existence of Wikipedia hurts me personally, deeply, and fatally - delete it all!) We need to find a place to draw the line, and "living" seems a good place to draw it. --GRuban (talk) 17:45, 11 May 2023 (UTC)
• Option 3 out of these but in my view the better solution would be to remove "living transgender or non-binary" and other gender/sexuality references to end up with If a person was not notable under a former name, it should not be included in any page... and A person's 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. Furthermore, since it makes no sense to have the resulting stuff in a section entitled "Gender identity", it would probably be appropriate to merge it with WP:CHANGEDNAME. casualdejekyll 21:59, 11 May 2023 (UTC)
• Option 3 I've seen several trans people, some of whom were at least plausibly notable enough for an article, explicitly say on social media that they don't want a Wikipedia article because they're afraid people will use it to broadcast their deadname to the world. MOS:GENDERID has helped with that, but if you can add non-notable deadnames to an article after the subject dies, that sentiment isn't going to go away. And it's a lot harder to ethically write about trans people on Wikipedia if they actively don't want an article because of our policies around deadnames. (Not to mention that there are plenty of people who will want to add a deadname to a trans person's article as soon as they've been dead long enough for purely bigoted reasons, not for any reason related to building an encyclopedia, and that's something we should strongly discourage.) TheCatalyst31 ^{Reaction•Creation} 00:53, 12 May 2023 (UTC)
• Option 3. Option 2 could lead to arguments around the inclusion of birth names for almost any trans or nonbinary person. there should be no ambiguity that the name itself needs to be notable for it to be included. Tekrmn (talk) 19:31, 11 May 2023 (UTC)
• Option 3. We shouldn't much care about the subject's feelings -- they don't have any, cos they're dead. So the default is to perform our remit of informing as much as we can. (However, it would be nice to consider the feelings of the recently bereaved, so like "only if they've been dead five years" (say) would be good. Herostratus (talk)
• Option 4. If I had my druthers, I'd strike the entirety of MOS:GENDERID per WP:RGW. WP:NPOV can perfectly handle this entire scenario from start to finish: this is just unnecessary instruction creep. —Locke Cole • t • c 04:51, 12 May 2023 (UTC)
• Option 4, that the guideline does not and should not apply outside BLP. Decisions about inclusion or removal of content within an article should follow generally applicable principles and policies in the same way they apply to any other content. In particular, those policies are not to be conflated with notability. The guideline should remain rooted in BLP (including the recently deceased, as defined under WP:BDP) and not in freestanding recourse to respect and disrespect that would run afoul of WP:NOTCENSORED. I also agree with Mitch Ames on why Option 2 is a poor rule. Adumbrativus (talk) 06:51, 12 May 2023 (UTC)
• Option 3 preferably or Option 2 per WP:DUE. If they were not notable under their old names there is no encyclopedic value in including it. Yet since the policy right now is needlessly vague about deceased trans people, editors have this same endless fight over several trans articles, including people trying to change a trans biography right after the subject dies. Rab V (talk) 14:26, 12 May 2023 (UTC)
• Option 4 preferably or option 2 I think WP:DUE and WP:NOTCENSORED provide enough guidance here. Option 3 attempts to carve an exemption to NOTCENSORED by saying that actually mentioning deadnames is SO offensive‍ NOTCENSORED should not apply. We really should not be treating different types of potentially objectionable content to different standards. CandyScythe (talk) 16:54, 12 May 2023 (UTC)
• Option 3; I see no reason why we should necessarily split the difference here. Privacy concerns are a sufficient, but not necessary, reason why we shouldn't include non-notable deadnames. Sceptre (talk) 16:27, 13 May 2023 (UTC)
• Option 2 as removing the old name entirely creates a barrier that could completely prevent readers from finding information prior to name change. (Note, I didn't say prior to transition, as name change and transition can happen at different times.) Remember that Wikipedia is not a reliable source itself, it is a compilation of reliable sources, and one of the benefits of Wikipedia is as a gateway to reliable sources elsewhere, which would be impeded by an iron-clad policy of "remove deadnames" of those who were not notable before name change. Even if a person is not notable yet, there could potentially be many sources about them. —Lights and freedom (talk ~ contribs) 22:19, 13 May 2023 (UTC)
• Option 3 or 4. Option 1 is flat-out unenforceable -- if someone's deadname has not been reported, then this wording all but requires editors to either do WP:OR to dig it up and/or to rely on questionable sources (people databases, etc.) Option 2 gets into all kinds of problems about recentism and availability -- there is no guarantee that "the majority of sources" will be evenly distributed pre- and post-transition, or equally accessible -- and seems likely to lead to cherry-picking or mischaracterizing sources. Gnomingstuff (talk) 22:32, 13 May 2023 (UTC)

  Just a side comment on your objection to option 2… if the majority of sources are from pre-transition, then it is highly likely that the subject is notable pre-transition (and thus the deadname should at least be mentioned somewhere in the article, per our current guidance). Blueboar (talk) 23:08, 13 May 2023 (UTC)

• Option 2 per NOTCENSORED. -Ad Orientem (talk) 23:16, 14 May 2023 (UTC)
• Option 3, per DanielRigal, Sideswipe9th, and the reasons I gave in pre-RFC discussion, summarized as: the reasons for not including non-notable deadnames don't change if the person dies. Wikipedia is not an indiscriminate collection of information, and regularly excludes not only gratuitously offensive things people want to include for bad reasons, but even perfectly inoffensive but non-notable things; in pre-RFC discussion, people argued a deadname would help genealogical researchers: so would knowing the person's genealogy (indeed, that would be far more helpful!), yet in a recent RfC about COPHERITAGE, everyone seemed to agree that despite being NOTCENSORED, Wikipedia is not the place for non-notable genealogies. Likewise, I've yet to find an article where a celebrity's non-notable street address is included: despite the help it'd be to the mythical innocent genealogists some people say deadnames would help, it's not notable information. If a person was not notable under their deadname, then even under the aforelinked existing policies and guidelines, it should not be included, and clear language to this effect would be helpful in resolving the many redundant discussions which otherwise come up. -sche (talk) 01:55, 15 May 2023 (UTC)
• Option 3. I honestly don't have much to say besides what has already been said: respect for one's gender doesn't end once a person dies. I wanna point out that the living qualifier was added without consensus by Sdkb in 2020. LilianaUwU ^{(talk / contributions)} 03:41, 15 May 2023 (UTC)

  I wanna point out that the living qualifier was added without consensus by Sdkb in 2020. This was discussed here and refined here, where @Sdkb: participated with other editors at the time. The initial RFC closure was only cautiously in agreement for aligning it with BLP, not expanding it to all living or dead individuals. —Locke Cole • t • c 16:43, 15 May 2023 (UTC)

Extended disagreement on whether current version (“living”) has consensus

No prior discussion can bind us against holding another discussion. Everything is open for change, including policies and guidelines that may have been agreed to by a prior consensus-based discussion.--Jayron32 16:49, 15 May 2023 (UTC) Who are you talking to? —Locke Cole • t • c 16:54, 15 May 2023 (UTC) You had mentioned that there had been a prior discussion on this matter, which had at the time determined to limit the matter to living individuals only. I was letting you know that even if true, it's not terribly important, and consensus can always be changed with a new discussion. --Jayron32 17:05, 15 May 2023 (UTC) You must have missed the quoted part, I was only addressing the claim that there was no consensus for the addition and clarifying the discussion around that. Please do be more careful in the future when reading discussions. —Locke Cole • t • c 17:19, 15 May 2023 (UTC) I will be sure to give your advice its due consideration. --Jayron32 17:33, 15 May 2023 (UTC) At the time of the addition, there was no consensus for it. Neither of the proposals in the preceding RfC contained language that restricted the applicability of the deadname provisions as a whole solely to living people. Loki's proposed version did add the clarifier that for living people, a non-notable deadname should be treated as a BLPPRIVACY issue, but did not restrict the first part of the rewording to only living people. In the subsequent section, there were three comments made prior to Sdkb changing the guideline to restrict it as a whole to living people only. One from Sdkb rationalising why the deadname provision should be restricted only to the living, and one from Armadillopteryx stating clearly that Some explicitly referenced WP:BLPPRIVACY, but others presented a rationale that could be reasonably interpreted to cover dead subjects as well. The discussions that followed from 17 October onwards focused on the point as to how the then newly updated deadname guideline was to be interpreted with respect to mention of the deadname in infoboxes and throughout the article's text. The living restrictor wasn't discussed in detail until almost a year later, in a subsequent RfC. Sideswipe9th (talk) 18:46, 15 May 2023 (UTC) @Sdkb and Armadillopteryx: (since apparently this abusing {{noping}} behavior is catching). As Sdkb noted elsewhere, WP:SILENTCONSENSUS is a thing, and that the language used stood unchallenged for a year after the discussed change tells me there was no significant dispute over it. This fully refutes LilianaUwU's claim that the edit was made without consensus; there was discussion, no objection, and the edit was made and has withstood the test of time. —Locke Cole • t • c 19:00, 15 May 2023 (UTC) I think everyone has made decent points here! But, as everyone has also acknowledged, the origin of the modifier is, for the most part, not super relevant, because, as Jayron pointed out, even if it was adopted via consensus, that prior discussion isn't binding on this one, but, as Locke Cole has pointed out, even if it wasn't the consensus of the discussion, it is the current status quo (affirmed sub silentio). :) --Jerome Frank Disciple 19:12, 15 May 2023 (UTC) there was discussion, no objection Hard disagree. There was an objection, due to the ambiguity over whether or not the intention of contributors to the preceding RfC was to restrict the guideline as a whole to living people only. The subsequent discussion was then focused on a different objection about another part of the proposed change. Also I disagree on my use of {{np}} being abusive. WP:NOTIFY states that notifications should be given for discussions about another user, however my comment is not a discussion about another user. I mentioned and quoted from Armadillopteryx's 2020 reply to Sdkb when summarising the context surrounding the addition made by Sdkb, but made no other comment about it or them as an editor or their conduct. Sideswipe9th (talk) 19:14, 15 May 2023 (UTC) Cool story, bro. —Locke Cole • t • c 19:16, 15 May 2023 (UTC) Since apparently we're edit warring to keep this open even though it has no relevance whatsoever to what I said, I guess I need to add that I never implied or stated the prior consensus was immutable and unchangeable. This whole subthread strikes me as an exercise in "templating the regulars". I also don't hold out much hope that Jayron32 was sincere when stating they would give my advice its due consideration when they used the edit summary "Cool story, bro." —Locke Cole • t • c 18:47, 15 May 2023 (UTC) No, I sincerely gave all of the consideration your advice was actually due. --Jayron32 11:19, 16 May 2023 (UTC)

• Option 1. One of the difference between articles about living people and deceased people is that official records such as birth certificates may be used for deceased people but not for living people. Names before a gender transition are useful in facilitating research among offical records. Jc3s5h (talk) 18:38, 15 May 2023 (UTC)
• Option 3. If a person was not notable under their deadname during their lifetime, that name is trivial and its inclusion is undue (2nd pillar). MOS:GENDERID is a guideline and many of the arguments in favor of Option 2 point to outlier cases which would be allowed as occasional exceptions. Option 3 is a simpler solution, far easier to implement and understand. gobonobo ^{+ c} 16:25, 17 May 2023 (UTC)
• Option 3 options 2 and 3 are very simmilar and 3 is just simpler. Further it avoids the weird situation of arguing about whether or not to include a deadname after someone dies—blindlynx 19:32, 17 May 2023 (UTC)
• Option 2, though option 4 is also acceptable. I have concerns about the application of MOS:GENDERID and the "do not include deadnames for living people who were not notable under that name" (for example, when and how is notability established?), but I feel that the rule itself is acceptable, given its inherent ties to WP:BLP and how Keffals was targeted and harassed merely for being transgender. The concerns over harm to people necessarily cannot apply to dead people, and thus I oppose extending the rule to cover dead people as well. However, any such name is going to need really good sourcing to be acceptable. -BRAINULATOR9 (TALK) 19:45, 17 May 2023 (UTC)
• Option 2. I think it's reasonable to take a case-by-case approach, and I think it's frequently encyclopedic to include the birth name. Including it in this way is not disrespectful, just informative. --Tryptofish (talk) 22:13, 18 May 2023 (UTC)
• Option 3 strongly preferred, but weak support for Option 2 if, for whatever reason, option 3 wasn't a runner. We do not need to know the deadname of someone who was never notable under that name. Bastun^{Ėġáḍβáś₮ŭŃ!} 22:18, 18 May 2023 (UTC)

Discussion (MOS:GENDERID topic 2)

I'd like some clarification on option 1. Would the mentioning be in the lead section? Or would it be farther down into the body in, say, the 'Early life' section? I'm reading the poll so far and it makes me think that one or two editors are taking the wording to mean that it would be in the in the lead section or even in the first sentence. SWinxy (talk) 23:29, 6 May 2023 (UTC)

Hi! Under option 1's framework, the deadname would not necessarily be confined the lead, but I think in your average case it would be there. Rather, an article would use a deadname any time the person's full name was referenced. Now, per MOS:SURNAME, that's usually just in the lead if we're talking about the body of the article, but if there's a template with the person's full name, it would also be there, or if there's a mini-bio section (which does happen), it might be there, too.--Jerome Frank Disciple 01:51, 7 May 2023 (UTC)

In my view, the natural place to mention the name would be in the "early life" section rather than the lead, same as we often report parents' names and other birth details. --Trovatore (talk) 05:23, 8 May 2023 (UTC)

I think the topic should be "When to mention deadnames?", rather than "...reference...", as the former is more specific and consistent with the proposed changes. "Reference" has specific (different to "mention") meaning in Wikipedia. Mitch Ames (talk) 12:13, 7 May 2023 (UTC)

Fixed! Sorry about that—I thought I had caught it before I opened. I originally used "first reference" quite a bit because that term is in MOS:GENDERID (although MOS:SURNAME says "initial mention", which is maybe less ambiguous).--Jerome Frank Disciple 12:17, 7 May 2023 (UTC)

I was thinking to include their original name in the lead. Most of time, saying "their name" (formally "their former name") should be avoided though. See MOS:GENDERID for more details. Cwater1 (talk) 17:17, 18 May 2023 (UTC)

@Skyerise, Jerome Frank Disciple, Sideswipe9th, Bilorv, DanielRigal, LokiTheLiar, Trystan, Thryduulf, Barnards.tar.gz, Some1, RoxySaunders, Galobtter, Yasslaywikia, Cuñado, HTGS, Blueboar, and Stwalkerster: Ping editors who have participated to notify them of the addition of an option 2a. BilledMammal (talk) 12:38, 7 May 2023 (UTC)

With respect, I'm placing option 2a below your vote. This RFC concerns only the deadnames of deceased trans persons—that's in the questions asked, and it's in the lead section description. From my perspective, if you want to discuss other topics, I think that should be in a separate RFC.--Jerome Frank Disciple 12:58, 7 May 2023 (UTC)

I've moved it back. It's a significant option, and very relevant to a discussion about when we should mention these names. Further, the BEFORERFC included discussion of this option. Excluding that option, or otherwise lowering the prominence of it, raises WP:RFCNEUTRAL issues. BilledMammal (talk) 13:04, 7 May 2023 (UTC)

Dispute over whether an RFC concerning the "deadnames of deceased ... persons" also covers the deadnames of living persons

I disagree, thanks. You are welcome to start your own RFC. As I said, this RFC concerns the deadnames of deceased persons.--Jerome Frank Disciple 13:08, 7 May 2023 (UTC) You don't own an RfC after you start it. If an editor wishes to include a new option they are free to do so. I also don't understand your objections; what is the issue with including it with the others, and what is the benefit of putting it at the bottom instead? BilledMammal (talk) 13:11, 7 May 2023 (UTC) Please find me where on WP:RFC it says that the scope of the RFC can be unilaterally changed by a user responding to the rfc. Also, your neutrality charge is nonsensical. All your proposal does is take the existing proposal and also apply it to living persons. That doesn't mean the existing proposal is non neutral.--Jerome Frank Disciple 13:15, 7 May 2023 (UTC) Adding an option isn't changing an RfC. It is commonly done, and to edit war to try to hide that option is disruptive. BilledMammal (talk) 13:18, 7 May 2023 (UTC) You are changing the scope of the RFC. Again, feel free to point to anything on WP:RFC supporting you. But because you apparently need your option to be in the top, I'll introduce it. --Jerome Frank Disciple 13:20, 7 May 2023 (UTC) It's within the scope of when to mention deadnames. Further, it's unclear why you attempted to limit the scope from the scope discussed at the RFCBEFORE. Finally, the comment you make in the opening statement regarding option 2a does not comply with WP:RFCNEUTRAL. BilledMammal (talk) 13:23, 7 May 2023 (UTC) That's not the scope—and that's not what "within" means The questions asked, the section title, and the proposals make clear that the scope is the deadnames of deceased trans person. Your argument is the equivalent of saying that "NCAA basketball games" are within the scope of "NBA basketball games" because of the word "basketball". For the record, I'm also still quite dubious that you can (1) include your proposal alongside the proposals, particularly when it does expand the scope of the RFC to a different question, and (2) try to insist on the order it's placed in (could a user place a proposal above the proposer's proposal? ... notwithstanding that you did partially do that).--Jerome Frank Disciple 13:26, 7 May 2023 (UTC)

Although I think the example is a valid one to discuss, the distinction between living and deceased people is significant enough that the two cases are worth treating separately. So I am not changing my response. Barnards.tar.gz (talk) 13:30, 7 May 2023 (UTC)

I agree with Barnards.tar.gz and Jerome Frank Disciple - whether to change the existing consensus regarding living people should not be part of an RfC about people who are not living and attempting to force it in is disruptive. Thryduulf (talk) 16:30, 7 May 2023 (UTC)

I agree with Jerome Frank Disciple that this should be discussed in a separate RfC. What to do in the cases of living people has been discussed extensively already. You are not going to get a consensus to change that in an RfC explicitly about deceased people. Please don't shoehorn such a change in, and force the RfC to include it - doing that is disruptive. Galobtter (talk) 14:29, 7 May 2023 (UTC)

I've removed it; this was also proposed by the user prior to the opening of the RFC and these issues were noted by most users who opined on it even at that time. -sche (talk) 16:39, 7 May 2023 (UTC)

I agree with the removal, and the comments that the proposal was entirely out of scope for an RfC on how to handle the deadnames of deceased trans and non-binary people. If BilledMammal wishes to seek this change to GENDERID for how we handle the deadnames of the living, then it should be discussed in a separate RfC. Sideswipe9th (talk) 16:47, 7 May 2023 (UTC)

Just for context, BilledMammal's 2a would have been:

Option 2a: Sometimes—WP:PLA / majority of sources (New paragraph after 3rd paragraph) (all trans and nonbinary persons, both living and deceased)

Note: All text is new (bold omitted). For a trans or nonbinary person, their birth name or former name should be included in an article if they were notable under that name or if such inclusion would satisfy the principle of least astonishment, particularly considering the majority of reliable sources discussing said person. Introduce the prior name with either "born" or "formerly". For example: From Sophie (musician): Sophie Xeon (17 September 1986 – 30 January 2021) ... Note: Sophie was not notable prior to transitioning, and the majority of reliable sources used Sophie's chosen name. 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.

I also agree with the removal, and in fact actively oppose 2a just like I did in the discussion above. A living trans person's deadname should not be included under only PLA. Under time pressure right now, but I can find the real-world harm policy that overrides the policies BilledMammal cited above in WP:BLP later. Loki (talk) 18:37, 7 May 2023 (UTC)

I won't be not-voting on this RFC, because I noticed myself becoming emotionally reactive in the thread where it was first being discussed, plus now the words are so many that my poor brain keeps dropping two thirds on the floor when I'm tryna read the other bits, but I did want to mention one thing here, I guess as a matter of consideration / clarification.

I see (and have seen elsewhere) people bringing up the idea of respect for the dead, respect for the relatives of the dead, respect for the victims of the dead, etc, and I'm under the impression that people are missing out on considering a key demographic: every living trans person with no relation to the subject who ever reads the article. To my mind, sloppy and limited as it may be, something I feel like we should care about is the project's general reputation regarding respect for trans people. Whatever anyone's feelings are about a perfidious dead trans criminal or their surviving family members, mentioning deadnames in prose any more frequently than the minimum required of a thorough encyclopaedia article may well give the impression to uninvolved readers that wikipedia doesn't care about respecting trans people. (For the record, in our editor-facing spaces, my opinion is that our sensitivity is more than adequate.) Folly Mox (talk) 22:11, 7 May 2023 (UTC)

the words are so many—First, I'm so sorry about the verbosity! I take full responsibility for that—Sideswipe9th did her absolute best to help me cut it down. I did think splitting the issue into 3 questions was the best approach, and—despite my naturally verbose nature—I swear I tried as best I could to make the proposals as straight forward as possible. Second, I absolutely agree with 100% of your comment and genuinely appreciate the input.--Jerome Frank Disciple 22:16, 7 May 2023 (UTC)

You are coming from a good base of concern. I do have a bit of worry about making our goals focused on the reputation of Wikipedia rather than the quality of Wikipedia. Us having concern about Wikipedia being respectful of trans people (within a larger context of being respectful of people in general, but with specific issues in mind) is good. Us being concerned about whether people will see us a respectful, at least in any way that interferes with making this a quality encyclopedia, is less good. (To draw a parallel with other guidelines, us not allowing bigoted aspersions on Islam is good, but it would be wrong for us to start putting (PBUH) after each invocation of the Islamic prophet's name, which would be showing respect, would be wrong.) Having said that, I suspect that in most cases being respectful will look much the same as conveying our respect for trans people. --Nat Gertler (talk) 12:15, 8 May 2023 (UTC)

• I've sat out most if not all the GENDERID discussions up until now. I expect my following question is going to garner some heat: Why are we treating trans people like a special protected class with regards to the naming issue, and how do our methods not obviously violate WP:RGW and WP:NOTCENSORED? To my knowledge, the basic standard for including former names of a person is that we have basic RS confirmation for those former names. I understand that the "encyclopedic" value of someone's former name under which they were not notable is arguably minimal depending on the circumstances, but then shouldn't our guidelines universally recommend an "old name" purge for nearly everyone? Jessie Rae Scott, like many women of her time, was not notable under her maiden name, so should we ban mention of it? US President Gerald Ford Jr. was renamed by his family at a young age after his stepfather, so that he wouldn't carry the name of his violently abusive biological father, Leslie Lynch King. Why don't we offer extra sensitivity to him and his family? Why don't we update all mentions of any Muslim person who has ever completed a pilgrimage to Mecca to always reflect the "Al-Hajji" prefix they adopt to show we respect their faith regardless of chronology? As it stands, GENDERID guidance is stricter than WP:BLPCRIME in terms of "past potential unpleasantness for the subject" being allowed mention.

Yes, I know there are violent and malicious actors out there who enjoy deadnaming trans people to be bullies, and in some places in the world its basically a "pass as cis or be grossly denied basic human rights" situation. But why are bending over backwards to try to "protect" these subjects and not others? I can't think of many other issues where we so cautiously avoid mentioning things that are socially or politically inconvenient for the subject (whether that be people, corporate entities, or communities). Either everyone should have an about-equal standard, whatever that standard may be, or we should just admit we have no interest in being neutral on this issue. -Indy beetle (talk) 19:42, 10 May 2023 (UTC)

If you can point to another class of people where there old names are routinely weaponized like that, I imagine the community would give that consideration. Most name changes don't have that consequence; Holly Robinson Peete is probably not bothered much if everyone knows she used to be Holly Robinson. We have many ways in which we treat people in different categories differently, such as separating how we treat public figures from non-public figures, or minors from adults. WP:BLPPRIVACY discusses types of information that we may have that we should not include, as what little they add to the understanding of the topic is outweighed by their potential for damage. -- Nat Gertler (talk) 19:58, 10 May 2023 (UTC)

Why don't we offer extra sensitivity to him and his family? That's a fair question. There's a lot I think we handle incorrectly with regards to name changes in general, particularly so for individuals who have had to change their names for serious issues like being victims of abuse (historical or current) or crime. While ultimately I would love to see us address that deficiency in MOS:CHANGEDNAME, in a manner that would let us seamlessly integrate the deadname provisions of GENDERID without the current state of making trans and non-binary name changes separate, I think changes along those lines are (sadly) less likely to find consensus. Sideswipe9th (talk) 20:25, 10 May 2023 (UTC)

Because trans "rights" in general are a current political football, so we get people here on both sides trying to have Wikipedia conform to extremist views. Neutrality has not so far won out. Anomie⚔ 21:09, 11 May 2023 (UTC)

The wildly different definitions of what neutrality is mean I don't think any one person is capable of knowing which position even is neutral. casualdejekyll 21:31, 11 May 2023 (UTC)

Actually, I agree with you here. And by that I mean we should hold the same standard to all people by removing UNDUE coverage of previous names. I know I've said this before in one of these wall of text discussions. (Incidentally, none of the three sources cited for Scott's maiden name appear to actually mention her maiden name - The News And Observer says nothing, a Google Books search of the book doesn't have the claimed maiden name in it except as a first name, and the ABC link appears to be dead. As such, I've taken it out of the article in question.) casualdejekyll 21:45, 11 May 2023 (UTC)

I feel like this RFC has a biased setup and doesn't include the option that makes the most sense. Options 2 and 3 are largely the same thing and 2 can be misunderstood as the status quo, when it's not in the details. Cuñado ☼ - Talk 16:50, 11 May 2023 (UTC)

Contingent question: If option 3, how should redirects be handled?

At ongoing RfD, we have an emerging consensus that a redirect from a deadname that is not mentioned in the target article is acceptable because the article discusses the deadnaming of the subject, includes a quote that originally contained the deadname but has been (correctly) modified to exclude it, cites sources that use the deadname, and is about someone buried under her deadname. If option 2 or 3 passes, it is unclear how such redirects would be affected.

In the event of option 3 passing, what should apply to redirects? I'll give these ones letters to disambiguate.

Option A: Always permissible if verifiable (2nd paragraph—changes relative to Option 3 bolded)

If a transgender or non-binary person was not notable prior to transitioning, their former name (deadname) should not be included in any page (including lists, redirects, disambiguation pages, category names, templates, etc.), even in quotations, even if reliable sourcing exists, with the exception of redirects from deceased persons' verifiable deadnames. Treat the pre-notability name as a privacy interest separate from (and often greater than) the person's current name. For example:

Option A2: Always permissible if verifiable in secondary sources (2nd paragraph—changes relative to Option 3 bolded)

If a transgender or non-binary person was not notable prior to transitioning, their former name (deadname) should not be included in any page (including lists, redirects, disambiguation pages, category names, templates, etc.), even in quotations, even if reliable sourcing exists, with the exception of redirects from deceased persons' deadnames when the name has been included in secondary sources. Treat the pre-notability name as a privacy interest separate from (and often greater than) the person's current name. For example:

Option B: Limited exception when relevant (2nd paragraph—addition of footnote to Option 3 text)

If a transgender or non-binary person was not notable prior to transitioning, their former name (deadname) 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. For example: Notes

Option C: No explicit carve-out but affirming that occasional common-sense exceptions to guidelines exist.
No change to text.

Option D: The prohibition on such redirects should be taken as absolute or near-absolute.
No change to text.

-- Tamzin^{[cetacean needed]} (she|they|xe) 18:43, 12 May 2023 (UTC)

!votes (GENDERID topic 2 redirects question)

• Option B or C. Hard oppose both A and D. Our avoidance of deadnaming the living is informed by both dignity and privacy. With the dead, the motivation of dignity remains, but there is no longer a privacy interest, which means that there is more of a need to balance with legitimate navigational needs. Someone seeing the deadname of a deceased trans person in a newspaper clipping or on a gravestone should be able to find the correct Wikipedia article for that person; this furthers our encyclopedic mission without publicizing anything that wasn't already public. The article's discussion of deadnaming should adequately resolve any confusion the reader may have as to why they wound up at that title. And by keeping any exception limited, we avoid opening the door to outing-by-redirection of the dead. -- Tamzin^{[cetacean needed]} (she|they|xe) 18:43, 12 May 2023 (UTC)
• Option C to avoid instruction creep. casualdejekyll 21:52, 12 May 2023 (UTC)
• C or D to avoid instruction creep. I'm honestly not terribly convinced by the argument that someone might come to our website by a deadname. Loki (talk) 00:54, 13 May 2023 (UTC)
• D, second choice C. If we make a choice that a name doesn't merit inclusion in an article, it makes no sense to redirect readers looking for more information on that name to that article and expect them to just guess why. It would be an WP:EASTEREGG redirect.--Trystan (talk) 06:14, 13 May 2023 (UTC)
• B; I don't think instruction creep is too great of an issue here, given it's in a footnote, but I'm not necessarily opposed to option C. Options A & D are too strict; IAR exists for a reason. Skarmory (talk • contribs) 10:29, 13 May 2023 (UTC)
• Option D as "near-absolute" (which is basically option C). In addition to what everyone else has said, unfortunately people can be pretty terrible regarding trans people and it is easy to imagine a scenario where such a redirect is vandalized. That vandalism is likely to go undetected because redirects are less patrolled in general, and (a bit ironically) because if someone's deadname isn't in an article, people are are less likely to know about and monitor it. The best deterrent is not having the redirect page in the first place. Gnomingstuff (talk) 22:14, 13 May 2023 (UTC)
• A, this is really an advocacy/NPOV issue. —Lights and freedom (talk ~ contribs) 22:26, 13 May 2023 (UTC)
• B - Tamzin's reasoning is generally good here, but I think that C would end up acting as a de facto narrowing. I don't believe it would be a particular aspect of instruction creep compared to the overall deadnaming rules. Nosebagbear (talk) 01:04, 14 May 2023 (UTC)
• A - we have failed in our mission as an encyclopedia, to inform people, to distribute knowledge, if we cannot even bring people to the correct page when using the name of an individual. Even if this name is a previous name, this should not affect the matter at all. Oppose B, C, D under WP:RIGHTGREATWRONGS, Lights and freedom is correct, this is just advocacy. If editors like Gnomingstuff are worried about vandalism, implement semi-protection. starship.paint (exalt) 01:28, 14 May 2023 (UTC)

  Semi-protection would help, if it's implemented indefinitely and proactively. This is beyond what's recommended in WP:SEMI and, more importantly, relies on people actually doing it. Gnomingstuff (talk) 14:39, 15 May 2023 (UTC)

• A We should follow the sources, not the presumed wishes of the subject/s. 𝕱𝖎𝖈𝖆𝖎𝖆 (talk) 02:47, 14 May 2023 (UTC)
• B or C ... narrowly oppose A, D. I think redirects should be judged by their usefulness. In the event of some persons, assuming their birth name wasn't widely reported, it'll make little sense to have a redirect, because no one is going to, for example, head to some fairly weak secondary/tertiary source, see the subject discussed, see the name used, find the birth name mentioned, and then, in good faith, search wikipedia for that birth name, thinking that's the best way to find the person. At the same time, if the birth name is widely reported or even often used by other sources as the principal name, then the calculus changes.--Jerome Frank Disciple 13:26, 14 May 2023 (UTC)
• C If the deadname is non-notable, then a redirect should not exist; IAR will apply even under option D. voorts (talk/contributions) 18:08, 14 May 2023 (UTC)
• A, this is an encyclopedia, not a battleground to try and WP:RGW. We don't suppress knowledge or self-censor what reliable sources verify. Pretty much every single proposal here has the wheels falling off when you start considering WP:NPOV, WP:NOR and WP:V. Even MOS:GENDERID as written runs afoul of policy. Trying to disallow redirects from well source/verifiable names to their subjects is lunacy. —Locke Cole • t • c 18:43, 14 May 2023 (UTC)
• (edit conflict) C, very strongly oppose A. Like other redirects without mentions these are normally not helpful (and are sometimes actively harmful) so the presumption should be against inclusion but exceptions exist. There are many possible reasons for an exception, and I don't think listing only one is particularly helpful because some people will read it as suggesting that every time X applies a redirect should exist, but every case needs examining on its individual merits. Factors to consider include the frequency of the name's inclusion in sources, the nature of those sources (including but not limited to reliability, age, topicality and partisanship), other people with the name (especially any who are borderline notable, e.g. we shouldn't normally redirect the verifiable but very obscure deadname of a trans individual to their biography when there is a very prominent individual with the same name who people are more likely to be looking for, even we don't have an article about them (yet)), how open the subject was about both being trans and their former name, etc. Note this does not exclude redirects needed for navigation, it just requires that the need be demonstrated as both real and as, on balance, more beneficial than harmful. Thryduulf (talk) 18:49, 14 May 2023 (UTC)
• C, Oppose A I think common sense applies here. If there is actually a reasonable belief that people will search for the name, such as it being a name that is being used at least somewhat prominently in coverage, then common sense would be to make a redirect. However, if the name is not and their chosen name is the one receiving the coverage (or in cases where news is using their chosen name and just mentioning the dead name merely as an aside of "born ***" or "previously known as ***") then I don't see the need for a redirect because people will know and be using the correct chosen name to search for. So a redirect serves no purpose and is only punitive. Silverseren^C 19:19, 14 May 2023 (UTC)
• C, Oppose A, Neutral on B. If reliable sources don't make the deadname notable enough for it to be mentioned in the article, it isn't notable enough for a redirect. D doesn't make too much sense either because of WP:IAR. Arguments coming from the point of "this is an encyclopedia" or WP:NOTCENSORED forget tht we don't include literally every WP:GRATUITOUS piece of information on Earth, and that (even outside of deadnames) redirects from topics that aren't mentioned in the article itself is basically WP:EASTEREGG and not recommended. Chaotic Enby (talk) 19:30, 14 May 2023 (UTC)
• C or weak B. As several people have mentioned, a redirect from a name that doesn't appear in the article is rarely if ever going to be useful. Even if something is verifiable, it doesn't necessarily belong on Wikipedia. —Rutebega (talk) 20:33, 14 May 2023 (UTC)
• Judge it on a case by case basis - I suppose this is somewhere between B and C… but my opinion does not fully fit in either. Essentially, I am opposed to trying to make any firm and fast “rule” on anything relating to deadnames. What is appropriate for one subject won’t be appropriate for others, so exceptions are always going to be necessary. Having No “rule” would be better than an inappropriate rule. Blueboar (talk) 20:49, 14 May 2023 (UTC)
• C: if it's not public enough to go in the article, nobody's ever going to search for that as a page title either. In the presence of WP:IAR, D reads functionally equivalent to C to me. ℰmi1y_⧼T·C⧽ 20:52, 14 May 2023 (UTC)
• B as most aligned to normal practice outside of this topic area, where a former name would be an obvious use case for a redirect. Harm-based arguments against this seem tenuous if the person is deceased, and a redirect is not highly visible. Barnards.tar.gz (talk) 21:28, 14 May 2023 (UTC)
• Strong A (edit: or B; I really can’t tell the difference without my lawyer present): At the point of redirects, the interest is strictly one of privacy, and privacy is an interest which expires with the subject. I would like to express a need for verifiability sans doubt though. (And big congratulations on making this an absolute stinking mess of an RFC.) — HTGS (talk) 23:02, 14 May 2023 (UTC)
• A2. Redirects are to help the reader find the article they are looking for. If a name is used in secondary sources, then it is possible that readers will look for that name and we should help them find the relevant article. I prefer A2 over A as when the name is not reported in secondary sources it seems unnecessary to include it; readers are very unlikely to be looking for it in such circumstances, but would support A over the other options. BilledMammal (talk) 01:57, 15 May 2023 (UTC)
• A / A2 If the deadname is mentioned in reliable secondary sources, readers who search for that deadname here on Wikipedia should be redirected to the relevant article, not to an empty page. Some1 (talk) 02:22, 15 May 2023 (UTC)
• C or (2nd choice) B; A would be bad: redirects can be helpful if someone might encounter the deadname in reliable sources in which the person's current name is not also mentioned, but (balancing this), as is already the case in general, redirects must not be used to violate policies or guidelines. You can't create a page titled "that [n-word] who became president" and argue it's fine because it's a redirect rather than a content page, you can't put someone's verifiable home address as a redirect and argue it's fine because it's a redirect and not a content page, and there's no reason to take away that general level of (for lack of a better word) protection, and give trans people less protection, like the first option seems to. It is also, as a practical matter, nonhelpful (indeed unhelpful) to redirect someone who searches for "John Doe" to an article on "Jane Roe", if that article has no mention of John Doe. AFAICT the main use of such a redirect seems to be ... providing a backdoor to take deadnames that are so non-notable and undue they aren't even mentioned in the person's article, and nonetheless wedge them into the encyclopedia. -sche (talk) 02:38, 15 May 2023 (UTC)

  providing a backdoor to take deadnames that are so non-notable and undue they aren't even mentioned in the person's article; per WP:RNEUTRAL, redirects don't need to be neutral, and in addition some of the options above, including the one you supported, would exclude mentions of names even when they are WP:DUE. BilledMammal (talk) 02:51, 15 May 2023 (UTC)

• Comment. If a deadname exists in the article, then a redirect may be created for it. If it doesn't exist for the article, then an {{R without mention}} isn't going to be helpful since readers won't know if they went to the right page or not. I don't know what option I should be casting a !vote for (maybe Option C or A2; oppose B?).
  Whatever the consensus is for the rest of the discussion, redirects should just follow the same standard for everything else. Deadname in article? Deadname for redirect is fine. No deadname in article? No deadname for redirect. –MJL ‐Talk‐^☖ 04:31, 15 May 2023 (UTC)
• First choice C, second choice B. --Jayron32 11:39, 15 May 2023 (UTC)
• B - I would prefer to avoid the usage of deadnames where possible, but for instances where a person's deadname becomes a notable part of the coverage about them in sources, that name becomes a plausible search term. In such scenarios, I think the readership at large would be best served by being redirected to an article under the subject's chosen name. Weak support for C and A2, which come close to striking this balance but (in my opinion) don't quite pull it off. Oppose A and D. ModernDayTrilobite (talk • contribs) 13:45, 15 May 2023 (UTC)
• Option C, with option B as second choice. Per Silver seren's argument, I find the supposed value of deadname redirects as search aids to be rather overblown. XOR'easter (talk) 13:50, 15 May 2023 (UTC)
• Option C As I said in the previous section, my main concern is that trans people are afraid to have Wikipedia articles about themselves because they think bigots will use them as a WP:COATRACK to publicize their deadname, and our policies should limit that behavior as much as possible. Since redirects are less visible, I'm not as worried about having them in cases where someone's deadname is widely publicized anyway, but the default should be "don't create them without a pretty good reason". TheCatalyst31 ^{Reaction•Creation} 15:58, 15 May 2023 (UTC)
• Option C per Tamzin and others. ser! ^{(chat to me - see my edits)} 19:36, 15 May 2023 (UTC)
• Option C: I find myself falling somewhere between B and C. I think this is a case where for the vast majority of articles that involve a deceased trans or non-binary person who transitioned prior to notability, a deadname redirect would be inappropriate. Leelah Alcorn and Brandon Teena would maybe be exceptions to that, though I do worry that option B's explicit "limited exception when relevant" carveout could be misused by bad faith editors to backdoor add non-notable deadnames. I'm also not entirely sold on the premise that reporting of the deadname by RS, and the target article discussing the deadname is strong enough justification on its own for including a deadname redirect. Killing of Brianna Ghey is an example of an article where her deadname was (briefly) reported by an RS, and the article discusses the deadname, but on balance I think that allowing a redirect would be incredibly disrespectful and distasteful far beyond the point of WP:GRATUITOUS. In the case of Ghey, you don't need to know the deadname to understand the large backlash against publishing it.
  While there may be other phrasing, similar to B but that's narrower on when to include the redirect, that I could support, I find that for now I prefer no explicit carve-out except as subject to IAR. Sideswipe9th (talk) 20:05, 15 May 2023 (UTC)
• Thanks for the ping. This is a tough and nitpicking call, and I probably couldn't decide it on my own, but will support Tamzin's position; they have clearly thought about this extensively. --GRuban (talk) 12:36, 16 May 2023 (UTC)
• Option C per Tamzin and others. Bastun^{Ėġáḍβáś₮ŭŃ!} 22:21, 18 May 2023 (UTC)

Discussion (GENDERID topic 2 redirects question)

Are we still talking about deceased people only? Barnards.tar.gz (talk) 14:13, 14 May 2023 (UTC)

Based on the proposals, I believe yes.--Jerome Frank Disciple 14:21, 14 May 2023 (UTC)

Tamzin / Jerome Frank Disciple : Since this was added after the other questions, perhaps the people who voted on the other questions should be pinged to it? It seems like it's got much less participation even after several days, and I assume some of that is people assuming they've already !voted in this series of RFCs. Loki (talk) 17:47, 14 May 2023 (UTC)

Not a terrible idea. I can say for myself though that I've been aware of this, I'm just carefully weighing up the options. Sideswipe9th (talk) 17:49, 14 May 2023 (UTC)

You're right! My fault for not having done that. I'm going to ping the users who commented on or cast !votes as to topic 2, since this proposal only pertains to a consequence of that topic, unless they've already commented here. I ... hope I got everyone. (And if I got you even though you already participated, I'm sorry!)

@Skyerise, Bilorv, DanielRigal, Thryduulf, Some1, RoxySaunders, Galobtter, Yasslaywikia, Cuñado, Blueboar, HTGS, Stwalkerster, BilledMammal, Hatman31, 3mi1y, Trovatore, Jayron32, Mitch Ames, ModernDayTrilobite, Springee, Voorts, Silver seren, Spy-cicle, MarijnFlorence, Stifle, MJL, Anomie, CoffeeCrumbs, SmallJarsWithGreenLabels, Chaotic Enby, Why? I Ask, Ser!, XOR'easter, Thesavagenorwegian, RAN1, Rutebega, GRuban, TheCatalyst31, Herostratus, Tekrmn, Locke Cole, Adumbrativus, Rab V, CandyScythe, and Sceptre:

Hello! There has been a new contingent proposal related to topic 2.--Jerome Frank Disciple 18:04, 14 May 2023 (UTC)

Thanks for the ping! Chaotic Enby (talk) 19:33, 14 May 2023 (UTC)

Topic 3: How often to mention deadnames? (MOS:GENDERID 3rd paragraph*)

After the first reference, how often should a Wikipedia article mention the former name (deadname) of a deceased trans or nonbinary person?

Note: If there is a consensus for option 2, above, these options would be placed below the option 2 text.

Option 1: Whenever the person's full name is mentioned (changes bolded in black)

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. Introduce the prior name with either "born" or "formerly". For example: From Chelsea Manning, notable under birth name: Chelsea Elizabeth Manning (born Bradley Edward Manning, December 17, 1987) ... From Elliot Page, notable under former professional name: Elliot Page (formerly Ellen Page; born February 21, 1987) ... When the former name (deadname) of a deceased trans or nonbinary person should be included, include the prior name with either "born" or "formerly", as above, any time the person's full (chosen) name is mentioned.

Option 2: To avoid confusion (changes bolded in black)

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. Introduce the prior name with either "born" or "formerly". For example: From Chelsea Manning, notable under birth name: Chelsea Elizabeth Manning (born Bradley Edward Manning, December 17, 1987) ... From Elliot Page, notable under former professional name: Elliot Page (formerly Ellen Page; born February 21, 1987) ... When the former name (deadname) of a deceased trans or nonbinary person should be included in an article, it should be included with either "born" or "formerly", as above, after the first reference to the person. Subsequently include the prior name only if doing so is necessary to avoid confusion.

Option 3: Once (changes bolded in black)

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. Introduce the prior name with either "born" or "formerly". For example: From Chelsea Manning, notable under birth name: Chelsea Elizabeth Manning (born Bradley Edward Manning, December 17, 1987) ... From Elliot Page, notable under former professional name: Elliot Page (formerly Ellen Page; born February 21, 1987) ... When the former name (deadname) of a deceased trans or nonbinary person should be included in an article, only include the prior name once—after the first reference to the person with either "born" or "formerly", as above.

Option 4: No change

User:Trystan has suggested that Option 3 might implicitly affect how editors interpret the guidelines as to living transgender and nonbinary persons, and desires that this proposal including living transgender persons also be considered:--Jerome Frank Disciple 13:36, 7 May 2023 (UTC)

User:Trystan's Option 3a: Once (changes bolded in black)

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. Introduce the prior name with either "born" or "formerly". For example: From Chelsea Manning, notable under birth name: Chelsea Elizabeth Manning (born Bradley Edward Manning, December 17, 1987) ... From Elliot Page, notable under former professional name: Elliot Page (formerly Ellen Page; born February 21, 1987) ... When the former name (deadname) of a trans or nonbinary person should be included in their main biographical article, only include the prior name once, after the first reference to the person. Outside the main biographical article, generally do not discuss in detail changes of a person's name or gender presentation unless pertinent. Where a person's gender may come as a surprise, explain it on first occurrence, without overemphasis. Avoid confusing constructions (Jane Doe fathered a child) by rewriting (e.g., Jane Doe became a parent). In articles on works or other activity by a living trans or non-binary person before transition, use their current name (or, if deceased, last-used name) as the primary name (in prose, tables, lists, infoboxes, etc.), unless they prefer their former name be used for past events. If they were notable under the name by which they were credited for the work or other activity, provide it in a parenthetical or footnote on first reference; add more parentheticals or footnotes only if needed to avoid confusion.

!votes (MOS:GENDERID topic 3)

• Option 3 (proposer). I could be persuaded by option 2, but, for now, I cannot think of a circumstance in which multiple references to a deadname would actually be necessary to avoid confusion. The best argument I've heard for needing to use a deadname multiple times has been in the abstract—references to a situation like Athletics at the 1976 Summer Olympics – Men's decathlon (which was won by Caitlyn Jenner prior to her transition). But, looking at that article, which does use Jenner's birth name twice, I have to wonder ... is the second reference really necessary to avoid confusion? Perhaps there's something to be said for having a clarification in both template and the article body, but I'm truly not sure.--Jerome Frank Disciple 19:50, 6 May 2023 (UTC)
• Option 3 (or perhaps 2): once is sufficient to avoid confusion, but I'd like that to allow for one footnote that is cited multiple times. For instance, imagine a list of sports records presented through tables where three records were set by the same individual before transition—the reader is unlikely to be reading from top to bottom and it makes sense to reference the name they won the record under each time. — Bilorv (talk) 20:17, 6 May 2023 (UTC)
• Option 3 Full disclosure, I assisted Jerome Frank Disciple with drafting these questions. Option 3 is the version that best fits with the other guidelines on how many times to mention a person's name in an article (MOS:SURNAME, MOS:GIVENNAME, MOS:SAMESURNAME). Outside of the exceptions to MOS:SURNAME, I've not seen in practice any good examples for why we need to mention a person's full name, regardless of whether they were cisgender, transgender, or non-binary, more than once in an article in a manner that's not already covered by other broader name use guidance. Sideswipe9th (talk) 20:23, 6 May 2023 (UTC)

  As it was added after my !vote, for the purposes of assisting with consensus determination I also support Option 3a with the same rationale as for option 3. I'm not sure though if I prefer one over the other as they both seem fine to me. Sideswipe9th (talk) 02:06, 12 May 2023 (UTC)

• Option 3 is going to be the correct approach the vast majority of the time. There might be some rare exceptions but I am very hesitant to support Option 2 as "necessary" is not defined and trolls would doubtless try to use that ambiguity to argue disruptively. I'm not sure how it could be worded to allow for genuine exceptions but preclude long arguments in other cases. If anybody can find a way then I'd support that but, of the two genuine options we have now, Option 3 seems best. DanielRigal (talk) 20:50, 6 May 2023 (UTC)
• Option 2 or 3: My one reason for liking Option 2 is that there are cases of historical trans people (such as the Public Universal Friend) where it's reasonably clear that they did not identify under their eventual name for the entire life. So in the PUF's case there is a real distinction between "the PUF" and "Jemima Wilkinson" that probably should be made. But this case is uncommon and I see the concern that "when necessary" may be too vague. Loki (talk) 21:11, 6 May 2023 (UTC)
• Option 2 We should mention former names as few times as possible to avoid confusion, but that might theoretically be more than once. Barnards.tar.gz (talk) 21:19, 6 May 2023 (UTC)
• (edit conflict) Mostly Option3 per DanielRigal and Bilorv, but I do agree with the latter's suggestion of allowing (but never requiring) a single footnote than can be referenced multiple times if strictly necessary - my first thought was where an article contains multiple tables of results, each of which might be referenced independently, but where only a single link to the person's article would normally be used. Thryduulf (talk) 21:22, 6 May 2023 (UTC)
• Option 3a. It should generally be mentioned only once, but I think the specific wording proposed in Option 3 creates confusion in the guideline. There is no need to distinguish between living and dead subjects on this point. The guideline doesn't currently say that it should only be used once for living subjects in their main biogrpahical article, and it should. There is detailed guidance on how to refer to living trans/nb subjects in other articles, and that should simply be extended to also cover dead subjects. Hence 3a, above.--Trystan (talk) 21:30, 6 May 2023 (UTC) edit: Second choice would be Option 4 - no change at this time.--Trystan (talk) 12:48, 8 May 2023 (UTC)

Discussion of option 3a

I see your logic, but, to be honest, I really hope people don't add too many more options to the RFC, particularly if it expands the scope of the RFC. (Imagine if we end up with an option 3c, or maybe also a 2b or 2c in the above two topics.) That's a quick way to kill any shot at a consensus.--Jerome Frank Disciple 21:52, 6 May 2023 (UTC) The guideline does say it only be used once for living people, specifically that it should only be used in the lead. So I agree with JFD that 3a is unnecessary. Loki (talk) 00:12, 7 May 2023 (UTC) It says to include it in the lead "only if they were notable under that name," which doesn't actually prohibit mentioning it multiple times elsewhere. (There is a more strained interpretation that it be included in the "lead only" if they were notable under that name, but that would create the larger problem of not prohibiting including non-notable BLP deadnames.) More to the point, the question is whether we want a different standard on this point for living and dead subjects, which Option 3 would create. In the case of the non-main-biographical article, Option 3 would result in markedly different wording applying to living and dead subjects, for no apparent reason.--Trystan (talk) 02:52, 7 May 2023 (UTC) I genuinely think if you want to change the policy for living trans and nonbinary persons, it shouldn't be in an RFC that's specifically devoted the policies for deceased trans and nonbinary persons. I'm moving 3a down here below your vote, as it's already causing confusion and wasn't in the original RFC.--Jerome Frank Disciple 10:54, 7 May 2023 (UTC) For articles other than the main biographical article, 3a simply extends the existing detailed guidance for living subjects to apply to deceased subjects. Why would we create a totally seperate standard for deceased subjects, rather than just doing that? For the main biographical article, Option 3 will have the unfortunate and unintended consequence of changing the guideline for living indivudals, which is what 3a is designed to avoid. Currenty, deadnames under which a BLP subject was notable are typically only included once, in the lead. The guideline doesn't actually say that, though this hasn't been problematic so far. However, if you add an explicit rule to only mention them once, and explicitly limit that rule to deceased individuals, it becomes reasonable to interpret the exclusiom of living individuals as intentional.--Trystan (talk) 13:24, 7 May 2023 (UTC) Given the discussion above, I'm re-adding your option to the top but with a note that it would expand the scope of the RFC to living persons.--Jerome Frank Disciple 13:35, 7 May 2023 (UTC) "Option 3 will have the unfortunate and unintended consequence of changing the guideline for living individuals"—I see your point about how there might be an implicit effect, but I still think the implicit argument is an expansion of scope. (I'm also a little dubious that, even if option 3 goes through, the actual effect will be that editors will treat deceased subjects more restrictively?--Jerome Frank Disciple 13:39, 7 May 2023 (UTC)

• Option 3a (or perhaps 3). I'm confused by the distinction between 3 and 3a, because, as far as I can tell, Option 3 seems to arbitrarily limit the guideline to only apply to deceased persons; any guideline here should either apply to all persons equally or be more strict for living persons. Regardless, I'm pretty convinced by User:Sideswipe9th's argument above. For an example, let's take the current revision of Rishi Sunak's article. Conducting a Ctrl+F find on the page, we discover that in the article prose (not including hatnotes, infoboxes, reference names, etc.) the name 'Rishi' appears only thrice: once as the very first word of the article, and twice in quotations (which are already addressed by MOS:GENDERID). In this case, it seems as if we are simply extending what is already a common naming practice to explicitly include deadnames. Shells-shells (talk) 03:37, 7 May 2023 (UTC)

  Option 3a was added by a !voter after the launch of the RFC to cover both living and deceased persons. The only reason it wasn't included Because this RFC was specifically devoted to the deadnames of deceased trans persons.--Jerome Frank Disciple 10:53, 7 May 2023 (UTC)

• Option 2 or 4 (in that order). I fail to see how restriction to a single mention is necessary or helpful. Try to apply the more restrictive standards to someone like Gloria Hemingway or the Public Universal Friend and see how far you get. This is the very sort of question that is difficult—but very tempting—to answer from our present ideological ivory tower, but is better answered by those casuists who actually write the biographies. — HTGS (talk) 05:34, 7 May 2023 (UTC)
  • Gloria Hemingway was an interesting read, thanks. I think that's a good example of an article that really suffers from being forced into one gender, since the person involved seems to have struggled with gender identity their entire life and seems to have used both male and female presentations both before and after surgery. The article seems to do its best to minimize that, leading to reader confusion. Anomie⚔ 12:31, 7 May 2023 (UTC)
• None of the above - when, where and how often to mention a deadname (in those situations where it should be mentioned at all) depends on the specific subject, and can only be determined on an article by article basis. Each individual is unique and has unique factors to consider. Blueboar (talk) 12:04, 7 May 2023 (UTC)
• None of the above (basically Option 4) Agreed with Blueboar. This should be determined on an article-by-article basis. The MOS shouldn't dictate show often a name should or should not be mentioned because not all articles are the same. Some1 (talk) 13:17, 7 May 2023 (UTC) Some1 (talk) 15:41, 7 May 2023 (UTC)
• None of the above, per Blueboar. BilledMammal (talk) 13:19, 7 May 2023 (UTC)

  I suspect that the "None of the above" !votes should be "4. No change". Because if they don't want Option 4 (or 1,2,3), what do they want? (Feel free to delete this comment if all of the above change their stated preference.) Mitch Ames (talk) 13:47, 7 May 2023 (UTC)

  Concur. Perhaps there's a small distinction—i.e. "No change" implies an endorsement of the status quo, while perhaps these editors want to reserve the right to pick entirely different guidelines, but at least some of them are explicitly saying "this shouldn't be addressed by the MOS" ... and, currently, it isn't!--Jerome Frank Disciple 15:35, 7 May 2023 (UTC)

  To explain my “none of the above”vote… my preference would be to use the deadname only in historical context (for example in an “early life” section), but otherwise use the current name. That said, there will be exceptions in both directions. The flaw with all the questions and options is that they attempt to impose a “one-size-fits-all” rule on a VERY complex and sensitive thing that simply does not lend itself to sweeping rules. It HAS to be determined on a case by case basis. Respect for the wishes of the subject needs to be balanced with encyclopedic value. Where and how to find that ballance is going to be article specific. Blueboar (talk) 14:56, 8 May 2023 (UTC)

• Option 3 if, and only if, it is to be included, it should only be in their main article and only the once, for completeness. --Jayron32 14:20, 8 May 2023 (UTC)
• Support Option 2 or Option 4, Oppose Option 3 - I would think that at least two mentions are needed, once in the lead and at least once in the body, perhaps one more in an infobox. Avoid confusion. My views also overlap with HGTS and Blueboar. starship.paint (exalt) 14:31, 8 May 2023 (UTC)
• Option 4, no change - All of the proposed changes add unnecessary limitations, complexity and scope creep. Existing policies, and editorial discretion on a case-by-base basis, are sufficient. Mitch Ames (talk) 14:40, 8 May 2023 (UTC)
• Prefer Option 2; Options 3 and 4 also acceptable. I believe we should strive to mention deadnames as little as is feasible; however, "as little as is feasible" may occasionally be more than once (see, for instance, the example raised above of the Public Universal Friend). In practice, I expect that Option 2 and Option 3 will lead to the same results in a large majority of situations; in the remaining situations, I believe that Option 2 is the language that will result in the least confusion for readers and editors alike. ModernDayTrilobite (talk • contribs) 16:37, 8 May 2023 (UTC)
• Option 4 with Option 2 as a best practice As with my other replies, my concern is being overly prescriptive in handling this. Option 2 is likely the best solution in most cases as it puts both names up front and allows for both uses to avoid confusion. Is this any different than what is already allowed? What does Option 4 allow that Option 2 (and typical editorial oversight) wouldn't allow? Springee (talk) 16:56, 8 May 2023 (UTC)
• Option 3a There should be no distinction between living and dead persons, and mentioning a notable deadname only once best comports with the spirit of MOS:GENDERID. voorts (talk/contributions) 21:42, 8 May 2023 (UTC)
• Option 3a I never understood the need to use the name more than once in the cases where the name does need to be mentioned. Mention it once and don't use it again, similar to birth or maiden names. Why would you even need to use it more frequently than the one time? And, as I said in move vote above, living should have never been included in this policy in the first place. Dying doesn't change the purpose of this MOS usage. Silverseren^C 22:07, 8 May 2023 (UTC)
• Option 1 or 2 Since option 3, goes against the principle of MOS:LEAD.  Spy-cicle💥  ^Talk? 02:43, 9 May 2023 (UTC)
• Option 4. No need to be overly prescriptive here. Sometimes one option will make more sense than others. In most cases it will be irrelevant as the dead name will be a first name, and people are by MOS generally named only as surname within article text. Stifle (talk) 14:00, 9 May 2023 (UTC)
• Option 2 is the one that I feel strikes the best balance between compassion for the subject and our basic, primary role as an encyclopedia. CoffeeCrumbs (talk) 04:26, 10 May 2023 (UTC)
• Option 3a Follows MOS:GENDERID the best, doesn't make unnecessary distinctions, and no point in repeating the deadname in the whole article. Chaotic Enby (talk) 15:02, 10 May 2023 (UTC)
• Option 4, to avoid being overly prescriptive. This will vary on a case-by-case basis, but if a general guideline must exist, then only mention the deadname if both of the following conditions are true:
  • Including the deadname would help the reader, such as to alleviate confusion over discrepancies between an article and its sources, particularly when such sources pre-date the transition.
  • The particular instance is either:
    • the sort of thing you would add a link to if on another article (note that repeated links to the same article are generally discouraged), or
    • a listing of a given person's full name, in which former names are expected to appear for non-transgender name changes.

I also oppose revdel'ing violations of this guideline/policy. -BRAINULATOR9 (TALK) 03:08, 11 May 2023 (UTC)

• None of the above (basically Option 4) per Blueboar. Not all articles are the same. --GRuban (talk) 17:49, 11 May 2023 (UTC)
• Option 3a Tekrmn (talk) 21:51, 11 May 2023 (UTC)
• None of the above per Blueboar, et al. m:instruction creep is over there. WP:RGW. —Locke Cole • t • c 04:52, 12 May 2023 (UTC)
• Option 4. Other options prescribe a rule too categorically, as editors have argued above. "Necessary to avoid confusion" is one possible reason, but I would not easily declare any one reason or set of reasons to be the only possible one. Ordinary editorial discretion can include any number of considerations – helpfulness to readers, contextual relevance, types of content (lists, tables, quotes, citations, infoboxes, image captions, etc.), degree of coverage in sources, and so on – case-by-case. Adumbrativus (talk) 09:16, 12 May 2023 (UTC)
• Option 1 makes the most sense to me as the most neutral approach to this. Considering that MOS:SURNAME dictates that we principally refer to the subject by their surname, this shouldn't be problematic for most articles as I don't see how further mention of either the subject's former or current name would be beneficial. Yasslaywikia (talk) 20:39, 12 May 2023 (UTC)
• Option 4 Generally, my position on this has already been covered by many of the option 4 votes; Blueboar and Springee's are of particular note. Skarmory (talk • contribs) 10:36, 13 May 2023 (UTC)
• Option 3/3a – We should be using deadnames only when editorially justified, and I don't think we need to do so more than once in nearly any circumstances. Sceptre (talk) 16:27, 13 May 2023 (UTC)
• Option 2 It just doesn't make sense to have a rule on the number of times it can be stated, per WP:DUE. —Lights and freedom (talk ~ contribs) 22:24, 13 May 2023 (UTC)
• Option 4 or 2 - ultimately our articles need to be clear. Option 1 would be oddly gratutiously awkward even if there were zero alternate interests in play. Option 3 (or 3a) are unwise and will reduce clarity in articles. Nosebagbear (talk) 01:07, 14 May 2023 (UTC)
• Option 2 -Ad Orientem (talk) 23:20, 14 May 2023 (UTC)
• 3a or 3 (or failing that, 4), per Sideswipe9th.
  Option 2 is not a workable/functional guideline, since in previous discussions, some people have argued a person's deadname and/or birth sex has to be spelled out when discussing any and every thing the person did pre-transition to (ostensibly) prevent "confusion"; off the top of my head, I've been involved in a discussion on WT:V where someone argued it was not merely confusing but violated WP:V to use a source saying "John Smith studied XYZ" (or did anything else!) and a source clarifying than John Smith transitioned and is now Jane Smith to say Jane Smith studied XYZ; elsewhere people have argued it's confusing to mention a prior relationships; etc, etc; so option 2 is just a recipe for more repetitive discussions (based on general stances rather than article-specific factors) on more articles. -sche (talk) 02:12, 15 May 2023 (UTC)
• Option 3 as I can't conceive of a natural example where we would need to use the deadname more than once. Bastun^{Ėġáḍβáś₮ŭŃ!} 22:23, 18 May 2023 (UTC)

Discussion (MOS:GENDERID topic 3)

• Thank you for re-adding 3a. I don't agree with the characterization of it expanding the scope of the RFC to living persons. Outside the main biographical article, it takes the existing guidance and makes it also apply to deceased subjects. Clearly no change for living individuals there. For the main biographical article, it would make explicit the existing practice for living persons, and make that apply to all articles. Option 3 is, in my opinion, the one with policy implications for living persons, by creating an explicit rule that specifically excludes them, when that exclusion would be contrary to current practice.--Trystan (talk) 13:56, 7 May 2023 (UTC)

  I apologize I'm late on getting my coffee today, so I'm scattered. I almost thought I was picking up what you were putting down ... but then I lost it. When the former name (deadname) of a trans or nonbinary person should be included in their main biographical article, only include the prior name once, after the first reference to the person. ... You're saying that wouldn't be new guidance that would apply to living persons?--Jerome Frank Disciple 14:15, 7 May 2023 (UTC)

  It does apply to living persons, in order to preserve the current practice and interpretation of the guideline. By flagging my option as outside the scope of the RFC, it implies that the originally proposed options don't have unintended consequences for how the guideline as a whole will be interpreted with respect to living persons, which is very much a matter for debate. I would prefer it if my option were simply introduced without commentary, for editors to neutrally evaluate alongside the others.--Trystan (talk) 15:06, 7 May 2023 (UTC)

  I reworded the intro to reflect what you just said, but I do think it should be noted that the proposal would, by its explicit terms, dictate the treatment of living persons, even though this RFC (by its questions, section title, and every other indicator) only claimed to be addressing how to cover deceased persons. "But the current proposal might have implicit affects" may or may not be true (I'm personally quite skeptical, because I can't really imagine a world in which the deadnames of living transgender persons are treated with less care than those of deceased transgender persons). But, regardless of its truth, it's still an admission that the proposal only explicitly concerns itself with deceased transgender persons, as the RFC title and questions indicate. (But hopefully the revised intro is an acceptable compromise?)--Jerome Frank Disciple 15:30, 7 May 2023 (UTC)

  Looks good, thanks.--Trystan (talk) 15:42, 7 May 2023 (UTC)

• @Spy-cicle:—Could you elaborate on the MOS:LEAD point? I'm not sure I understand. Per MOS:SURNAME, we usually only give a biography subject's full name once—in the lead. ... How would this be different?--Jerome Frank Disciple 13:17, 9 May 2023 (UTC)
• As Trystan correctly points out, option 3 is problematic because it seems to set a higher standard for deceased subjects than living people. But option 3a contradicts paragraph 5: Paraphrase, elide, or use square brackets to replace portions of quotations to avoid deadnaming or misgendering, except in rare cases where exact wording cannot be avoided, as where there is a pun on the notable former name, etc. The existing guideline seems to be more in line with option 2, allowing the deadname to be used only where unavoidable, but applying that restriction only to living subjects. I hate to introduce even more complexity into the debate, especially at this stage, but I'd argue either form of option 3 logically requires a more comprehensive rewrite of the entire section. I also think there should be an option, analogous to option 3 from topic 2, where the "living" stipulation in ¶3 is simply removed. The added paragraph in option 2 is fine but it's largely redundant if the rest of the section is understood to apply to both living and deceased subjects. —Rutebega (talk) 17:58, 11 May 2023 (UTC)

Would like to understand how Criteria_for_speedy_deletion#G8 applies to Templates?

Hi I am an editor from Chinese Wiki and my major interest is to move the templates from English Wiki to Chinese Wiki, so the people can build pages with minimal effort.

Currently I face one problem while moving templates. In English wiki there are some templates looks like a subpage (e.g. Template:NYCS_Platform_Layout_BMT_Brighton_Line/embankment and there is no main page for this template (Template:NYCS_Platform_Layout_BMT_Brighton_Line in this example). While I move the template from English wiki to Chinese wiki the bot triggered a speedy deletion alarm and the subpage template was deleted zh:Template:NYCS_Platform_Layout_BMT_Brighton_Line/embankment due to the speedy deletion rule. While chatting with other editors they said the Speedy deletion rule was inherited from G8:Subpages with no parent pagerule.

So I would like to understand how English wiki interpret the speedy deletion policy and how speedy deletion wouldn't apply to Template:NYCS_Platform_Layout_BMT_Brighton_Line/embankment? Thank you very much Winston (talk) 00:13, 7 May 2023 (UTC)

My understanding is that the "Subpages with no parent page" provision in WP:G8 can apply to templates, e.g. to delete components, docs, testcases alongside the main template. One example is Template:CBB Seasons Cat Header/Name conv. But the whole WP:G8 "excludes any page that is useful to Wikipedia", so it should not be used to delete helpful templates that can work on their own and not actually a subpage in the sense of being a component of a non-existent parent template, even if they are (perhaps inappropriately) titled as a subpage formally. ——HTinC23 (talk) 02:05, 7 May 2023 (UTC)

G8 is almost always invoked in template space only when the parent template is deleted at WP:TFD. A G8 otherwise would be quite suspect.

That said, our rules don't decide how zh works. OP should discuss there about how and why actions should be taken. IznoPublic (talk) 01:38, 8 May 2023 (UTC)

@Izno I totally agree that the en rules doesn't decide how zh works. And thanks for your comment.

I am looking at WP:TFD#REASONS and it seems that the subpage rules doesn't apply to templates, from the general application point of view. Winston (talk) 02:45, 8 May 2023 (UTC)

Petition to remove appealing to Jimbo from the Arbitration Policy

Hi all, please see this petition to amend the arbitration policy to remove Jimbo Wales's ability to overturn ArbCom decisions, which needs a 100 signatures as per the formal amendment process. Galobtter (talk) 18:18, 9 May 2023 (UTC)

Thanks! Signed it! Chaotic Enby (talk) 22:04, 14 May 2023 (UTC)

Status of Snow Closes

A contentious Deletion Review was just closed. Well, it was really a contentious one-against-many Deletion Review. One form of the question for the community is whether the Snow clause is a valid basis for an early close of an AFD. The Snow clause is an essay, not a guideline. The most recent effort to raise it to the status of a guideline was not successful. The DRV in question was Wikipedia:Deletion_review/Log/2023_April_29, concerning Wikipedia:Articles for deletion/Christopher W. Shaw.

The appellant and at least one other editor disagreed with early or snow closes in general. However, the large majority of participating editors endorsed the closure, and the DRV was closed as endorsing the closure.

So my first question is whether the community wants to change the status of snow closures, either to deprecate them, or to formalize them as a guideline. My second question is, if it is desired to continue to recognize early or snow closes, why is the provision for them kept at the status of only an essay? Robert McClenon (talk) 02:11, 10 May 2023 (UTC)

WP:SNOW is an invocation of WP:IAR for when there's a snowball's chance in hell of a certain proposal passing. For example, if I were to nominate Earth for deletion, that has a snowball's chance in hell and there's no need to go through the full process. If there is any reasonable disagreement whatsoever, WP:SNOW should not be invoked. When reasonable people disagree and one group wins out, we just call that WP:CONSENSUS, and we have processes for determining consensus. Thebiguglyalien (talk) 04:45, 10 May 2023 (UTC)

A case I recall was Wikipedia:Articles for deletion/Peter Blake (artist). At the time, and now, I didn't think it did Wikipedia's credibility any good for that article to be carrying an AfD template for a week and was relieved when it was snow-closed after 2 days. In cases such as these, I would like to think a nominator would be actively considering others' comments, would "read the room" and withdraw their nomination, but where that level of engagement is absent, I see snow-closure (whether by an admin or not) as a sustainable fallback, so would oppose deprecation. I am inclined to think its current status as an unusual but understandable outcome is about right. AllyD (talk) 05:53, 10 May 2023 (UTC)

It seems clear from the discussion around your recent proposal and the February RfC that there is no appetite in the community to either deprecate them or to promote them as a guideline. The reasons that people support keeping WP:SNOW as an explanatory essay seem to be fairly clear from those discussions – primarily that the status quo works perfectly fine. Why are you bringing this up again only a week after your last proposal to upgrade the essay was closed? Caeciliusinhorto-public (talk) 11:17, 10 May 2023 (UTC)

Per Caecilius, the community (at least the part of it sitting behind this keyboard and typing) understands that explanatory essays are useful as is even if they aren't policy or guidelines. An explanatory essay is a time-saving measure for frequently used explanations. That doesn't make them policy or guidelines, which serve different purposes. Citing WP:SNOW doesn't mean "Wikipedia has a policy we expect you to follow, and here it is", citing WP:SNOW means "Look, it's too much to type this frequently-used explanation out over and over again. Just read this if you want to understand why I am doing what I am doing". Like Caecilius, I am perplexed why you continuously ignore this easy-to-understand idea. --Jayron32 13:17, 11 May 2023 (UTC)

Literally what's been said above, essays can be used as shorthand links to what can be more complex methods. Wikipedia:Don't template the regulars is an essay, but we shouldn't HAVE to make this a policy for people to understand it's meaning when someone removes a series of ill fitting templates from their userpage. WP:STICK is an essay. We don't need to be typing out a long winded explaination as to why people shouldn't continuously state the same information over and over to get the same result. Things being essays are just fine. Please can we snow close this? :P Lee Vilenski ^{(talk • contribs)} 14:34, 11 May 2023 (UTC)

Unlike everyone else (apparently), I do think we should elevate WP:SNOW to a guideline if we're going to be closing major discussions based on it. There are some really big-deal essays out there, but there aren't many that are as procedurally important as WP:SNOW. Loki (talk) 14:41, 11 May 2023 (UTC)

SNOW explains a type of WP:IAR, using "per WP:SNOW" is a way of avoiding typing "I am invoking WP:IAR in this case because there's no way this discussion needs to be left open anymore; everyone should be well aware of how it is going to be closed, so leaving it open any more is just silly at this point". It shouldn't be elevated to policy or guideline because it is not a type of policy or guideline, it is a common explanation. Policies are not explanations. Guidelines are not explanations. A good, well-used explanation doesn't magically become a WP:PAG merely because it is well-used. Policies, guidelines, and explanations aren't in a hierarchy, all three serve different purposes, and you don't make one into another by simply declaring it so. WP:SNOW is fine as an explanation because that's its purpose. It is not supposed to guide, it is supposed to explain. --Jayron32 15:55, 11 May 2023 (UTC)

• My general take on SNOW closures of AfDs is that they should be used with caution. Wikipedia:Articles for deletion/Christopher W. Shaw was a good example of what can go wrong. It's not that there was any doubt about the outcome, but that the risk:reward ratio wasn't convincing. The reward was that we saved 8 hours, but there wasn't any cost to waiting, so there wasn't actually any potential reward at all. The risk was that somebody might object to process not being followed correctly. That's exactly what happened, and it cost us another full week of acrimonious debate. There's a place for SNOW closes, but I'd be looking for a much stronger consensus. I don't do a lot of AfD work these days, but when I was an active closer, I would be looking for unanimous (except for the nom) consensus with 10 or maybe 12 opinions. I would have never SNOW closed that AfD. At the same time, Jay was indulging in pointless wiki-lawyering by opening the DRV. We need some kind of double-headed trout award on this one. -- RoySmith (talk) 14:59, 11 May 2023 (UTC)

  I'm here because of the ping. I think I was right in opening the DRV, and actually did that with the expectation that the AfD close be reverted. I also said that Unless DRV is about outcome all the time, in which case I'm open to be educated, and not visit DRV again except for change of outcome.. There are unanswered questions, including why was the AfD closed 8 hours early. I respect the DRV close, so if this is an attempt to "review" what happened at the DRV, I won't be analyzing anyone's votes or comments. You may have your opinion about the DRV, and trouting is your prerogative! Jay 💬 15:18, 11 May 2023 (UTC)

  Nothing would have gone wrong in that case, except for one person who insists on playing the rules game. You shouldn't hold up that absolute farce of an example of "what can go wrong". We don't write or amend policy to deal with singular examples of silliness like that. People sometimes do unpredictably silly things. I've only been an active editor at Wikipedia since 2006, so maybe I'm still too new around here to know if this is a widespread problem, but I've never seen anything like that before. --Jayron32 15:32, 11 May 2023 (UTC)

In my opinion, SNOW is properly tagged as what it is: a supplement to IAR. casualdejekyll 22:03, 11 May 2023 (UTC)

I think that snow decisions are an example of the not-explicitly-acknowledged method of how Wikipedia operates Which involves weighing multiple considerations. In this case they include:

• How overwhelming is the sentiment expressed?
• How controversial/non controversial is the topic?
• How high or low of an impact is the topic on Wikipedia as a whole?
• Has it been open long enough to get what is likely to be a representative sampling (including taking number of eyes/visibility into consideration)?
• Have any sincere objections to the early close process been expressed?

Unless any guidelines acknowledged this, I think it would do more harm than good. Sincerely, North8000 (talk) 15:34, 11 May 2023 (UTC)

Wikipedia is not a bureaucracy. "Although some rules may be enforced, the written rules themselves do not set accepted practice. Rather, they document already-existing community consensus..." Wikipedia:Snowball clause is a prime example of documenting community practice. It is not intended to be written down as a rule (or five hundred legalists will show up asking for exact numbers on when it can and can't be used), but rather as an explanation: "just why was this discussion closed early"? Others like this include Wikipedia:Deny recognition, Wikipedia:Competence is required; all powerful, and often cited, but not rules in the sense of "what we should do", rather explanations of "why did we just do that?" --GRuban (talk) 21:29, 11 May 2023 (UTC)

I feel that if anything is supposed to be closed (or someone even blocked, ban, IP block/ban,RfCs) all of that the exact policy needs to be stated as the reason for closure and not some essay. The essay can be used in an explanation for using the policy and the closure and keep/delete. I also agree that if one person goes against the norm as stated above you have 45 keeps and 3 deletes it should not be closed using WP:SNOW and should be ran it’s normal 7 days instead of rushing things. No essay should ever be used as a criteria for an admins actions. I remember a few years ago I think someone wrote an essay and it became a quoted reason for blocking named users/ips without an RfC for making it a policy. It appears when I look through various essays and other items of interest there is a lot of overlap between them all. Like they were cherry picked to form a policy that encompasses various authors ""views"" that do not reflect the consensus of or viewpoints of others. I also notice a lot of people who vote on these things are almost always admins. We should have a policy that there has to be a certain amount of editors (below admin level) have to also participate and vote or it fails. So if it is 65-30 then 65 of the votes has to be 32 regular editors or as close to 50/50 as possible to ensure it’s a consensus and not an admin group setting up the RfC to pass because they want it to. Just my 3¢ worth. — Preceding unsigned comment added by 2600:8801:CA05:EF00:4405:B060:E0C7:DB35 (talk) 07:15, 19 May 2023 (UTC)

Forgive former vandals

I was wondering if, say User:Example vandalizes Example, but then, after being warned, becomes a constructive contributor. Do we just...forgive and forget? If so (or not so), there should be policy that supports it. Just want to get consensus. Sincerely, --AugustusAudax (talk|contribs) P.S: Aliens exist 12:15, 10 May 2023 (UTC)

well if they are constructive after one warning, that is great. As long as they are not blocked permanently they can attempt to do good with their edits. No one has to forget or forgive though. But WP:AGF means we give them a chance if they look good. Graeme Bartlett (talk) 12:24, 10 May 2023 (UTC)

I'm not sure what there is to forgive though. Wikipedia doesn't maintain a formal set of demerit points or any other way to quantify bad behavior. Memory of bad behavior tends to fade over time based on the severity of the offense and the time since the last offense, but that's just general human nature. Since Wikipedia has no formal means of tracking such things, there's nothing to "forgive". Either you are being useful, or you aren't. That's really all Wikipedia as a system cares about. --Jayron32 13:12, 11 May 2023 (UTC)

Unless you are blocked (or banned), every user is free to contribute constructively. If you have a history of vandalism, it might take a lot longer for your record to be seen as cleaner (say if you were to ask for advanced perms, say), but you aren't blackballed for it. If you are blocked, such a "forgive and forget" mentality can be seen with WP:FRESHSTART. It's difficult to have a policy around this, as users will have different standards of history if a user was to say, run at RfA. Some users might ignore things happening over two years ago, some might not care about minor stuff, and some might really care about that time in 2007 you accidentally mistyped "shift" into an article on a BLP. To each their own. Lee Vilenski ^{(talk • contribs)} 14:40, 11 May 2023 (UTC)

Forgive and forget is a good idea in general; some former vandals have actually become sysops. Of course we can't compel people to forget, but from a procedural standpoint everyone is welcome to contribute as long as they remain in good standing. 74.73.224.126 (talk) 01:31, 12 May 2023 (UTC)

Also probably depends on how long it's been. A lot of vandals are teenagers and grow out of it. Gnomingstuff (talk) 02:00, 12 May 2023 (UTC)

I have wondered at various points whether vandalism might even be a point-of-entry for some users. “Anyone can edit” etc.

I feel no need to enshrine anything into policy though. We have, as a community, many guidelines (and policies?) that can collectively be read as saying, “hey, if you’re doing good work I won’t chase you for old crimes.” — HTGS&.nbsp;(talk) 04:44, 12 May 2023 (UTC)

@HTGS: Such as what? Sincerely, --AugustusAudax (talk|contribs) P.S: Aliens exist 11:16, 12 May 2023 (UTC)

IP vandalism is usually one-off unless it is a shared account (a school, usually) so probably impossible to say. Gnomingstuff (talk) 15:44, 12 May 2023 (UTC)

@HTGS and Gnomingstuff: Well, here's one data point. A number of my earliest edits (although not the very first) were vandalism, and I do think those experiences contributed to me becoming a productive editor. There was something cool about being able to just change the site like that and, when not trying to come up with silly jokes with my friends, that turned into a desire to make the wiki better. -- Tamzin^{[cetacean needed]} (she|they|xe) 08:15, 19 May 2023 (UTC)

Wikipedia guidelines and In the news

There is currently no policy or guideline that oversees WP:In the news or its selection process in what is posted to the main page. As a result, ITN has diverged from sitewide consensus, and its processes are determined by a small group of regular editors enforcing a standard of "significance" or "ITN-worthiness" that has no basis in Wikipedia policy or guidelines. Discussions at ITN make virtually no reference to policy or any sort of sitewide standard, amounting to little more than WP:ILIKEIT and WP:IDONTLIKEIT arguments, and discussion closures are little more than a headcount. If anything, these discussions actively circumvent policies and guidelines relating to WP:CONSENSUS, WP:NOTABILITY, and WP:OR. There's a good write up at WP:HOWITNWORKS that goes into this in more detail.

Sitewide consensus has already indicated opposition to the current process of ITN for these reasons, most recently in February at Wikipedia:Village pump (idea lab)/Archive 47#In the news criteria. Some editors, including myself, have attempted to explain this at ITN and pushed for an approach more aligned with policy. Despite this, a local consensus continues to be enforced at the expense of sitewide consensus.

A great example of the issue here is at the recent discussion on whether to post the coronation of Charles III and Camilla. Despite clear consensus that it was a notable event with extensive news coverage and a quality article, ITN regulars broadly voted against posting it to the main page because it didn't meet some arbitrary standard or because they had their own personal gripes about the event itself, rather than any challenge to the subject's notability or the article's quality. It was only posted at all because several editors who don't normally participate in the ITN process came to see why it hadn't yet been posted and !voted to support posting.

WP:ITNSIGNIF gives a vague description of how submissions should be evaluated, but to my understanding it is essentially a WP:PROJPAGE. It has never undergone the sitewide scrutiny that's expected of pages like this, and it likely wouldn't pass such scrutiny given how unhelpful it is and how much it encourages original research. WP:CONLEVEL is clear on this point: sitewide consensus—especially in the form of policies and guidelines—outweighs any decisions made in a specific area by a small group of regulars. There is no exemption for ITN or any of the other main page focus areas. If anything, these areas should be receiving the highest level of sitewide scrutiny. I believe that there either needs to be a modification of current guidelines to take this situation into account, or a new guideline is needed specifically for ITN or for the main page in general. Thebiguglyalien (talk) 17:46, 11 May 2023 (UTC) Update: ITN is currently in a heated argument about a duck. Thebiguglyalien (talk) 02:00, 12 May 2023 (UTC)

Honestly ITN is useless and should be replaced with something else. As it currently exists, it just serves as a great way to start arguments and get people blocked. Also... are you saying that ITN was brigaded...? The coronation should not have been posted. --Rockstone^{Send me a message!} 07:25, 13 May 2023 (UTC)

@Thebiguglyalien: This is a very confusing statement to read - it raises valid concerns about the overall lack of broadly-backed guidance for ITN, but also accuses of issues by participants. Those issues (if true) are a mix of things that are valid unless and until there is a broad-based set of rules rather than a locally written set - and others that might not be. Additionally, this is sitting at VPP, but it's not actually proposing specific changes but raising a general issue. VPI would probably be a more logical forum. tl;dr - break up what are the issues and what we should consider as solutions. If solutions need to be workshopped first, perhaps try VPI. Nosebagbear (talk) 01:14, 14 May 2023 (UTC)

Nosebagbear: It was already raised at VPI with Wikipedia:Village pump (idea lab)/Archive 47#In the news criteria, as I linked above. It hit a wall in part because there was no policy or guideline to fall back on. Thebiguglyalien (talk) 02:22, 14 May 2023 (UTC)

My apologies @Thebiguglyalien for missing the previous VPI thread - clearly I shouldn't edit at 2 in the morning, local. Having read it, however, it's slightly odd - in some ways it actually had clearer proposals. I do feel that I should highlight that Notability, OR, and such (but not wp:consensus) apply only to articles - ITN wanting to make their decisions on another basis is not, inherently, policy-violating. ITN currently have an extremely lightweight framework that does mean that there is little difference between votes and !votes.

I would suggest that the following questions need to be answered:

1. Is the current status quo sufficiently broken that a more formalised set-up is needed?
2. What will the "in the news" aspect require as a minimum - prevalence of on-going coverage
3. Of those literally in the news, what level of quality needs to be reached to not be excluded on an article quality basis?
4. Of articles that meet these two minimums, how are they then picked: the most covered by news? The best articles? Some balance?

Nosebagbear (talk) 10:57, 14 May 2023 (UTC)

The guidelines as written already address these matters. In operation, what happens is that discussions are hijacked by a small group of vocal people who believe they know best on what is significant solely on their assertions that something is or is not significant. There's not much to be done about this that policy can fix; writing more policy does not correct the problem of people ignoring written policy. --Jayron32 13:06, 15 May 2023 (UTC)

The point of my post here is that there aren't policies or guidelines for ITN as they're defined on Wikipedia. If we did have such a guideline, then it could be improved and enforced by the community. Right now, ITN operates as its own bubble with minimal community oversight. Thebiguglyalien (talk) 18:48, 15 May 2023 (UTC)

WP:ITN contains extensive written guidance on both quality and significance. I suggest you read it before claiming it doesn't exist. It's been there for at least a decade before you insisted that it wasn't. --Jayron32 11:15, 16 May 2023 (UTC)

I'm well aware of that non-guideline. A good portion of the above post is about why it's insufficient. To summarize: how it's applied was determined by a walled garden without sitewide scrutiny, it's not enforceable by the broader community, it's vague and arbitrary, and it pushes against the letter and spirit of policies such as WP:CONSENSUS and WP:OR. Time and time again, the community has shot down the idea that individual corners of Wikipedia can create their own governing structure independent of sitewide procedures. I don't see why this is any different. Thebiguglyalien (talk) 14:22, 16 May 2023 (UTC)

I have no experience in editing ITN, nor do I, as a reader, make great use of it, because I rarely if ever hit the main page. Therefore please treat this observation as potentially naive: it seems to me like the main page is only barely a real article, which makes the usual content policies not terribly helpful. But the conduct policies are still relevant, and this sounds like there might be a little too much WP:OWNERSHIP going on. Barnards.tar.gz (talk) 13:50, 15 May 2023 (UTC)

A "here's news stories that a small group of editors decided to emphasize" section should probably not be at the top of the most prominent Wikipedia and Wikimedia page. Nowadays a likely stronger standard of just follow what the media head count does would also be bad. A standard of "how impactful is it?" would make it an excellent section for Wikipedia but that probably isn't going to happen. Best to eliminate it. North8000 (talk) 13:31, 15 May 2023 (UTC)

That's now what ITN is. Your characterization isn't helpful. What ITN is supposed to be is "Here's a link to quality Wikipedia articles about current events". That sometimes votes don't go the way you want them to is not a reason to take the entire thing down. That's a bit of a petulant attitude. Could Wikipedia do a better job of actually meeting the purpose as laid out at WP:ITN? Absolutely it could. Wikipedia could be better at doing everything, everywhere, all the time. That's not a reason to shut down the whole encyclopedia, though. It's a reason to be better. --Jayron32 14:05, 15 May 2023 (UTC)

Thebiguglyalien, I think you need to keep in mind just how much the English Wikipedia has changed. The main ITN page was created in 2004. We have editors who weren't even born back then. We have admins who hadn't even been born back then. I wrote WP:PROPOSAL in 2008. Consequently, it's basically impossible for the page to have followed directions that didn't exist. That doesn't mean that ITN's page hasn't been checked out by others, or that it's inherently flawed or otherwise urgently needs some bureaucratic processes thrown at it. Back when ITN was created, pages were still getting designated as guidelines (or whatever) through the expedient of someone slapping a tag on the page and waiting to see whether it would be reverted. Having a label, or not having a label, isn't the most important thing. There's no tag on Wikipedia:Articles for deletion or Wikipedia:Featured article criteria or Wikipedia:Peer review, either, and that's okay. Wikipedia:Not every page needs a tag. As a general rule of thumb, if some process has been in operation every day for longer than you've been an editor, it's safe for you to assume that the community knows about it and doesn't strongly object to it. We use the principle of WP:SILENCE in our processes, too. WhatamIdoing (talk) 19:02, 15 May 2023 (UTC)

I don't believe that the present day ITN functions as it did in the 2000s, nor do I believe that it complies with the community's general expectations (hence this discussion). As Jayron32 said above, the discussions are controlled by a small group of vocal people, and ITN has moved away from any 2000s-era consensus that may have once existed. I also included a link of a recent VPI discussion in my post above as one instance where the community expressed dissatisfaction with the current processes at ITN. The WP:SILENCE has been broken many times by many editors, both at WT:ITN and here at WP:VP. All I'm really asking for is some oversight from the community. Thebiguglyalien (talk) 19:20, 15 May 2023 (UTC)

I'm responding to the last paragraph of your opening post, especially It has never undergone the sitewide scrutiny that's expected of pages like this. My message to you is: Sitewide scrutiny wasn't actually expected of that page back then.

As for the rest, I see that you complain that some editors, whom you call the "ITN regulars", voted differently from you in Wikipedia:In the news/Candidates/May 2023#(Posted) Coronation of Charles III and Camilla. What you seem to leave out is: your side won anyway, the entries you supported were on the Main Page, and none of those "ITN regulars" even complained very much about the result. Showing up to vote in discussions such as that one is what "some oversight from the community" looks like.

I'm not sure that there is any significant problem here (some editors not respecting others' rationales doesn't count), but if there is a problem, then holding a vote over how to label the page, so that it can either be definitively declared a guideline or a not-guideline, isn't the solution. A WP:PROPOSAL to tag a page is basically never the solution to any problem involving what editors want to see on the Main Page. WhatamIdoing (talk) 21:01, 15 May 2023 (UTC)

Maintenance templates

The process for creating a maintenance template is too easy. It creates situations where people can say that information is unreliable, when it is reliable without proof. That is especially problematic with pages that have less visitors that will edit.

I therefore propose that any editor that wants to create a template has to write out a justification that explains why he or she is right. That means provability, they for example would have to point out exactly where the articles are not citing correctly and why they are not cited correctly. That may mean having to read a source to judge if what the article says is provable.

Then after that editor is finished, he or she would have to show their work to an administrator who would have to approve and thoroughly explain why they approve. The same process should be done for the removal of a maintenance request. Orlando Davis (talk) 23:39, 11 May 2023 (UTC)

You would do well to learn a little more about how Wikipedia works before proposing changes in policy. Admins have no authority to make rulings regarding content. AndyTheGrump (talk) 23:44, 11 May 2023 (UTC)

If editors are putting Template:Advert on the article you contributed to, it's probably because you're adding content that sounds promotional or celebratory. The article should just tell us about the person's life. It shouldn't tell us how talented or successful they are. In the future, I suggest using the articles for creation process so someone else can review it before it becomes an article. Also, don't forgot that you don't own any article on Wikipedia. Anyone can add anything to it as long as they follow Wikipedia policies. Thebiguglyalien (talk) 23:59, 11 May 2023 (UTC)

I didn't create this one:

Sergio Oliva Orlando Davis (talk) 00:17, 12 May 2023 (UTC)

Or this one:

Clone trooper

There are many more. I think it's bringing down the quality of Wikipedia, the lack of checks to make sure content is verifiable. Orlando Davis (talk) 00:20, 12 May 2023 (UTC)

It's also not aesthetically pleasing. You wouldn't see that in the Encyclopedia Britannica. Orlando Davis (talk) 00:22, 12 May 2023 (UTC)

This is an old article, but it highlights some problems that I think have gotten worse.

http://edition.cnn.com/2007/TECH/11/02/perils.wikipedia/ Orlando Davis (talk) 00:24, 12 May 2023 (UTC)

And Sergio Oliva looks like it has problems in need of maintenance. I checked just one sentence and its reference: As a teenager, after only a year of training, Sergio was able to perform clean & jerks in excess of 400 pounds. Well, there's a boastful statement, and the source given, https://wikiz.com/wiki/Sergio_Oliva , is a mirror of Wikipedia, so its a circular reference. So yes, it has reference failure. Does it have enyclopedic tone failures? 'He then ran at top speed until he was safely inside the American consulate. Arriving breathlessly, he demanded and received political asylum. – so, yes. It is indeed an article that editors should be encouraged to improve. Britannica does not seek such improvement; we do. -- Nat Gertler (talk) 01:23, 12 May 2023 (UTC)

Hello Nat,

I do love your work. What about this article? It is one I am creating. I was told by 2 editors that it is not neutral, encyclopedic, and that it sounds like an advertisement. Do you agree?

Draft:Guillermo Rojas Bazan

I appreciate your feedback. Orlando Davis (talk) 01:54, 12 May 2023 (UTC)

Here is another one I created that I was told sounds like an advertisement:

Cherry Hill (model engineer)

What do you think. I appreciate your feedback. I read the peanuts comic as a kid. It is really great! I got a lot of laughs. Orlando Davis (talk) 02:20, 12 May 2023 (UTC)

Cherry Hill: "She is recognized worldwide among model engineers for the quality of her work." "During her 60-year career, Hill built nearly 20 super-detailed scale models of steam vehicles, including intricate Victorian models, which each took her approximately 7,000 hours to make. These models are remarkable because of their perfectionism and because the engines are completely operational."

Yep, that's "advert" speak, or more in WP-terms, WP:PROMO and WP:FLOWERY. Gråbergs Gråa Sång (talk) 07:16, 12 May 2023 (UTC)

Well, maybe it should change. If someone is stating facts and those facts are verifiable. Then that should be good enough. Even if verifying takes some effort like going to a library, or making phone calls. The neutral tone is stuff nobody cares about. You read an encyclopedia because you want to learn facts. Verifiability is the only thing that should matter.

There has been chat on Wikipedia that women engineers are not included due to misogyny. I think this article should have people trying to build it instead of tear it down. Orlando Davis (talk) 10:53, 12 May 2023 (UTC)

You can pretty much be an obstacle to the truth by setting up bureaucracy that makes it difficult to tell it. Orlando Davis (talk) 10:58, 12 May 2023 (UTC)

@Orlando Davis:, you focus on verifiability, so you should easily be able to prove The neutral tone is stuff nobody cares about. that received less comment than such as drastic statement really should. Given the vast number of sources talking about the neutrality, comparative neutrality, and lack of neutrality of Wikipedia I'm interest in seeing the rebuttal. Nosebagbear (talk) 01:21, 14 May 2023 (UTC)

The issues quoted are of neutrality. not advertising. As is often the case, it is wrong to describe them as "advertising". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:59, 14 May 2023 (UTC)

Presumably you are referring to addition and removal of maintenance templates not their creation, or at least that's what I infer.

Bluntly this proposal is a nonstarter, if you want to try and workshop something from your ideas at WP:VPI you are welcome to, but I don't see that as likely to produce anything actionable either.

Sysops have never had any special power over content and that's not going to change. Nor would the bureaucracy of sysop approval be workable in any case. If you believe a maintenance template was inappropriately added or notice that an issue a template refers to has been resolved you or any other editor in good standing can remove it. If the issue hasn't been resolved then maybe you should try to resolve the issue.

The templates do not bring down the quality of Wikipedia rather their purpose is to call attention to existing issues. The fact that we are tracking unsourced articles is a good thing, and believe it or not there are quite a few people who still work the backlog.

De gustibus non est disputandum, so I won't get too much into aesthetics. Some people don't like the size or prominence but part of what we are attempting to do is get people involved in improving articles and calling attention to issues in a prominent way increases the odds of that happening. 74.73.224.126 (talk) 01:14, 12 May 2023 (UTC)

What evidence do you have that the maintenance templates increase quality?  Has that been studied? Orlando Davis (talk) 01:31, 12 May 2023 (UTC)

I'm not sure what statement you're referring to. Regardless, the very fact that there are active projects dedicated to working certain areas of the backlog belies the idea that maintenance tagging serves no purpose. If instead you're asking if the WMF or anyone else has done any research on this question the answer is I don't know; Whatamidoing (WMF) would be in a better position to respond to such an inquiry.

Of course if you believe that e.g. {{BLP unreferenced}} is a net negative you can always start a deletion discussion, though I would strongly recommend against doing so. 74.73.224.126 (talk) 02:01, 12 May 2023 (UTC)

Thank you for that information. What is the link for submitting a request for deletion of may not reflect an encyclopedic tone, sounds like an advertisement, and does not sound neutral.? Where are the links for all the different maintenance requests? I appreciate it. Orlando Davis (talk) 02:40, 12 May 2023 (UTC)

@Orlando Davis, Wikipedia:Templates for discussion is the place. A full list of clean-up templates is here. I also strongly recommend against this - I think you're heading into disruptive editing territory, thus risking a block - but it's up to you. 199.208.172.35 (talk) 13:52, 12 May 2023 (UTC)

Hello,

I apologize if you believe that I am a disruptive editor. Could you show me where I have done that? You know, I have edited many articles for small errors, and have done my best to remove subjectivity in my editing. Everything is double checked to make sure it's right. and I don't impose subjective judgement on quality. Rather, I have focused on things that are generally accepted, for example spelling. Again, it is not my intention to be disruptive. I appreciate your help. Orlando Davis (talk) 14:19, 12 May 2023 (UTC)

@Orlando Davis, I think you've been edging into disruptive territory, and I wanted to give you a heads-up before you proceeded any further. IDHT-ing and BATTLEGROUND-ing is a bad idea even as a veteran editor; you are still quite new and unfamiliar with Wikipedia's policies and procedures. It's up to you where to go from here. I'd recommend standing back a bit, continuing to gain experience and ask questions, and revisiting your ideas about this issue when you have a few more months and several hundred more edits under your belt. 199.208.172.35 (talk) 14:44, 12 May 2023 (UTC)

I'll second everything 199 just said. Please spend some time editing and getting to know your way around before diving into the deep end. 74.73.224.126 (talk) 21:00, 12 May 2023 (UTC)

Even checking something as seemingly straightforward as spelling, grammar and style can involve subjective judgment to a degree when it comes to Wikipedia because of things like WP:ENGVAR, WP:CITEVAR, WP:DATEVAR, etc. For example, Wikipedia doesn't have one house-style of English, and it allows articles to be written in different varieties of national English. So, deference is often given to the style (spelling, grammar, formatting, etc.) established by the original creator of an article or the first major contributor to an article. In-article consistency is important per things per WP:ARTCON and WP:DATEUNIFY, but simply changing a previously established style just because it's not the one you (from hereon "you" in this context is the generic you) might prefer or regularly use yourself can be seen as disruptive, particularly if you're making a point of doing so across lots of articles within a relatively sort period of time without giving the matter much thought and when it's perhaps not really warranted. -- Marchjuly (talk) 22:40, 12 May 2023 (UTC)

74.73, I prefer to have volunteer-me answer that question. To the best of my knowledge, nobody has ever properly studied the effect that maintenance tags have on articles.

In my own experience, certain kinds of simple tags (e.g., {{Uncategorized}}) that are added to new articles probably do result in those discrete issues being addressed. Tags on heavily edited articles tend not to linger, so they are either effective or just removed.

However, for the most typical types of tags and the most typical types of articles, I strongly suspect that many of the more generic or whole-article tags (e.g., {{ref improve}}, {{third-party}} [which I created]) do not have a significant effect for typical articles.

Other tags may have a mixed effect. For example, {{fact}} may sometimes cause the loss of uncited but verifiable and accurate content (e.g., through edits such as this one), but might result in the addition of sources (e.g., through tools such as Wikipedia:Citation Hunt). WhatamIdoing (talk) 02:30, 13 May 2023 (UTC)

Often someone will add a maintenance template, and the article will get fixed, but no one will remove the maintenance template. If you come accross an article with a maintenance template that you feel is no longer applicable, check the article history to see when it was added and what changes have been made since then, and check the talk page to see if there is relevant discussion. If the issues have been fixed and/or there is no discussion, feel free to remove it, as I have to one of the examples you gave above, see this diff - and pay attention to my edit summary. ~ ONUnicorn^{(Talk|Contribs)}problem solving 14:34, 12 May 2023 (UTC)

Got it! Thank you! Orlando Davis (talk) 14:47, 12 May 2023 (UTC)

If one is less sure, one can talk about it first: Talk:Johnathon Schaech/Archive 1#The major contributor banner. It can be productive to ask the adding editor "Hey, I think I fixed this issue, do you agree?" Gråbergs Gråa Sång (talk) 16:07, 12 May 2023 (UTC)

I will agree that adding maintenance tags is too easy a process. I have come across articles with one of those tags slapped on top, & silently wondered if said editor's goal was simply to bloat their edit numbers -- which can be done quickly by adding a tag & moving to the next article to tag -- instead of taking the time to actually do the work improving the article. (I've had occasions where it took me weeks to find a proper citation.) After all, if you know enough about a subject to know the article needs expanding, you know enough to improve it -- or at least leave a note on the Talk page to explain what needs doing. I don't know how we can fix those cases, & while I remove any tag I feel is inappropriate or silly, I doubt any changes to policy will fix this problem.But I appreciate the opportunity to vent about it. -- llywrch (talk) 18:32, 16 May 2023 (UTC)

In general, any such template added without an explanation can be removed without one. So feel free to do so. You can't prevent people from doing the wrong thing, you can only clean up after them. --Jayron32 18:40, 16 May 2023 (UTC)

Capitalization of hockey rounds and such

Following on discussion at WT:MOSCAPS#And_again, there's an RFC at WT:WikiProject Ice Hockey#RfC: NHL round names capitalization, essentially asking for a Hockey exception. Comments? 04:25, 12 May 2023 (UTC) Dicklyon (talk) 04:25, 12 May 2023 (UTC)

Evolution/Creation

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

---

I've come from the 'horse' page. In the 1st paragraph it's redirecting to the page of a fossil and stating an evolution link. I am a creationist however I am interested in species adaptation. I have my own thoughts on macro vs micro evolution. In this situation, I wasn't expecting speculation, just living facts about horses. This is likely to be across many pages. It's a bad look. And honestly... it's a crap fossil, whatever that was it's unlikely it functioned like the horses of today. Suggestion: instead of 'the horse evolved from' - 'Some speculate that the horse(insert other animal)...' Because imagine yourself on the other side of things reading 'God made the horse on day 1 but it was still a bit dark so he had to adjust it later, which is thought to be this fossil...' 120.22.128.217 (talk) 11:15, 12 May 2023 (UTC)

Presumably you are talking about The horse has evolved over the past 45 to 55 million years from a small multi-toed creature, Eohippus, into the large, single-toed animal of today at horse. The body gives a series of reliable sources that suggest this is true. Are there any WP:RS by Wikipedia's definition that state otherwise?

You are welcome to your own WP:FRINGE theories, but this isn't where we promote them. This is also a content dispute, and shouldn't be at this location, rather at Talk:Horse as this isn't a policy change proposal. Lee Vilenski ^{(talk • contribs)} 12:13, 12 May 2023 (UTC)

Wikipedia has no interest in what you believe, or changing it for that matter. However, Wikipedia will continue to report things that are verifiably true and not merely to conform to what you wish were true. --Jayron32 12:49, 12 May 2023 (UTC)

If someone were to add "God made the horse on day 1", we'd have problems within existing policy. Even if we accept the Biblical account of creation and used that as a reference, land animals weren't created until the sixth day. Perhaps the modern horse is evolved from some sort of pegasus, but even that would only move it back to the fifth day. Whichever of those days it was, however, it came before Genesis 1:26 and the creation of man. That means that the only observer capable of recording events was the almighty himself, and it is His word, or Word inspired by Him, that this is what happened. So we're dealing with a WP:SELFSOURCE issue, and surely saying that one created the horse is a boastful claim (certainly if I invented the horse, it'd go right to the top of my resumé!) For matters of evolution, however, we have plenty of policies and guidelines on how to deal with science topics, relying on peer-reviewed literature and such. -- Nat Gertler (talk) 13:56, 12 May 2023 (UTC)

I think Eohippus would be pretty saddened to learn you called it "crap" if it was still alive. Of course it didn't function like the horses of today, there's a full Cenozoic of evolution between the two. Give it time, please! It filled more of a niche of small ungulate, like the dik-diks of today. Adorable little creature.

More seriously, there is definitely a debate to be had as to whether Eohippus should be mentioned in the first paragraph of Horse rather than of Equidae — it's just as much the (near) ancestor of horses as of other modern equids, although this line is often presented (misleadingly) as "horse evolution" even though it is just as much "zebra evolution". More of a question of how WP:RS discuss this topic, really (the facts stay the same — Eohippus or its close relative evolved into the modern Equidae species).

In terms of the evolution/creation matter, it isn't really a "one side vs the other side": verifiable scientific research overwhelmingly support evolution, and placing both on the level of personal beliefs is creating a WP:False balance that doesn't represent what the sources actually say.

Also, as the previous replies mention: this is a content dispute, not a policy change, so this conversation would be better located at Talk:Horse. Chaotic Enby (talk) 14:18, 12 May 2023 (UTC)

It is a 'content dispute' only in as much as the OP is arguing in favour of violating core Wikipedia policy regarding specific content. People who don't want to read about the evolutionary history of species are free to not look at Wikipedia articles on such species, but if they chose to read them, they can expect such articles to concur with the overwhelming scientific consensus on the subject. This clearly isn't open to negotiation on the talk page of the article concerned. There isn't any 'conversation' to be had. AndyTheGrump (talk) 02:16, 13 May 2023 (UTC)

I'd agree with that - I was mostly being polite, insofar as even if there weren't such policies or consensus, this should be at Talk:Horse rather than Wikipedia:Village pump (policy) of all things! But yeah, the conversation about hiding evolutionary history to not displease creationists shouldn't really be had to begin with. The only part of this discussion that is reasonable is whether Eohippus should be mentioned at Horse or at Equidae (or both!), but I don't think adding it to the Equidae lead even requires a conversation (interestingly, the first equid isn't even mentioned on that page!) I'll go and do it. Chaotic Enby (talk) 12:52, 13 May 2023 (UTC)

Added Eohippus to the Equidae lead. The body should probably get a rewrite, considering it mentions Hyracotherium instead which isn't considered an equid anymore (and isn't very up-to-date), but that's getting completely out of the scope of this... argument? I think we can call it closed, if anyone with a closing ability comes here. Chaotic Enby (talk) 13:03, 13 May 2023 (UTC)

There aren't "two sides" to this. There's facts and there's fairy tales. Encyclopedias deal in facts. --User:Khajidha (talk) (contributions) 16:12, 13 May 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.

Deleting to make way for accepting a draft?

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

---

Hi there. I created a draft article, and a few other editors and I worked on it before submitting it for review. While our draft was undergoing review, someone created the article in mainspace. The reviewer procedurally declined our draft for that reason, but said our version was more detailed. The reviewer would like to know, admittedly at my request, whether it would be permissible to delete the mainspace article to make way for accepting the draft? This would be on the grounds that the article shouldn't have been created when the draft was already submitted. I know it's a small issue, but I'd greatly appreciate it. Thanks! Davey2116 (talk) 15:34, 12 May 2023 (UTC)

For reference, the article is Kenvue, and the draft is at Draft:Kenvue. Davey2116 (talk) 15:34, 12 May 2023 (UTC)

If an article already exists, you can simply edit/rewrite it to include the information from your draft. No need for deletion and then recreation. Blueboar (talk) 15:42, 12 May 2023 (UTC)

I understand I can do that, but would the deletion/recreation by the reviewer be against some policy? I would prefer to keep the version history of our draft. Davey2116 (talk) 16:19, 12 May 2023 (UTC)

@Davey2116, an admin would need to do it, and they'd need a valid reason under our deletion policy. What rationale are you offering? "Our draft was first and it's better" is probably not going to work. 199.208.172.35 (talk) 16:44, 12 May 2023 (UTC)

I have done a histmerge. -- King of ♥ ♦ ♣ ♠ 16:51, 12 May 2023 (UTC)

Thank you! I was unaware this was called a histmerge, this is exactly the solution I was looking for. Davey2116 (talk) 16:59, 12 May 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.

These entire two discussions are closed as being started by a blocked user evading a block --Jayron32 17:13, 16 May 2023 (UTC)
The following discussion has been closed. Please do not modify it.
Add public on‑chain activity to WP:RS Consensus seems entirely clear that we aren't going to permit the use of primary blockchain data in the manner proposed, since it fundamentally violates core policies. The refusal of the OP to comply with requests to stop posting while logged out in regard to a subject where they have a clear CoI demonstrates a further unwillingness to actually listen. To be blunt, if the media doesn't report on this, neither will we. AndyTheGrump (talk) 14:18, 14 May 2023 (UTC) The following discussion has been closed. Please do not modify it. Hello, I wanted to bring updates to a cryptocurrency software article using sources from on‑chain data since no newspaper talks about it. And they were reverted in the name that blockchain activity isn’t part of WP:RS. This seems odd, because at justice on trials, blockchain data can be used as legitimate trusted proofs to tell what happened but not on Wikipedia. The only difference is the technical nature which requires some knowledge to read but in the end, there’s no error possible so it might even be more trustworthy. Ideally though, I recognize we shouldn’t be using random third party blockchain explorer websites, but that blockchain data should have it’s own Template like ɪꜱʙɴ in order to cite logged events ; transactions ; and/or addresses. In the case of Ethereum like blockchains, the recommended trusted way to access the p2p data is through a full archival node. 2A01:E0A:401:A7C0:8474:A152:73C7:23E (talk) 22:16, 12 May 2023 (UTC) I can think of very few circumstances where it would be appropriate to discuss "logged events ; transactions ; and/or addresses" in an article at all. Certainly not without the specific data also being discussed in secondary published reliable sources. Using blockchain data in the manner you propose would appear to violate WP:OR and could have serious WP:BLP implications. AndyTheGrump (talk) 22:32, 12 May 2023 (UTC) This would probably be a WP:PRIMARY source in all cases, and therefore super rarely appropriate to mention at all. "No newspaper talks about it" is a big shiny red flag saying that it probably shouldn't be on Wikipedia. casualdejekyll 22:45, 12 May 2023 (UTC) In the example we tried to edit, the global assumption of the press is that the software stopped working since the original developer team who created it disbanded and the original website and forums were sized (the fact they all left and the original off‑chain assets ceased to exists and that most almost all the userbase stopped using it is all true). This Point of vue is completely understandable since journalists tend to not be persons with a strong technical background, but that’s ignoring hosting shifted to the blockchain itself as a backup a few months before those events using alternative systems like the Ethereum Name System instead of the ᴅɴꜱ : I used the registration records as a source to prove the link to the official website. It’s also ignoring what is truly a ᴅᴀᴏ so that in the end it’s the userbase who decide which updates are applied and which persons are paid to maintain the project much like shareholders on the stock exchange. I used the logged events to show that updates were still pushed contrary to the article which states the latest version dates from 2021 (that 2021 claim itself in addition to being wrong is unsourced but it was reverted anyway despite the obvious fact that they are not always newspapers when a new version of a software is published) as well as transactions to details the voting process which took place and the address of the ᴅᴀᴏ. Think as falling from a cliff and not being found for 2 months : for this reason, your Wikipedia article is updated to declare you passed away in August 2022 using the news that states you fell from a cliff and that your property was even auctioned off. But while a major failure, you’re in reality still alive : you try to alert the press, but your relatives now refuse to talk about you in public and nobody has an interest in someone who is considered dead. In addition to your reputation (News article from peoples that declare they successed you in your work unaware you’re alive), that article is harmful to you because the providers who still work with you constantly require you to prove you are still alive when reading it (that part is true for us). So you end up editing your own Wikipedia article despite WP:COI by adding historical references from your own blockchain activity. But your own actions are declared to not be part of WP:RS and to be WO:OR. After 2 reverts, you can witness your own article being protected from vandalism in the state that declares you dead despite the WP:BLP#Legal persons and groups. With the latest news talking about you dating from your accident, at that point, you would quite frankly prefer to have that article that says rubbish about being deleted than corrected. sounds like a Monthy Python sketch ? But that’s exactly what is happening to ᴜꜱ. 2A01:E0A:401:A7C0:8474:A152:73C7:23E (talk) 07:39, 13 May 2023 (UTC) As a PRIMARY source that's almost always going to fail WP:WEIGHT. Unless you can find a reliable independant seconadary source supporting such material it's probably going to be excluded. If you believe a new template is needed you may request its creation at WP:RT 74.73.224.126 (talk) 22:55, 12 May 2023 (UTC) I tend to disagree with this in the case of computer science : an article that says something can’t happen (hence scientifically wrong) should be able to be corrected by a source that demonstrates it can happen (for example proving a cipher system can be deciphered and was multiple time deciphered). 2A01:E0A:401:A7C0:8474:A152:73C7:23E (talk) 08:25, 13 May 2023 (UTC) Your analogy is flawed, but even so, if reliable, secondary sources say that you are dead, Wikipedia doesnt have a choice but to accept that. To modify your analogy, what if you did die, and someone stole your identity and began to use that to drain your bank accounts. Bank transactions would show you as alive, and so long as the impostor didn't need to directly meet anyone, the impostor could pretend to be you. News sources may report you as alive, and even though someone had a photo of your smashed corpse at the foot of the cliff, that probably wouldn't convince anyone, since everyone would think that you are alive, and say that it was faked. You could try to stop them, but since you're dead, you can't exactly do anything about it. How about saying that you actually want to modify WP:NOR, WP:PRIMARY and WP:RS to make a special case for using blockchain data? That is what you would really need, but I can assure you that it has a snowball's chance in hell of succeeding. Mako001 (C)  (T)  🇺🇦 09:11, 13 May 2023 (UTC) Wrong and absurd! In the case of blockchain there s can be no impersonation. There are many peoples who claim to be Satoshi Nakamoto, and Wikipedia has even individual articles about such persons who proved to be Satoshi Nakamoto in court, but none of them control his funds. Here it is the reverse and there can be no key theft since the ᴅᴀᴏ is an immutable computer program acting on its own. If the Bitcoins of Satoshi Nakamoto are moved from their 11 years old addresses and sold on Bitcoin, then those transactions records should be used as a proof he is alive Argument from silence. About modifying WP:NOR, WP:PRIMARY and WP:RS, that s more efforts than just changing the status of the software and modifying the website domain to its original backup on Ethereum, hence why I prefer to request it here. 2A01:E0A:401:A7C0:C5CB:DD1:D5D9:D583 (talk) 10:21, 13 May 2023 (UTC) Please stop editing while logged out - doing so to avoid scrutiny while having a clear conflict of interest is a violation of Wikipedia policy. [3][4] AndyTheGrump (talk) 14:24, 13 May 2023 (UTC) Not the scrunity of Wikipedia but scrunity from the peoples looking at the article I m talking about. This section is watched by more than 1000 users. And otherwise we are aware of WP:COI. Thus we don t try to edit what is said about us like the fact the illegal activity was a minor part of the use. The aim is just to correct the fact we ceased to exists. 15:49, 13 May 2023 (UTC) — Preceding unsigned comment added by 37.174.43.101 (talk) Please stop saying "we". Wikipedia articles and discussions are supposed to be edited by individual people who are responsible for what is said, not "we"s. Phil Bridger (talk) 16:35, 13 May 2023 (UTC) Simply because I’m not the only person at the same who tried to fix we stopped existing. 2A01:E0A:401:A7C0:8474:A152:73C7:23E (talk) 07:34, 14 May 2023 (UTC) If the Bitcoins of Satoshi Nakamoto are moved ... then those transactions records should be used as a proof he is alive — or evidence that someone else has the password / private key to those Bitcoins, which is a plausible scenario. Digital inheritance is a thing. Passwords can be held in escrow. Mitch Ames (talk) 04:00, 14 May 2023 (UTC) If that was the case, it would had been done long before. More seriously, almost all courts can sentence you for using your blockchain activity as the only source of real proof. See the courts documents of https://www.reuters.com/article/usa-silkroad-agent-idUSL1N1162JJ20150831 for an example. Also, I don’t see why an official registration document can be used as a WP:RS source but not an official equivalent log on the blockchain. 2A01:E0A:401:A7C0:6CB7:4A51:17D:B464 (talk) 07:06, 14 May 2023 (UTC) I don't think that requesting for the creation of the template is a good thing before this is established or not as a WP:RS, it would be a bit premature to create a template just for the consensus to end up being that it shouldn't be used as a source. Chaotic Enby (talk) 05:18, 14 May 2023 (UTC) There is very little chance that a record on Blockchain would ever be considered an RS. There's so incredibly small chances that something coming from this, that isn't mentioned elsewhere in other RS would be suitable for inclusion in an encyclopedia, and would likely fall foul of RS. I'd recommend closing this discussion as it's clear that it's just starting an argument. I would also recommend logging into any accounts you have, and if this is multiple people talking (the use of the word "we") to not edit Wikipedia at all, accounts and IPs should only ever be edited by one person. (I get that IP addresses work different, but I get the feeling I'm talking to someone who is representing a series of people). Lee Vilenski (talk • contribs) 11:33, 14 May 2023 (UTC) You’re indeed talking to an ɪᴘ address using a fixed ɪᴘᴠ6 prefix representing a group of people but the edits that were reverted were made by a group of people. I now recognize the only time the press talked about us is when all off chain assets were sized which is why there’s no Wikipedia article before and our notoriety remains small. Though such arguments here come against the generally admitted reasoning in the blockchain field : so I invited a few more people not linked to the software who will be able to explain better than me. Meanwhile, please leave this question open for the following 3 days. Otherwise, an example website registration using a web proxy (everything is verifiable independently on the command‑line using your own full Ethereum archival node). According to the registration, the manager is 0x5efda50f22d34F262c29268506C5Fa42cB56A1Ce which is linked by Etherscan as the ᴅᴀᴏ and also included in the ᴏꜰᴀᴄ’s blockchain list under that purpose. But it’s not only someone who transferred control as the program stored at 0x5efda50f22d34F262c29268506C5Fa42cB56A1Ce indeed used it’s manager role to update it in https://etherscan.io/tx/0x07194973cfc042c452eb7370ded8e953533a202ffa842ddfa24e41cc15f81862/advanced#eventlog (use eth_getTransactionReceipt on your full node on 0x07194973cfc042c452eb7370ded8e953533a202ffa842ddfa24e41cc15f81862 for an independent confirmation). Thus https://app.ens.domains/tornadocash.eth?tab=more is indeed the live website of 0x5efda50f22d34F262c29268506C5Fa42cB56A1Ce. And using such on‑chain proof as a sole source, this is the reason 0x5efda50f22d34F262c29268506C5Fa42cB56A1Ce was added later by the OFAC in the list whereas it wasn’t included initially (and is also why https://etherscan.io/accounts/label/ofac-sanctions-lists by being not up to date contains addresses in the same category but not 0x5efda50f22d34F262c29268506C5Fa42cB56A1Ce). 2A01:E0A:401:A7C0:8474:A152:73C7:23E (talk) 14:03, 14 May 2023 (UTC) How to source the preview release date when using Template:Infobox software? The problem is it s rare for a news article from third party sources to be published for beta or Alpha releases. Some large software like Windows do receive media coverage but other ones like Mozilla Thunderbird or Firefox have their release date self sourced using links to downloadable versions for the simple reason it happens every day. And indeed, a quick look to Special:WhatLinksHere/Template:Infobox software give many examples not sourced at all. In my case, I edited an article using the backup link to the official newer release (WP:SELFSOURCE as reference) and it was reverted 2 times (by 2 differents users) to the itself previous completely unsourced release date in the name of WP:OR and WP:RS. That I can use them only as WP:SECONDARY and I need to find reliable third party WP:PRIMARY. What s the proper way to achieve this? Or if using reliable secondary third party sources is really needed even in that case, is a large cleanup across thousands pages needed? 37.170.88.2 (talk) 11:26, 16 May 2023 (UTC) WP:ABOUTSELF seems to me to say that it is valid to source a release date to the company itself; "Self-published and questionable sources may be used as sources of information about themselves, usually in articles about themselves or their activities...so long as:the material is neither unduly self-serving nor an exceptional claim; it does not involve claims about third parties; it does not involve claims about events not directly related to the source; there is no reasonable doubt as to its authenticity; and the article is not based primarily on such sources." All of that applies to a company's own claims about their own release dates; it is not exceptional, does not involve claims about third parties, it is directly about the source, there is no doubt as to the authenticity, and it's only used for a single date; thus the article isn't really relying solely on such sources. You should be fine using the company who published the game as a source there, and anyone who says you can't isn't aware of Wikipedia's guidance on this. --Jayron32 11:37, 16 May 2023 (UTC) can such thing also apply to the official address of the website? For example, can the old unused official Twitter account which is referred by reliable third party sources be used to reflect a longtime non updated change on the article? Given the newer Twitter account that referred the same newer address was deleted by the fired angry community manager. I would understand it should be left as is if updating the website to the backup address is not possible. 37.170.88.2 (talk) 12:46, 16 May 2023 (UTC) If the Twitter account is verified as official, and it makes a statement which covers something banal and uncontroversial and simple, it's probably okay, though of course the devil is in the details. The "deleted by the fired angry community manager." does not, however, sound to me like a likely positive sign for usability, however. Given that this is apparently some source of controversy, I would find some source that was not so ephemeral that a disgruntled employee could screw it up. --Jayron32 15:24, 16 May 2023 (UTC) @Jayron32 This IP is Ytrezq evading their block, see Wikipedia talk:Sockpuppet investigations/Ytrezq. 192.76.8.85 (talk) 17:00, 16 May 2023 (UTC) I’m sure you are aware of this, but… one potential problem with ABOUTSELF announcements of pending release dates is that they are notorious for being inaccurate estimates. This is especially true when the expected release is scheduled for several months from the initial announcement (delays often occur). Blueboar (talk) 15:45, 16 May 2023 (UTC) I m mainly talking about using links to past published releases. Not necessarily announcements. 37.170.88.2 (talk) 16:47, 16 May 2023 (UTC)

ARBPOL amendment referendum live

As the petition for an ARBPOL amendment to remove the right for Jimbo Wales to act as an appeal route for arbcom decisions has received 100 signatures a referendum on the proposal has been opened.

Proposed amendment referendum

It requires a majority in favour with at least 100 supporting editors.

CENT, WLN, WP:AN, and VPP will all be notified. Please feel free to provide neutral notices to other relevant fora. Nosebagbear (talk) 11:06, 17 May 2023 (UTC)

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)

• 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)

• 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)
• 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)
• 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)

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)

• 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)

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)

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