Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

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

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
• Consider developing your proposal at Village pump (idea lab).
• Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
• Proposed policy changes belong at Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.
• Proposed new articles belong at Wikipedia:Requested articles.

« Archives, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Time to incubate the substubs

I propose that any stub I created which is below 200 bytes of readable prose/a one line stub without actual information be incubated/moved to user space until they can be fleshed out properly. Most will be at least 5 years unexpanded. It was wishful thinking at the time but there's a lot of currently unacceptable ones which really shouldn't be swamping the categories. There's enough crap content here as it is. There's a lot of "xxx is a village in xx. As of xxx it had a population of xx". Those are bare minimum useful with one fact but I think if there's hundreds of them like that in one category redirect and listify it by district into an A-Z table with population would be more sensible rather than incubate. I was browsing through some places in Nepal etc I created and to be honest a lot of them have degraded with local ips adding dubious, unsourced factoids. Small villages in the developing world are off most people's radars. In a lot of cases we're better off having a list with the population until somebody can write a half decent article and watch it.♦ Dr. Blofeld 12:48, 14 November 2018 (UTC)

Absolutely not. Some places (which are automatically notable) have stub articles <200 bytes long. 'Incubating' these stubs isn't going to help if they just languish in draftspace forever. If they're not being improved now, there's even fewer chances that they'd be improved later. It's a bad idea. Thanks for your suggestion, though -- I'm prone to some less than stellar ideas at times, moreso than most editors. ProgrammingGeek ^talktome 14:46, 14 November 2018 (UTC) Okay, so apparently I didn't read the proposal closely enough, sincere apologies! Striking in favour of new comment below. (15:59, 14 November 2018 (UTC))

Oppose - I am with ProgrammingGeek on this one, if you see a stub under 200 bytes that fails WP:N then just send it to WP:AfD. - Knowledgekid87 (talk) 14:52, 14 November 2018 (UTC)

I'm not a renowned fan of mass stub creation, but fact of the matter is, it's easier for a new editor to improve an existing stub than it is for them to create one. GMG^talk 14:53, 14 November 2018 (UTC)

I'd also like to see automated or semi-automated stub-suggestions for new editors, but I'll let you know when someone somewhere cares about my opinion. No luck so far. GMG^talk 14:54, 14 November 2018 (UTC)

I think you can configure SuggestBot to do such a thing, but haven't ever really tried. Ivanvector (^Talk/_Edits) 14:56, 14 November 2018 (UTC)

Well, I meant for example, if someone registers an account, and their first edit is on a rugby player, something like SuggestBot comes by (probably using category information) and says "I see you know that rugby is a thing that exists, here are some stubs (read: things we know you can work on that probably won't get deleted)". But if the user has to configure SuggestBot themselves...well...if they could do that then they know enough of what they're doing that they ain't the target audience. Having said that, queue 4.5 million angry comments about how that is too close to automated welcoming and perennial yadda yadda yadda (even though we've long identified finding work as a barrier to entry for new users). GMG^talk 15:01, 14 November 2018 (UTC)

I think we've hit on a separate discussion here, but I for one like the idea of automatically welcoming new users (or, say, newly autoconfirmed users) and offering them some "getting started" suggestions, like filling out a stub or de-orphaning something or I don't know what. Or make something so more experienced users can trigger suggestions, like putting some derivative of a SuggestBot template on their page along with a welcome template. Ivanvector (^Talk/_Edits) 16:09, 14 November 2018 (UTC)

• Could we just be clear that the stubs concerned here are only those created by Dr. Blofeld. Maybe if he could give us a few representative examples that would be helpful. – Uanfala (talk) 14:58, 14 November 2018 (UTC)

Dr. Blofeld is in the top 50 by edit count not sure exact number but over 350,000 which means XTools doesn't work for finding a list of article creations. One can find them using this but it also includes redirects and page moves. The limit=5000 will work .. probably a huge number in total. -- GreenC 15:04, 14 November 2018 (UTC)

Comment I've come across Dr. Blofeld stubs over the years on obscure topics (regional German language poetry awards) and they have been useful for creating blue links when backlinking or filling in a few details. Sometimes the titles need to be adjusted for English. Not sure it would be helpful to delete unless there are some known cases of bad ideas like every fire station in Belarus. -- GreenC 15:01, 14 November 2018 (UTC)

@ProgrammingGeek, Knowledgekid87, and GreenMeansGo: I think you've misread the question. What Dr. Blofeld is asking for is authorisation to conduct a mass transfer of any stub I created which is still below 200 bytes of readable prose (my emphasis). Dr B would be the first to admit that some of his earlier stubs have problems with sourcing and accuracy, and because there are so many of them (I don't have the numbers but at a rough estimate we're talking between 10,000 and 100,000 pages, many of which are genuinely unexpandable substubs bot-created from databases with no text other than "X is a building in Y" or similar) it would require a bot to perform a bulk move of the relevant pages to a {{noindex}}ed space where the sourcing and prose issues can be cleaned up at leisure, and such a bot would require community consensus. What the three of you are effectively saying is that you're better placed than him to assess his own contributions. ‑ Iridescent 15:08, 14 November 2018 (UTC)

No, I understand the question. I also understand the Dr. B is so prolific it's hard to separate an attitude toward his stub and an attitude about stubs. GMG^talk 15:15, 14 November 2018 (UTC)

I've not been prolific in a very long time, I used to create an enormous number of placeholder stubs pre 2012 which if they've not been expanded this since probably won't soon. My attitude means all stubs not my own but I can't control those.♦ Dr. Blofeld 16:04, 14 November 2018 (UTC)

But other than the fact that they are your stubs, that's not really an argument that doesn't apply equally to all stubs, of which we have 3.2 million (about half the project). If they're non-notable, then yeah. They should be deleted and never should have been created. If they're notable, then it's a waste of time to delete them when they need to at some point in the future be recreated. Besides that, I'm fairly confident in saying that automatically deleting tens or scores of thousands of articles is probably not what the community had in mind when authorizing G7. GMG^talk 16:17, 14 November 2018 (UTC)

Yes, that's exactly what happened. Sorry. ProgrammingGeek ^talktome 15:59, 14 November 2018 (UTC)

The vast majority are notable, but there's a lot of things like one liners on small rivers, obscure villages etc with no real information, a lot which are hardly vital articles and more marginally notable. A great deal of them might be better listified. If G7 is a problem then they can be moved to user space of course.♦ Dr. Blofeld 18:13, 14 November 2018 (UTC)

But again, you're mostly making an argument against stubs in general, and not some critical flaw in these stubs in particular. GMG^talk 21:42, 14 November 2018 (UTC)

• Support in case it's not obvious from my comment above. That we automatically delete any article without question from the mainspace if requested in good faith and provided that the only substantial content of the page was added by its author has been a basic principle of Wikipedia for a decade; all that's being requested here is that it be done by technical means rather than Blofeld be forced to manually move 10,000+ pages and tag the resulting cross-namespace redirects for deletion. ‑ Iridescent 15:12, 14 November 2018 (UTC)
• Sure We can incubate (do you mean draftify?) these stubs that only you worked on. That way anyone who wants to work on one and get it main worthy can do so. Alanscottwalker (talk) 15:22, 14 November 2018 (UTC)

Some way of removing what we would call "sub stubs" from the mainspace. If they've not been expanded in six years plus years they're unlikely to be soon. I say under 200b as a lot are fleshier and decent. Basically anything which is a one liner xxx is a bla bla bla, get shot of, if it's that notable somebody will write it later. I did mostly create notable subjects but a lot are ones which most people will hardly be looking for information on. I just think it's time we took this project by the scruff of the neck and had a giant cleanup.♦ Dr. Blofeld 15:55, 14 November 2018 (UTC)

Yes, (and next up, how can we get NSPORTS to listify all those player stubs (say, what!?!)) -- Alanscottwalker (talk) 16:02, 14 November 2018 (UTC)

• (edit conflict) Changed to Support per Iridescent, provided that Dr. Blofeld is the only user that has contributed to the draft. If there's consensus and you need someone to write the bot, just ping me. Best, ProgrammingGeek ^talktome 15:59, 14 November 2018 (UTC)
• Oppose Yes a lot of the sub-stubs are bad and cannot be expanded, and when this occurs they can be individually deleted for lack of notability. I do not see why they should all be deleted because of this, many of the articles are presumed notable. This would set a precedent to delete in excess of a million articles. Maybe more. — Frayæ (Talk/Spjall) 16:11, 14 November 2018 (UTC)
• Support On reflection I think a certain level of minimum quality would be reasonable given what we hold as the standard at AfC. None of these articles would meet the requirements we insist on there so deleting/incubating them is reasonable. — Frayæ (Talk/Spjall) 17:00, 14 November 2018 (UTC)
  • I don't think you understood the proposal. Natureium (talk) 16:13, 14 November 2018 (UTC)

Yes, nothing is being deleted, just moved behind the scenes until they have adequate information. I did identify a lot of notable subjects but if they're still placeholders after years then they're not going to be developed soon.♦ Dr. Blofeld 16:23, 14 November 2018 (UTC)

If you approve a bot capable of moving substubs to draftspace then it can potentially be used to remove maintenance backlogs to draftspace as well. Incubated articles are deleted after 6 months via G13. This is a bad idea. — Frayæ (Talk/Spjall) 16:30, 14 November 2018 (UTC)

Then we'll put them in a special category so nothing gets deleted and they're linked in a place people can work on them if they wish.♦ Dr. Blofeld 17:08, 14 November 2018 (UTC)

There are no exceptions to G13 and looking at previous RfC discussions on the subject it is going to stay that way. If you want to keep the pages more than 6 months you should make sure they are put in your userspace where you have some say on the matter. — Frayæ (Talk/Spjall) 17:17, 14 November 2018 (UTC)

Move to user space then.♦ Dr. Blofeld 17:30, 14 November 2018 (UTC)

• Support. Much better than going through all of them. Natureium (talk) 16:13, 14 November 2018 (UTC)
• Support. Deletion criteria should take into account number of backlinks to non-dab mainspace articles; number of external links; byte count of plain-text article body. -- GreenC 16:22, 14 November 2018 (UTC)
• Comment. I do not have a strong opinion either way, but if this gets closed as oppose or no consensus, we might still want to make a list of such articles so that interested parties could work on it.--Ymblanter (talk) 16:37, 14 November 2018 (UTC)

A typical stub of mine will look like Thüringische Muschwitz, that's 7 years old. Has an infobox and length but little else and the whole category is flooded with ones like it. I think ones like that would be better off in a List of rivers in Thuringia with a table giving information on source and mouth and length so no information is lost until somebody can write a better article.♦ Dr. Blofeld 17:50, 14 November 2018 (UTC)

• Comment I thought we had generally considered that WP functions as a gazetteer, and thus justifying stubs of any officially recognized town/village or natural landmark, with the basis that local sources potentially could be used to expand these (keeping in mind, no deadline exists for that). I understand if we were talking stubs on persons or other less permanent elements to userify them, but places seemed to have been handled differently in the past. --Masem (t) 18:08, 14 November 2018 (UTC)

True, but the issue I think is people searching through categories and wanting to read and find decent articles and finding almost every entry is xxx is a village and no real information. I've been browsing some and it is frustrating when viewed from a reader's perspective. For a lot of those you could currently represent the same information in one list instead of having to browse dozens of articles just to retrieve one figure.♦ Dr. Blofeld 18:22, 14 November 2018 (UTC)

I can see listifying these then by logical groupings to give better context to readers, but this would still demand that redirects be left behind (as a gazetteer, these are searchable terms) and to that end, it doesn't make sense to necessary userify them and instead just appear a redirect to the history. --Masem (t) 18:27, 14 November 2018 (UTC)

Note that I expanded Thüringische Muschwitz a bit and now it is slightly longer than it was when Dr. Blofeld wrote the above comment. If we stick to 200 bytes, it is not eligible now to be moved.--Ymblanter (talk) 19:12, 14 November 2018 (UTC)

• Oppose - I think removing them on grounds of quality (vs normal deletion grounds) is incorrect - I don't think it functionally harms Wiki and they can be beneficial if and when someone does want to write on one. Obviously most go a long time without being edited, but there are so many the rate of at least some having edits made must be reasonably high. Nosebagbear (talk) 18:34, 14 November 2018 (UTC)
• Leaning oppose. I honestly don't see what's the problem with having these mini-stubs in mainspace, as long as the factual correctness is not in dispute and they have a minimum of sourcing. I would have found Thüringische Muschwitz useful (even in its pre-Ymblanter state), not least because there's the language link to the more developed version on deWP. Also, as noted above, expanding a stub is easier than creating a new article. And every so often someone comes along who does specialize in Nepalese hamlets, even if it does take longer than 6 years - why not make it easy for them to get going? --Elmidae (talk · contribs) 19:24, 14 November 2018 (UTC)
• Oppose - if you don't like that they are so short, then you can always just expand them... Thanks. Mike Peel (talk) 20:00, 14 November 2018 (UTC)

Redirecting these villages to the district where we can put a list of all of them would be the preferred way to go. Don't dump them all in userspace or draft where no one will work on them and they will just need to be managed with the tens of thousands of other abandoned pages there. Legacypac (talk) 21:58, 14 November 2018 (UTC)

A huge number did get expanded though, I'd forgotten how many valuable subjects I'd started too! Yeah maybe the ones with hundreds of villages and one liners belong in a list.♦ Dr. Blofeld 23:01, 14 November 2018 (UTC)

Oppose deletion of the stubs. Even if they're low-quality and very short, at least it's not actual garbage, unlike some examples of mass creation... ^Semi_Hypercube ✎ 23:52, 18 November 2018 (UTC)

• Oppose deletion or moving to userspace/draftspace or anything else. If the subject of the article is sufficient to survive deletion discussions, there is no reason to delete or move or do anything to such sub-stubs. If the article should exist, there's no reason to delete beyond the obvious (copyvio, etc.) and just "being too short right now" is not a reason. If the article shouldn't have existed in the first place, by all means, delete it, but if it could be expanded properly, but merely hasn't, please don't.--Jayron32 03:47, 19 November 2018 (UTC)
• Oppose moving them to draftspace or userspace. Firstly, it could mean we end up with two articles for some subjects, one in draftspace/userspace and another in mainspace when someone recreates it. Secondly, it drastically reduces the number of people who are likely to improve the stub. If you want to improve them, then improve them in mainspace and give others the opportunity to help. If the vast majority are notable, then it is inappropriate to delete them. I like the suggestion that some articles be changed into redirects to lists where the small amount of information can be preserved, avoiding the issue of the articles being recreated by editors who might be unaware of the previous article or this discussion. If the information in the list is expanded, it would be easy enough to split it and replace the redirect. Jack N. Stock (talk) 05:01, 19 November 2018 (UTC)

• Oppose removal of stubs: When the info is presented neutrally, a bit of information is better than no information. Also, the mere existence of the article is also informative as it tells the world that a certain topic exists (a town, for example). Moreover, from the editors perspective a stub is more inviting for multiple editors to make small contributions that collectively add up to a better article. In contrast, removing the article from the main space makes it more daunting for any one editor to have to draft a more fleshed out article before publication. Thank you. Al83tito (talk) 18:42, 21 November 2018 (UTC)

• Oppose More users are likely to edit and improve these stubs if the are in the mainspace. —Eli355 (talk • contribs) 21:56, 22 November 2018 (UTC)

• Oppose. Incubating makes it far less likely that these articles will ever be improved. — pythoncoder  (talk | contribs)

• Oppose. Slightly time-consuming and removes information from Wikipedia. Hdjensofjfnen (♪ Oh, can I get a connection? Alternatively, trout me.) 03:11, 30 November 2018 (UTC)

• Strong Oppose. Outside of articles with serious issues, a short article is much better than no article. In the case of a town, for instance, even a substub can tell you where a place is located, what state/province/county it's in, and basic facts like its elevation and postal code (which may be in the infobox and not the readable prose). A short article also makes a topic more likely to be expanded, especially by new editors (who can't write new articles, probably won't find drafts as easily, and may think anything without an article isn't notable). TheCatalyst31 ^{Reaction•Creation} 22:27, 1 December 2018 (UTC)

• Oppose These stubs can be useful even if they are short. Doing this would likely remove any possibility of improvement on the vast majority on them. Linguistical (talk) 07:12, 2 December 2018 (UTC)
• Oppose as incubating is an almost useless process. Being in place they are more likely to receive the heat of editors. They has some small use, so geographical stubs are better there than not. Graeme Bartlett (talk) 08:03, 2 December 2018 (UTC)
• Oppose Whats the harm of the article? As above, these articles would likely not be touched for improvements, so readers and new editors who may want to expand the content of this stub won't be able to find it. If the article is that small that it needs to be moved to draft space, even when the article is 5 years old and isn't likely to be expanded on, then it should be sent to AfD. 17:34, 2 December 2018 (UTC)
• Oppose moving out of namespace 0. If they're a definite net negative, delete them (this can be a good decision if, for instance, a bot could easily create them from scratch from Wikidata data in the near future). Otherwise, keeping them in namespace 0 is the only way for them to have a chance to be improved and attract contributors, while in another namespace they would just rot and amass dust which makes the site less healthy. Nemo 16:24, 9 December 2018 (UTC)
  • For what it's worth, a quick query lists about 43k small articles on settlements by Dr. Blofeld which according to TreeViews end up having over 1.5 million pageviews per month, distributed rather evenly. Nemo 17:37, 9 December 2018 (UTC)
    • 1,500,000 divided by 43,000 gives 34 pageviews per article per month, or one view per day. That's lower than the traffic one would expect just from search engine crawlers and people clicking Special:Random; to put it another way, each of these pages is averaging 1⁄30 of the traffic our article on Cats That Look Like Hitler gets. ‑ Iridescent 17:52, 9 December 2018 (UTC)

Slack workspace for en-wiki

Not sure if this is the best place to start this thread but going to give it a try. For some time I've been kicking around the idea of a better chat platform for Wiki users who want to have real time communication with eachother. I was considering starting a Slack workspace and was curious if anyone would be interested in joining? Just gauging interest. --Zackmann (^{Talk to me}/_{What I been doing}) 18:10, 21 November 2018 (UTC)

• We already have a chat platform for Wiki users ... It's called a talkpage, Sorry for the bluntness but I don't really think we need a chat platform when we have talkpages..... –Davey2010^Talk 18:38, 21 November 2018 (UTC)

  Well as I said in my comment I was talking about real time platform. But I'll definitely put you down for an nonconstructive no. --Zackmann (^{Talk to me}/_{What I been doing}) 19:17, 21 November 2018 (UTC)

• We have both a more-or-less official IRC channel as well as an unofficial Discord. --Izno (talk) 19:19, 21 November 2018 (UTC)

  This is also the kind of idea that should probably be at WP:VPI instead in the future. --Izno (talk) 19:24, 21 November 2018 (UTC)

  @Izno: wasn't aware of Discord! Thank you for the tip. That works just as well as Slack so I'm joining there! :-) --Zackmann (^{Talk to me}/_{What I been doing}) 19:28, 21 November 2018 (UTC)

• Such a workspace would be bending or at least testing policy; per Wikipedia:Consensus Discussions on other websites, web forums, IRC, by e-mail, or otherwise off the project are generally discouraged, and are not taken into account when determining consensus "on-wiki". In some cases, such off-wiki communication may generate suspicion and mistrust. Most Wikipedia-related discussions should be held on Wikipedia where they can be viewed by all participants. we shouldn't use offwiki venues unless there is a good reason for, and regular article work almost certainly does not qualify. Jo-Jo Eumerus (talk, contributions) 19:31, 21 November 2018 (UTC)

  @Jo-Jo Eumerus: Another VERY good point! I appreciate you raising that. I was not aware of it. Certainly not attempting to circumvent policy here. --Zackmann (^{Talk to me}/_{What I been doing}) 19:34, 21 November 2018 (UTC)

  I think "are generally discouraged" probably should be removed as it does not add to the point of the policy, and almost certainly doesn't take into account the current reality of how many different ways there are to communicate about Wikipedia. The sentence would objectively read better as Discussions on other websites, web forums, IRC, by e-mail, or otherwise off the project are not taken into account when determining consensus "on-wiki". I also don't think Most Wikipedia-related discussions should be held on Wikipedia where they can be viewed by all participants. is framed particularly well or particularly necessary either. --Izno (talk) 19:35, 21 November 2018 (UTC)

  I would personally prefer that it be made clear that the only prerequisite for participating fully in community discussion is access to the web site. I'm not sure if a rewording of the last sentence is needed to ensure this. isaacl (talk) 22:36, 21 November 2018 (UTC)

  I think probably we should have the converse of the first sentence (with my suggested removal) or similar to enter into that same sentence, rather than the weak item at the end. Something like "Consensus is developed on Wikipedia by editing its pages and on its talk pages by discussing. Discussions elsewhere—i.e., on other websites, web forums, IRC, by e-mail, or otherwise off the project—are not taken into account." --Izno (talk) 23:04, 21 November 2018 (UTC)

  WT:CON#Workshop on amending guidance for off-wiki discussions opened. Enterprisey (talk!) 04:10, 2 December 2018 (UTC)

My experience with IRC (granted, less than many others, but an occasional lurker for some years) is that #wikipedia-en is largely a social venue. There's some pointing to vandalism, problematic new pages, talking about Wikipedia goings-on, but it's not where substantive discussions happen such that it might purport to constitute some part of the consensus-building process (responding to Jo-Jo's point). There's the occasional canvassing, but it's sufficiently well populated with people who understand off-wiki coordination for that sort isn't ok. It's useful sometimes if you see someone there that you're involved in a discussion with, to hash something out directly (presuming it's something that doesn't involve other people), but other times I wonder about its usefulness. Right now people are talking about music, the death of George Bush, and commiserating about spending time on Wikipedia. In other words, it's socializing. That's not a bad thing, to be clear; it may help community (even if a particular subcommunity of IRC users). But I wonder if there's a need for more of that. What would happen in such a Slack channel? Would it be another place for socializing, or do you foresee other applications? Would it be the same as IRC but less....ancient? I use Slack for other purposes and would likely join to check it out, but I'm not sure what it adds. — Rhododendrites ^talk \\ 07:04, 1 December 2018 (UTC)

I'm surprised nobody's objected that Slack is closed-source and can be shut down at any time by the company, whereas IRC is open-source. (I use IRC very frequently, so I'm quite biased here, but anyway...) Enterprisey (talk!) 03:52, 2 December 2018 (UTC)

Should administrators be able to unblock themselves?

Tracked in Phabricator
Task T150826

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.

---

As raised on this thread at WP:BN, it has been questioned if we should still allow admins to unblock themselves. Therefore, I am proposing three versions, based on what was stated:

• Version A – No administrator, not even bureaucrats, are allowed to self-unblock.
• Version B – Only bureaucrats can unblock themselves. Other admins cannot unblock themselves.
• Version C – Status quo. Any admin can self-unblock.

^Semi_Hypercube ✎ 14:42, 23 November 2018 (UTC)

Clarification I'm not talking about policy, I'm talking about the technical ability (the (unblockself) permission) to self-unblock. ^Semi_Hypercube ✎ 20:29, 23 November 2018 (UTC)

Er, what? Version C is pretty much diametrically opposite to the status quo, which is Version A other than in the case of self-blocks, as spelled out in weary detail at WP:NEVERUNBLOCK; if an outright vandal were to compromise an admin account and block me with a block summary of "fuck you" I'd still not be allowed to unblock myself. If you're asking us to recode MediaWiki to make it technically impossible to self-unblock, that's not going to happen, as we're not the sole users of the software and some smaller wikis with only one admin need the technical ability to self-unblock in the case of mistakes. ‑ Iridescent 15:01, 23 November 2018 (UTC)

@Iridescent: my reading of this is that it is about technical measures. And it should not be hard to remove the 'unblockself' permission from the sysop group if we really wanted to for just our project. — xaosflux ^Talk 15:17, 23 November 2018 (UTC)

Removing unblockself could create a security hole if a rogue or compromised admin manages to block all other (active) admins. Doubly so since apparently phab:T19014 implies that blocked bureaucrats would not be able to stop the compromised account. You'd have to wait for steward action which would prolong the time it takes for damage to be constrained. Also, added a phab task where this RfC question is being discussed. Jo-Jo Eumerus (talk, contributions) 15:24, 23 November 2018 (UTC)

@Jo-Jo Eumerus:, but with 'option B' above, a blocked crat (who is also an admin) could unblock themselves, then block the offender, then start unblocking admins who could then in turn unblock other admins. — xaosflux ^Talk 15:29, 23 November 2018 (UTC)

• It seems like common sense to me that if there is a clear cut case of a compromised admin account or an admin gone rogue blocking numerous other admins, an exception to the prohibition on self-unblocking should be in place. Otherwise, in the course of more normal circumstances, neither an admin nor a 'crat should be able to self-unblock. bd2412 T 15:38, 23 November 2018 (UTC)

  @BD2412: I think this is about 'technical controls' not policies. Currently the only practical ways to stop a rogue admin is: (a) desysop them, (b) get a steward to globally lock them. — xaosflux ^Talk 15:42, 23 November 2018 (UTC)

• Version B, assuming that we're talking about technical capabilities. The only generally acceptable reason for an admin to unblock themselves is if they self-blocked, and there's really no reason to do that. Self-blocking by mistake or to enforce a wikibreak is easily rectified by pinging another admin, and we have test accounts for admins to test the block functions. An admin blocked by a rogue account can and should contact a 'crat immediately. The community has already basically strongly rebutted all other previous and potential uses of self-unblock; there is no good reason for it to be available, and several very good reasons why it should not. But as Jo-Jo Eumerus and xaosflux already suggested, disallowing 'crats from self-unblock is a Bad Idea. Ivanvector (^Talk/_Edits) 15:46, 23 November 2018 (UTC)
• Can we get some stats on how often admins unblock themselves, and under what circumstances? The only bad self-unblock recently has come from Fred Bauder. If there has even been one legitimate self-unblock between now and whenever the last bad one was before Fred, I would be hesitant to remove this permission. -- Ajraddatz (talk) 16:38, 23 November 2018 (UTC)
  • @Ajraddatz: quarry:query/31445. Of the other 8 self-unblocks since 2017-01-01, 4 are undoing accidental self-blocks, 2 are undoing self-blocks for retirement/wikibreaks, and 2 are undoing self-blocks made without any comment. Anomie⚔ 19:55, 23 November 2018 (UTC)
• Status quo our current policy works fine. One person self-unblocking themselves is not a big issue that we need a large RfC on. Admins occasionally do block and unblock themselves and that's perfectly fine. There's no real need for any sort of technical controls such as removing the ability, because self-unblocks that violate policy happens really rarely, and when it does, no real harm is caused. Galobtter (pingó mió) 17:01, 23 November 2018 (UTC)
• I agree that the status quo works just fine. As a practical matter, when I first became an admin, the first user I blocked was myself, to explore how the tool worked. And, then (after a vaguely amusing thread where I asked for help), I unblocked myself. It's not entirely clear if this proposal is intended to address can (as in, the software allows it), or, may (as in, policy allows it). Ether way, what we've got now needs no modification. -- RoySmith (talk) 17:14, 23 November 2018 (UTC)
• Oppose technical restriction – I oppose any technical restriction on self-unblocking for one reason. That's because the bright line that exists is useful for weeding out bad administrators. All administrators have the ability to unblock themselves, but very few will ever actually use that power. Any administrator that is bewitched by the temptation to use it to try and get out of a block placed by another administrator clearly doesn't deserve the administrator bit. The status quo is, in-and-of-itself, a test of fitness to serve. We trust administrators to be able to use their tools responsibly. If they cannot do so, they should be removed. RGloucester — ☎ 17:15, 23 November 2018 (UTC)
• Status quo – No rationale has been provided for the need to remove the technical ability to unblock yourself as admin. Unblocks in violation of WP:NEVERUNBLOCK can be handled by desysops as it is done right now. --AFBorchert (talk) 17:26, 23 November 2018 (UTC)
• Keep as is Admins should have the technical ability, but (by policy) are generally not permitted to self-unblock (although I can't see why restoring talk page or e-mail, if needed is generally OK). Crouch, Swale (talk) 17:31, 23 November 2018 (UTC)
• Status quo - it's a bit chilly out tonight, I predict snow. Cabayi (talk) 19:46, 23 November 2018 (UTC)
• Status quo - the timing for this is interesting. Old admin accounts are being hacked and blocks to active admins applied. They should certainly have the ability to reverse this trolling. Flare ups like the the that brought this proposal about can be dealt with on an individual basis. MarnetteD|Talk 19:53, 23 November 2018 (UTC)
• Can you explain what problem you think changing this would solve? Natureium (talk) 21:23, 23 November 2018 (UTC)
• No reason to change. What if someone finds an admin's password (two examples in the last 48 hours) and uses a script to block every other admin? Johnuniq (talk) 22:42, 23 November 2018 (UTC)

I assume in such a situation, the fix would be for a developer to do some direct database manipulation to block the rogue user and unblock all the admins. -- RoySmith (talk) 04:37, 24 November 2018 (UTC)

In 2015, when we were doing the batch adminbot blocks for the Orangemoody socking case, it took 14 minutes to block 381 accounts, and it was blocking based on an account list posted on enwiki; it's my understanding that blocking was throttled to 30/min. I'm pretty sure if we suddenly saw 30 accounts a minute being blocked, someone would be able to get it globally locked within the first 3-5 minutes of action, and I'm also sure that blocking the bad-guy account would disrupt the process, as well. But it wouldn't take very long to unblock, especially if someone had an adminbot handy. Risker (talk) 05:18, 24 November 2018 (UTC)

With Version B, if every other admin were blocked, a bureaucrat could unblock themselves and then desysop the rogue/compromised admin account and unblock the previously blocked admin. ^Semi_Hypercube ✎ 18:06, 24 November 2018 (UTC)

@SemiHypercube: in version B the desysop wouldn't even have to happen, the bad admin could just be blocked (since they wouldn't be able to unblock themselves). — xaosflux ^Talk 18:12, 24 November 2018 (UTC)

@Xaosflux: Which could also mean that if they were fast enough, any admin could block and stop the rogue/compromised admin, rather than only a bureaucrat. ^Semi_Hypercube ✎ 18:16, 24 November 2018 (UTC)

• Status quo: This proposal is an engraved invitation to a Denial-of-service attack. --Guy Macon (talk) 06:30, 24 November 2018 (UTC)
• Status quo - The number of appropriate self-unblocks (i.e. for self-blocks) far exceeds the number of inappropriate ones. This hasn't really been a serious issue for years, and I've long considered not self-unblocking to be like a cardinal rule of being an administrator, to the extent that it begs the question: if we can't trust an administrator not to unblock themselves, then why should we trust that user to be an administrator at all? Mz7 (talk) 00:09, 25 November 2018 (UTC)

  Striking my comment in light of the new information below – apparently removing (unblockself) from the administrator package will not prevent the administrators from unblocking themselves if they were the ones who blocked themselves. I will have to think this over some more, but that takes care of the main issue I had with Versions A and B of the proposal. Mz7 (talk) 03:12, 26 November 2018 (UTC)

• Version A The commonly cited objection of accidental self-block isn't a real issue given Anomie provided statistics above. Worry over a rogue admin account blocking every other (active) admin accounts and presumingly then being able to go on a wrecking spree unchecked is perhaps misguided. When there's a rogue admin account, we already require either crat desysop or outside assistance (steward lock) to stop them precisely because such an account is able to self unblock. Removing unblockself means a rogue admin account can be stopped immediately by another admin blocking them. In the scenario of a rogue admin account blocking every other admin, given the throttle mentioned by Risker, the rogue account would be locked long before they're able to finish what they're doing. -- KTC (talk) 02:03, 25 November 2018 (UTC)
• Question Can a blocked admin account block someone else? -- KTC (talk) 02:03, 25 November 2018 (UTC)

  @KTC: no, the only thing a blocked admin can do that a normal blocked editor can not do is unblock themselves. — xaosflux ^Talk 02:07, 25 November 2018 (UTC)

  @Xaosflux: Thanks for the response, but are you sure? I just remembered someone admining through a block back in 2015 by doing revision deletion on a page while they were blocked (and was desysop as a result partly because of that). -- KTC (talk) 02:30, 25 November 2018 (UTC)

  I think there are a few random things that are still allowed even if you are blocked. I did go over to testwiki/test2wiki (where I am an admin), blocked myself, and found that I could not block anyone else. --Rschen7754 02:34, 25 November 2018 (UTC)

  @Rschen7754:, @KTC:, I was wrong - there are still some things blocked admins can do. I'm not going to publish a whole list here. — xaosflux ^Talk 02:46, 25 November 2018 (UTC)

  Notably "edit" and "block users" are not some of them. — xaosflux ^Talk 02:48, 25 November 2018 (UTC)

  @KTC: revision delete is not one of them, however viewdeleted is. — xaosflux ^Talk 02:51, 25 November 2018 (UTC)

• Status quo There is a policy restricting it. ―Abelmoschus Esculentus ^{talk / contribs} 03:02, 25 November 2018 (UTC)

  @Abelmoschus Esculentus: I don't know how much we have to say this: this is for the technical ability of admins to self-unblock, not policy. ^Semi_Hypercube ✎ 03:59, 25 November 2018 (UTC)

@SemiHypercube: I am saying that since there is a policy restricting it, there’s no need to have technical restrictions on it. Also, what if the situation mentioned by Johnuniq really happens? Sorry for not making it clear. ―Abelmoschus Esculentus ^{talk / contribs} 04:14, 25 November 2018 (UTC)

self-unblock (when blocked by other sysop) - desysop ―Abelmoschus Esculentus ^{talk / contribs} 04:18, 25 November 2018 (UTC)

• Status quo It might seem like a good idea at first, but we have a lot of test blocks and accidental block to oneself, as well as when rouge admins block legit ones. Even when problems occur, they can get resolved by other means (ArbCom, desysoping) quite quickly. funplussmart (talk) 05:14, 25 November 2018 (UTC)
• Version A solves a number of problems both in general situations (two admins wheel warring for example), but also, more so IMHO, in the security of accounts, one block by any admin immediately stops a compromised account. As well as for compromised accounts this will also likely remove the necessity for emergency desysops since a normal enforcement method, used on every other account, will actually be able to stop an admin account. Stewards have shown in the latest series of compromised admin accounts that they are very able to respond quickly if there is a problem. Regarding the comments about blocking oneself unintentionally, there's already a warning which appears when trying to do that, so if there's a concern that people will miss that it can be made more obvious. Callanecc (talk • contribs • logs) 07:48, 25 November 2018 (UTC)
  • Just coming back to reinforce my support for version A after I found that admins even without the selfunblock permission can still remove blocks they imposed on their own account. Callanecc (talk • contribs • logs) 06:42, 26 November 2018 (UTC)
• Status quo too many problems. feminist (talk) 08:10, 25 November 2018 (UTC)
• (Non-administrator comment) Is it possible to disallow unblocking oneself, but allow admin X to unblock themself if admin X is the one who blocked themself? (I am not watching this page, so please ping me if you want my attention.) wumbolo ^^^ 10:22, 25 November 2018 (UTC)

  Not as currently implemented in the software. It would require asking the developer community to work on that for us, and that seems like a nontrivial task. But we could always ask, I suppose. Mz7 (talk) 11:37, 25 November 2018 (UTC)

  @Wumbolo: According to John Cline and Ajraddatz below, this is apparently precisely the functionality that removing (unblockself) would result in. So yes, it is possible, and if this RfC is successful, that is the functionality that we will get. Mz7 (talk) 03:12, 26 November 2018 (UTC)

• Very bad use of developer resources. Malicious self-unblocks happen maybe once every decade. They are grounds for immediate loss of sysop access. On the other hand, admins accidentally block themselves fairly often. It’s easy to click the wrong link. This is a trivial block that they are allowed to undo. Don’t waste real peoples time trying to solve a problem that almost never happens, and create a new problem that happens more frequently. Jehochman ^Talk 12:35, 25 November 2018 (UTC)

  Resources wise, we're talking seconds to add or remove a right to a userground. Malicious self-unblocks once every decade, did you miss the 3 compromised admin accounts in the last 3 days doing it? Accidental self-block unblock, 4 in last 2 years. It's really not as commons as everyone think it is, or maybe as it used to be. -- KTC (talk) 18:50, 25 November 2018 (UTC)

Depiction of Wikimedia Foundation destroying Wikipedia with Visual Editor, Flow, and Mobile App instead of making obvious but boring improvements to what we have.

• One would think that an organization that spends many millions of dollars on software development would have long ago changed the wiki software so that if you click the wrong link and block yourself a big red ARE YOU SURE??? would come up with the user having to type in the three letters "yes" (not just "y") to continue. Alas, we have a culture where making the software elegant, easy to use and generally excellent is not a priority, and administrators are especially prone to putting up with software that is OK but not great. This attitude is not new: during the Civil War cannonballs were slow enough so that if you noticed one coming at you you had time to duck. The problem was that it wasn't considered manly to duck. --Guy Macon (talk) 19:37, 25 November 2018 (UTC)

• Adding that big red ARE YOU SURE??? would be a good thing to combine with taking away the ability to unblock anyone while you are yourself blocked. I'm just saying. --Guy Macon (talk) 19:44, 25 November 2018 (UTC)

• It alreadys does, in red, right above the field for entering who to block. -- KTC (talk) 19:56, 25 November 2018 (UTC)

Does it make you type the word "yes" (not just "y" or clicking on a button)? It is a well known effect in human engineering that people who see a lot of "are you sure?" warnings tend to click the OK button or hit the yes key on autopilot no matter what the text of the message is. making them type something different for the rare warnings is a proven method of avoiding such errors. --Guy Macon (talk)

@Guy Macon: If you try to block your self you get 2 differences: (1) A big red warning (2) You have to check an extra "confirm block" box before proceeding. — xaosflux ^Talk 17:43, 26 November 2018 (UTC)

(ec) Anyone capable of accidentally blocking themselves after that lacks the reading skills necessary for adminship. DuncanHill (talk) 17:48, 26 November 2018 (UTC)

And we could change that to "Confirm self-block - you will not be able to undo this!" or the like. — xaosflux ^Talk 17:46, 26 November 2018 (UTC)

Note that even without unblockself admins can still remove self-imposed blocks - tested and confirmed with technical staff. -- Ajraddatz (talk) 17:51, 26 November 2018 (UTC)

Yeah, I should clarify—in case my comment directly above yours was confusing—that revoking the ability to unblock oneself is a solution that has indeed already been implemented, and it would be trivial work to remove that right from administrators, and that is what this discussion is about. What hasn't been implemented is "to disallow unblocking oneself, but allow admin X to unblock themself if admin X is the one who blocked themself". Mz7 (talk) 20:39, 25 November 2018 (UTC)

Mz7, this modification from 2011 ostensibly allows an admin to remove a self imposed block even if ever the unblockself permission is removed from the admin bundle. Whether it is still valid or not, I do not know.--John Cline (talk) 02:01, 26 November 2018 (UTC)

Fascinating. I just tested and it is still valid; removing the unblockself permission will not prevent admins from unblocking themselves unless this is changed. -- Ajraddatz (talk) 02:09, 26 November 2018 (UTC)

@Ajraddatz and John Cline: Wait... really? This is a game-changer, actually. If this had been advertised from the start of the RfC, I think it would have changed some minds. I will go and strike my comments above as I rethink. Mz7 (talk) 03:14, 26 November 2018 (UTC)

@Ajraddatz and John Cline: fix ping Mz7 (talk) 03:14, 26 November 2018 (UTC)

Yep, just did some more tests to confirm. On the beta cluster, I created a user group with only the block right and not unblockself. My test account was able to block itself and remove the self-imposed block. When I blocked my test account with my main account, my test account was unable to unblock itself. Tl;dr if we remove the unblockself permission from admins here they would still be able to remove self-imposed blocks. -- Ajraddatz (talk) 04:21, 26 November 2018 (UTC)

• Support Version A. The rest of us can't unblock ourselves if an admin has a moment's idiocy, I don't see why, in the case of a self-block, the person who had the moment's idiocy should be allowed to unblock themselves, and if they've been blocked by someone else then they should follow the same procedures to request an unblock as the rest of us. DuncanHill (talk) 19:42, 25 November 2018 (UTC)
• Comment would it be possible to add a ten-minute "cooldown" before the unblock can occur? The recent hijacking-vandalism has involved multiple admin-self-unblocks, and a ten-minute cooldown would be a benefit for all of them. power~enwiki (π, ν) 19:50, 25 November 2018 (UTC)
• Support Version A. Administrators should not be more equal than others. Even in the event of a mistake and blocking themselves, the administrators are enough of a clique they can contact another administrator and at worst suffer the indignity of being blocked for a few minutes. How many of them already have multiple accounts, much less the email addresses of some of their cohorts? Or at worst, sign in as an IP. If someone is blocked for cause, there should be enough documentation that anybody of the stature of an administrator should be able to make a rational decision as to whether the block is for cause or an accident. Trackinfo (talk) 20:00, 25 November 2018 (UTC)

@Trackinfo: "the administrators are enough of a clique" Is this implying there's a cabal? Not criticism of your reasoning, just what I'm wondering. ^Semi_Hypercube ✎ 01:50, 26 November 2018 (UTC)

• Support A. How many of you remember the Robdurbar incident? An admin went rogue, blocking a collection of people and deleting a bunch of important pages, and it took a good while to find anyone able to desysop him. Three times he was blocked, and three times he unblocked himself — there was no way to stop him from continuing his rampage until he lost sysop rights. From a technical perspective, any admin should be able to stop any other admin and any bureaucrat from acting until someone else intervenes: we're too big for a single user to be able to block everyone else without getting noticed and stopped (and we also have the stewards who could intervene), and in the event of a rogue admin, there will be no difficulty whatsoever in unblocking all the wrongly-blocked people once the rogue has been stopped. Note that I've three times attempted a self-unblock: once after blocking myself, once after someone else blocked me (I requested a block to do some testing, so I unblocked once the test was complete), and once after autoblocking myself via blocking my alt account (I had to request assistance for that one). In the final situation, I had to wait only ten minutes despite some confusing technical issues; if you can demonstrate that a compromised account has blocked you, the unblock should be nice and quick, and you can use the opportunity to say "User:Soandso is compromised or rogue and should be blocked before you unblock me" so others are aware of the situation. Nyttend (talk) 22:21, 25 November 2018 (UTC)
• Status quo The problem this purports to solve is small conpared to the problem that it might create.S Philbrick(Talk) 00:12, 26 November 2018 (UTC)
• Version A. If there is a disagreement or issue as to why, like everybody else, a discussion can be had at an appropriate place to work out the next step. There is no emergency as to why an admin will need to unblock themselves to do something. This ability IMO is strange and prone to disruption; the ability of an admin to go on a short break without admin tools does not justify it. --Tom (LT) (talk) 00:31, 26 November 2018 (UTC)
• Version B. If a crat account goes haywire, it would be very difficult to deal with, but the difficulty is only increased marginally with version B. Furthermore, version B prevents 'Crats from being locked out by a hijacked admin account, and hence unable to unblock admins, or indeed perform a desysop (probably? I don't know for sure). The status quo allows havoc until a desysop occurs - in one recent case, version B would have reduced the vandalism of the main page to one occurrence, rather than two. Of course, a legitimate alternative is to allow blocked admins to unblock users other than themselves, but in the context of recent compromised accounts, that's unlikely to prevent the attacks, since multiple admin accounts have been hijacked. And there's the old idea of allowing sacrificial desysopping by admins, which I would suggest is probably a better solution than any of the current options. ∰Bellezzasolo✡ Discuss 01:11, 26 November 2018 (UTC)

• Bellezzasolo, I've supported that in the past, and I'd support it again if it were proposed; it would resolve the issue at hand here without affecting people who have good reason to unblock themselves uncontroversially. I just doubt that such a proposal would go anywhere. Nyttend (talk) 01:42, 26 November 2018 (UTC)

• Someone wrote an extension to do that some time ago. Since stewards have a ~2 minute response time, and compromised accounts should typically be locked before they are desysopped, I'd say that there would be limited benefit to actually implementing this extension. -- Ajraddatz (talk) 01:49, 26 November 2018 (UTC)

• @Ajraddatz: WP:BEANS and all that, but a compromised crat account plus an automated script might take a concerted effort of stewards to solve. Actually, that's something that none of the proposals here address, I've emailed the beans. ∰Bellezzasolo✡ Discuss 14:49, 26 November 2018 (UTC)

• Yes, we can all think of doomsday scenarios. But the better approach is to focus on attacks that are likely to happen and reduce the risk that they do. Version A helps in both a doomsday blockbot scenario and the previously-seen compromise attacks, since any "good" admin can stop the abuse immediately without steward intervention. -- Ajraddatz (talk) 16:02, 26 November 2018 (UTC)

• I strongly disagree. We should make Wikipedia resistant to attacks that haven't happened yet. Ignoring a known vulnerability because nobody has exploited it yet is a classic indicator that idiots are in charge of security. (To be clear, I am talking about those in charge of security, not anyone here. We aren't expected to know about such things. Also, the WMF people in charge iof security appear to be doing an excellent job.) "That would be really easy to correct if it ever happened and a lot of work to prevent" is a good argument for ignoring a known threat, but "nobody has tried that one yet" is not. --Guy Macon (talk) 17:49, 26 November 2018 (UTC)

• Version B - self-unblocks only add fuel to the drama fire. (Ideally, would support version A, but there might be a security risk with blocking CRATs). Renata (talk) 02:31, 26 November 2018 (UTC)
  • @Renata3: What would the security risk be? Stewards have shown that they're very quick to respond to a compromised account. Having a compromised crat account which can remove userrights as well as everything else is worse than an admin account. Callanecc (talk • contribs • logs) 07:15, 26 November 2018 (UTC)
    • There are certain hours of the day (at least when I was a global sysop looking for a steward) when there are fewer around. Won't say what those are onwiki, of course. Personally, I would like to see self-unblock restricted to a group like CU/OS or even interface admin, as those groups are pragmatically required to take extra precautions with their accounts. A lot of our bureaucrats are sadly as inactive as the admins who are getting their accounts compromised. --Rschen7754 07:41, 26 November 2018 (UTC)
• Status quo There is no demonstrated need for a change; the current situation works fine. --Jayron32 03:15, 26 November 2018 (UTC)
• Version A basically per Nyttend -FASTILY 05:54, 26 November 2018 (UTC)
• Version A. If an admin blocks every other admin, that's what we have stewards for (who all have global unblockself permissions). There is no security problem here. Kevin (aka L235 · t · c) 06:04, 26 November 2018 (UTC)
• Version A because there is no reason for administrators on enwiki to have this right. ~ ToBeFree (talk) 07:13, 26 November 2018 (UTC)
• None of the above I don't really like any of these options. With option A, yes, stewards could self-unblock if everyone was desysopped, but the response time to clean up the damage would be significant, especially if it is a time of day where stewards are not that active. With option B, I'd rather that it wasn't the bureaucrats, as many are sadly as inactive as the admins who are getting their accounts compromised. I'd rather have the self-unblock right be held by CU/OS or even interface admin since they already have to take precautions with their accounts. If I had to go with any I'd say option C, but of course that has its flaws too. --Rschen7754 07:46, 26 November 2018 (UTC)

  @Rschen7754: So basically you're saying a tighter version of version B, right? I mean, that's not a bad idea either, while bureaucrats can desysop it wouldn't be needed with Version A or B if this was just a rogue/compromised admin account, since blocking them would stop since they couldn't self-unblock. ^Semi_Hypercube ✎ 14:15, 26 November 2018 (UTC)

  It would be kinda cool if unblockself could only be used by admins with 2FA enabled. Now that the previous security hole has been patched, it is nearly impossible that a 2FA-enabled account could be compromised. So admins that hate 2FA could continue to not use it, but if their account gets compromised they could be stopped by someone with a safer account. -- Ajraddatz (talk) 16:01, 26 November 2018 (UTC)

• Status quo: It's interesting to note that this RfC meets four out of five of Goode and Ben-Yehuda's characteristics for a moral panic. I bet that after some time has passed, it'll end up meeting all five of them.  Spintendo  08:12, 26 November 2018 (UTC)
• Version A -- No legitimate reason to unblock yourself. I would honestly go further and remove an admin's technical ability to block themselves as well. -- Dolotta (talk) 17:04, 26 November 2018 (UTC)
• Version A - Ofcourse admins have blocked themselves accidentally in the past (or have done so as a test) however both are extremely rare these days (those that block themselves usually ask to be blocked and unblocked) so I don't really see a reason as such to allow self-unblocking. –Davey2010^Talk 18:07, 26 November 2018 (UTC)

  @Davey2010: It has been noted above that even if the (unblockself) permission were removed, admins could self-unblock for self-blocks. ^Semi_Hypercube ✎ 18:15, 26 November 2018 (UTC)

• Status quo. @Nyttend: as one of the affected accounts of the robdurbar incident I still feel, that the DOS affect of the other options is worse that the dangers of leaving the technical abilities as they are. Also since then we have given crats the ability to desysop. Back then we had to wait for a steward. Agathoclea (talk) 18:27, 26 November 2018 (UTC)

• Agathoclea, while I disagree with your conclusion, I have to respect it more strongly because you were involved in the incident. Just one question: DOS affect? If you mean "denial of service", I'm unclear how that fits, so more details would help. Nyttend (talk) 01:57, 27 November 2018 (UTC)

@Nyttend: while this is a moo point now, It allows for a wiki to be shut down if the assailant is fast enaugh and hits the active admins first. Back in the day, the suggestion was made that blocking an admin should result in a automatic desysop. That would stop a rampage in its tracks. the auto de-sysop would be quickly reversed in obvious cases. In not so obvious ARBCOM would decide which of the two gets his bit back Agathoclea (talk) 08:52, 27 November 2018 (UTC)

• Version A I'm pretty sure version A is going to happen soon regardless of the outcome of this discussion. It's not necessarily permanent, though. Right now, accounts are being compromised left and right, a number of them are sysops. Drastic times call for drastic measures. Sometimes every second counts, for example when graphic pornography is placed on the Main Page. The time it takes to go to IRC and type !steward please lock <user> and wait for action is just too long. — MusikAnimal ^talk 18:48, 26 November 2018 (UTC)
• Status quo - Wrong approach to dealing with compromised administrator accounts; better to elect a few more Bureaucrats who are highly active and in various time zones so that emergency desysops are less of a worry. — Godsy ^(TALK_CONT) 20:12, 26 November 2018 (UTC)

  @Godsy: "better to elect a few more Bureaucrats" If you want to try reviving RfB, then go right ahead. Try to find an admin who is up for it. ^Semi_Hypercube ✎ 20:26, 26 November 2018 (UTC)

• These options all have problems. Perhaps a solution could be for blocked admins to be able to block other admins and for admins to be unable to unblock themselves. --Yair rand (talk) 20:28, 26 November 2018 (UTC)

• User:Yair rand, I'm not quite clear what you mean. Currently, you can't block someone if you're currently subject to a block, at least here at Wikipedia (is it different at Wiktionary?). Are you proposing that blocked admins be given this permission (and if so, why?), or do you mean something else? Nyttend (talk) 02:00, 27 November 2018 (UTC)

  @Nyttend: That is what I'm proposing, yes. In case of a rogue admin, the priority would be to stop damage from being done as soon as possible. If self-unblocking is allowed, blocking can't stop a rogue admin. If self-unblocking is not allowed and blocked admins can't block other admins, the rogue admin could preemptively block the other admins and remain as the only unblocked admin. If self-unblocking is not allowed and blocked admins can block other admins, any admin can block the rogue admin immediately and shut down all further actions other than the possibility of blocking the remaining admins. On further thought, however, I'm not sure that would be an improvement: All admins being temporarily unable to fix things up (like vandalism) until a steward or bureaucrat shows up might actually be worse than the alternatives... I am unsure. --Yair rand (talk) 05:49, 27 November 2018 (UTC)

• Not of fan of anything out there right now, so status quo for me. For example, if you have a self block, I'm fine with a self-unblock. If an account is compromised, or appears to be, then de-sysop until the account is back under control. Headbomb {t · c · p · b} 20:48, 26 November 2018 (UTC)

• Version A If an administrator gets blocked, it is probably for a good reason. —Eli355 (talk • contribs) 00:53, 27 November 2018 (UTC)

• Per phab:T150826 and Special:ListGroupRights, sysops and bureaucrats no longer have unblockself. ~ Amory (u • t • c) 02:03, 27 November 2018 (UTC)

• At that ticket, Ajraddatz said "self-imposed blocks can always be self-removed". I've just blocked and unblocked myself, so I can confirm that this is still the case. Could someone block me (and then ping me) so we can see whether the new settings are live yet? Please be careful to disable autoblock and enable talk-page access, of course :-) Nyttend (talk) 02:12, 27 November 2018 (UTC)

• Nyttend Done ;) ~ Amory (u • t • c) 02:16, 27 November 2018 (UTC)

• Already did these tests and reported back a few comments up, but that's ok, you guys can test it out again if you want ;-) -- Ajraddatz (talk) 02:24, 27 November 2018 (UTC)

• Ah, sorry, I guess I didn't read as much as I thought I had. The test went as expected; when I tried to unblock myself, I got a new message:

  You are not allowed to unblock yourself.
  
  Return to Main Page.

  Nyttend (talk) 02:27, 27 November 2018 (UTC)
• Considering that the devs have gone and removed the problem for us, should this RfC be closed then? — AfroThundr ^{(u · t · c)} 02:33, 27 November 2018 (UTC)

• I think so. I wish they'd waited for this discussion to close (someone mentioned this discussion, so they were aware of it), but since they didn't, there's no point in continuing. The only possible change would be a consensus to request the return of unblockself, and since they removed it on their own accord, I doubt they'd grant a request to revert themselves. Nyttend (talk) 02:35, 27 November 2018 (UTC)

• I say let the RfC play out. I for one can't fucking believe this was done behind the scenes without community consent. I find it hard to believe that the devs can't see the double-edged blade staring directly back at them us. If the inability to self-unblock can be used as a weapon against these rogue/compromised/abusive accounts, it can be used by these accounts, against us. I really don't think "Robdurbar" would have attacked the main page if he knew it would be over the second he did so. He may have instead strategized the best way to evade a block for as long as possible while inflicting as much damage as possible. This is a big project, with plenty of dark corners. It's really not hard for me to brainstorm creative ways to go rogue without being immediately blocked. I'm sure whoever is behind the compromised admin accounts is not terribly stupid either. There's not that many admins active at any given time. If we're lucky, there will be a crat or steward around to perform an emergency desysop when needed. Some nonsensical IP user can commit blatant anti-Semitic vandalism on an obvious target for that sort of thing, and no one will notice for nearly 48 hours. Or, they can go on an unhinged BLP violating/edit warring spree, while their name sits in a backlogged administrative noticeboard. If IPs can fly under the radar, do you really think that rogue/compromised admins can't get away with it if they really try? We're just giving these people reasons to engage in pre-emptive admin blocking, not to mention stealth sprees, and that can cause far more damage than anyone has ever tried to cause before. Yeah, it sounds like a good idea with no downsides at first, but there's a huge potential for this shit to backfire. Smdh.  Swarm  talk  02:40, 27 November 2018 (UTC)

  Swarm, No point in it now, I guess. FWIW if you're interested in numbers, I've been watching them for a while. On average there are 40-60 admins active on enwiki per hour, and about 500-700 per week. SQL^{Query me!} 02:50, 27 November 2018 (UTC)

  Imagine if you looked at the numbers where you take the body of "active" admins in a given time, weed out the ones who aren't actually working on/involved with the administrative backlog proper, spread them out across every venue where there are outstanding reports or requests for admin action, and then compare the rate of admin work that can be, or is being, completed with that workforce, relative to the rate of new admin work being created. Reports at AIV can sometimes sit for hours. Reports at AN/I, RfPP, PERM, or AN3 can sit for days. There's basically one person who has been handling the histmerge backlog over the years. It doesn't do me much good to know that there's 60 active admins here at any given hour when I'm waiting two or three days for a simple report to get an admin's response. We're not as on top of things as you'd think.  Swarm  talk  03:11, 27 November 2018 (UTC)

  I know we are all very enwiki-centric here but this was also done globally. How about those small projects where there are two or three admins? Block, block, and you have the run of the place until a steward steps in. --Majora (talk) 02:43, 27 November 2018 (UTC)

  For what it's worth, before this change such rogue admin account already had the run of the place until a steward interfere since no blocks can stop them, and their crats don't have the power to desysop. -- KTC (talk) 12:31, 27 November 2018 (UTC)

• Version A – I originally supported maintaining the status quo, but I have been persuaded by two arguments. Firstly, per this 2011 change found by John Cline and confirmed by Ajraddatz above, removing (unblockself) from the administrator toolset will not prevent administrators from unblocking themselves if they were also the one who blocked themselves. Most self-unblocking events on Wikipedia are administrators accidentally blocking themselves, and this proposal, as written, will not hinder administrators' ability to correct such uncontroversial errors. Secondly, per Callanecc above, this proposal would be useful in the event that an administrator account is compromised, which does occur every few years. Currently, the only effective way to stop a compromised administrator account is for a bureaucrat or steward to do an emergency desysop/global lock. The wait time for this can take several minutes, whereas this proposal would shorten the response time by allowing any administrator—not just stewards and bureaucrats—to neutralize the compromised account via a block. As MusikAnimal notes: in such a case, every second counts. Mz7 (talk) 03:12, 27 November 2018 (UTC)
  • Here's why I didn't support this option: what if someone did succeed in running a script to block all (active) admins? We have to weigh the time we save with option A and compare it against the probability of someone succeeding in doing this and the length of time it would take for intervention in that scenario. --Rschen7754 03:55, 27 November 2018 (UTC)

• Version C I basically agree with the latter half of User:Mz7's stricken post (the bit about whether someone who can't be trusted not to self-unblock can be trusted to be an admin, which is basically unrelated to whether self-blocks would be included, although I do applaud the detective work that was apparently involved there), with the addition that it seems to be in only extreme cases where admins get blocked at all (I've seen admins do/say things that would get any experienced non-admin blocked on-site, but with admins a more popular approach seems to be to ask ArbCom to desysop, as though it was taken as a given that if someone does something blockworthy their mop should be taken away first), and admins having the ability to self-unblock would seem to be useful to weed out the really extreme cases. I should also say that one way or the other this question would be better resolved after Wikipedia:Arbitration/Requests/Case/Fred Bauder is resolved, since desysopping someone for abusing an admin tool that has already been removed from all admins is ... well, it serves a function, but still feels kinda silly. Hijiri 88 (聖やや) 07:42, 27 November 2018 (UTC)
• Version D User:Jesse_Viviano's proposal that an admin can sacrifice their bit to desysop another admin.--v/r - TP 16:43, 27 November 2018 (UTC)
• status quo, too rare of a problem to need a special solution. Andrew Lenahan - Starblind 18:03, 27 November 2018 (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.

Nuclear Option

So devs have decided to pull "Option A" on all projects in phab:T150826. Note admins that SELF-block can still self-unblock. In theory if we wanted some local group to be able to 'unblockself' still we could argure for it here on enwiki only (e.g. int-admins, or 'crats, expect to get a lot of pushback if we asked for sysops to have it back). — xaosflux ^Talk 03:42, 27 November 2018 (UTC)

• Please don't try to add this to intadmins. SQL^{Query me!} 03:49, 27 November 2018 (UTC)
• Intadmins should not be elevated beyond their pure technical abilities to edit certain pages. TonyBallioni (talk) 03:55, 27 November 2018 (UTC)
• (edit conflict) No. Unblocking self would be important to smaller wikis, here it's done in minutes by other admins. We are fine here. -- Amanda (aka DQ) 03:56, 27 November 2018 (UTC)
• In order of preference as to who to give unblockself to, it would be "admins that have 2FA enabled," then CU/OS, then arbs (since you would have to create a separate usergroup for them), then bureaucrats (since they don't handle private info and thus might not take precautions on their accounts), then interface admins. I just worry that we might be opening up the door to someone who runs a script and blocks all the admins, at a time of day when stewards are not around. --Rschen7754 04:00, 27 November 2018 (UTC)
  • Striking my first suggestion as I think there is a potential security problem in that, and in giving certain privileges to admins based on whether they have two-factor or not. --Rschen7754 04:14, 27 November 2018 (UTC)
• The config change is quick and easy to make. Think of developer-forced "option A" as a temporary measure until more robust technical solutions are developed. For now, we should accept it. — MusikAnimal ^talk 04:19, 27 November 2018 (UTC)
• I'm somewhat peeved that the devs went ahead and partied like it's 1945 -- the issue was dealt with, the question of how to deal with the ongoing threat was being discussed, and this was sent to all Wikimedia wikis. I think there's some valid points being made on the Phabricator and while I'm partial to option A myself I'm concerned at the trigger-happiness. Best, ProgrammingGeek ^talktome 04:21, 27 November 2018 (UTC)
• We don't have to "do" anything, we can just move along as well. — xaosflux ^Talk 04:24, 27 November 2018 (UTC)
• Leave as is, stewards can still solve the problem if needed. Callanecc (talk • contribs • logs) 07:07, 27 November 2018 (UTC)
• Eek, "Old admin accounts are being hacked and blocks to active admins applied"? Oof. I wonder if a fix for this would be to make it harder to block admin accounts? Somehow... dunno how tho. Anyway, yeah, if admin accounts are being wrongly blocked isn't keeping it easy to unblock themselves called for? Herostratus (talk) 09:48, 27 November 2018 (UTC)
• I would support adding this right to bureaucrats and/or int-admins (but obviously not those who are in both, that would be one person) because having nobody be able to self-unblock seems like a security flaw to me. ^Semi_Hypercube ✎ 12:14, 27 November 2018 (UTC)

  I'd also be fine with having CheckUsers and Oversighters with this right. Basically, kind of version B above. (I would've !voted as that, but I feel like it's a bit rude to !vote in my own proposal) ^Semi_Hypercube ✎ 12:19, 27 November 2018 (UTC)

  What's special about CU/OS? Natureium (talk) 14:38, 27 November 2018 (UTC)

  CUs are mainly the ones dealing with the current spate on compromises, so I guess there's that, but I'm pretty meh about it either way. Hardcore opposed to IAdmins having it as it's literally just a flag that any admin who requests at BN with a sufficient reason can get and we shouldn't be adding anything to that userright beyond maybe the ability to edit the main page/other security risks. TonyBallioni (talk) 16:36, 27 November 2018 (UTC)

  Also because there is a significant risk of private data being leaked if CU/OS is hacked (even if blocked), so we're already in trouble. --Rschen7754 19:24, 27 November 2018 (UTC)

  Those are reasons that people with a CU flag should be particularly concerned about security (although I've heard the complaints about requiring 2FA for CU/OS several times), but why would it make sense for them to be able to unblock themselves? Natureium (talk) 20:03, 27 November 2018 (UTC)

• Suppose unblockself was a right that could be exchanged as in a changing of the guard per say, and perhaps 5 or 10 admins, coordinated at wp:an were vested with the right at all times after satisfying some form of active acceptance implying a commitment to remain active until at least such time as when another admin similarly accepts the right and commits to the role. It would not be difficult at all to maintain these 5 or 10 in-house go-to admin-guards and such an active rotation would capably foil any script a wannabe rogue could practically devise while ensuring wiki-continuity by en-means. Anyway, that's an old soldier's 2 cents worth of outside the box thought, given with no dividends due. Cheers.--John Cline (talk) 16:32, 27 November 2018 (UTC)

  John Cline: seems unnecessarily complicated, especially when we already have a group of users that are meant to be a highly available global quick-response team. –xeno^talk 16:37, 27 November 2018 (UTC)

  Thank you xeno, I appreciate your reply; in its grounded truth. Considering that I support option A, and that is effectively what we now have, I'd have done better leaving the other changes unpublished. I agree with your regards. That said, I would like it known that I am in full support of the foundation's leadership demonstration in implementing this global change. Bravo.--John Cline (talk) 01:35, 28 November 2018 (UTC)

• I don't see that the ability to unblock oneself has been removed or even decided. It's been my understanding as long as I've been an admin that we can unblock ourselves but it's a really bad idea to do so unless there is an absolute emergency. Jonathunder (talk) 21:58, 27 November 2018 (UTC)

Throttling

Slightly separate to (unblockself), I can't see any rate limits applied to administrators. I'm open to correction on that, but I can't see anything. After all, admins have (noratelimit). More concerning perhaps, should a 'crat account get hijacked, is no throttle on making sysop accounts (or, indeed, 'crat accounts). I'd suggest we have a throttle on administrators blocking other administrators (2/minute?) and a 24 hour cooldown on new bureaucrat accounts before they can user their new rights. WP:BEANS is why the cooldown is necessary, if in doubt email me and I might spill the BEANS. ∰Bellezzasolo✡ Discuss 13:52, 27 November 2018 (UTC)

I'll spill them. It's important that everyone knows and acts with knowledge rather than ignorance. Now that the devs have acted in their infinite wisdom and removed selfunblock, and because there is no rate throttling, at the risk (or outright ignorance) of WP:BEANS, I'm proposing this godawful idea that the next compromised sysop account simply uses the API to mass block all other administrators. Then we're fucked until a staff, dev, or steward comes by. This is a bad bad bad idea and it's going to bite us in the ass really hard.--v/r - TP 14:14, 27 November 2018 (UTC)

@TParis: Not only that, but if they got into a bureaucrat account, they'd be able to create new bureaucrat accounts through the API, and only stewards would be able to desysop them. It would be a bad case of whack-a-mole. But that's a threat even with (selfunblock), because crat accounts are also able to desysop! Only active crats and stewards would be available to fight the hacker. ∰Bellezzasolo✡ Discuss 15:06, 27 November 2018 (UTC)

I'm glad we've given up WP:BEANS, as it is my least favorite essay. Is it ever necessary for a single crat to +/- sysop or crat more than 2 accounts per day? It seems like a pretty strict limit would rarely cause actual problems. Natureium (talk) 15:31, 27 November 2018 (UTC)

At the start of each month, sometimes up to a half-dozen sysops have the perm removed by a crat per WP:INACTIVITY. Otherwise, well, we used to have multiple concurrent RfA's, and it's possible for multiple sysops to return at the same time (pretty nearly happened this week) so still useful if not strictly necessary. ~ Amory (u • t • c) 16:26, 27 November 2018 (UTC)

Ah, I forgot about the inactivity desysoping. That's a good point. Natureium (talk) 16:47, 27 November 2018 (UTC)

@Natureium and Amorymeltzer: We could set the desysop throttle to something high like 20/day or 30/day. That way, although a lot of damage is done, there should still be active admin accounts to block the hacker, and then unblock the crats so they can re-sysop. If we separate +sysop and +crat, you could then have a 5/day throttle for +sysop and 1/day throttle for +crat (I don't see 2 concurrent RfBs in the foreseeable future). The +crat would need a 1 day cooldown on the new account is the main thing, as it stops a malicious script hopping between accounts. ∰Bellezzasolo✡ Discuss 13:49, 28 November 2018 (UTC)

This is pretty painful to read. Under the status quo, someone could already compromise an admin and go on a mass blocking spree, and if another admin was able to block them the compromised admin could just self-unblock. A compromised crat could already go on a desysopping spree, and self-unblock if blocked. In all of these situations, either steward or bureaucrat intervention is already required to stop the abuse. With the removal of unblockself, any admin can put a stop to it, because the compromised admin vandalbot can be blocked by any other admin and cannot undo the block. This is a helpful move, not a harmful one. It gives more power to local admins to stop abuse in situations involving account compromises.

There's also a question of likelihood here. All of the previous compromises would have been stopped earlier without unblockself, and honestly the various doomsday situations you describe would still have the possibility of being stopped earlier since any admin could stop it immediately. Now, I'm not saying that the implementation is without concern - specifically the part of removing unblockself from small wikis too - but I think that the reaction here is honestly quite ridiculous. -- Ajraddatz (talk) 16:44, 27 November 2018 (UTC)

The difference is that we can all unblock ourselves and go right back to cleanup. Once unblockself goes away, a rougue admin can run a script to block 1300 sysop accounts (not hard) and then have free roam of the place. In fact, if hacker were to write the bot well, they'd start by scanning the admin logs for active admins and block those first. Honestly, if you're blowing this scenario off, you haven't really given it due weight.--v/r - TP 16:49, 27 November 2018 (UTC)

And it would be trivial for even a moderately skilled hacker to write the bot that well in advance, since mediawiki is freely available software which they can practice offline. Only in death does duty end (talk) 16:51, 27 November 2018 (UTC)

I'm not blowing it off, I'm saying that it is incredibly unlikely and could be stopped by one admin under the new scheme, whereas it could not be stopped without steward/crat intervention before. The actual clean-up is trivial compared with stopping ongoing damage. A rogue admin cannot instantly block all 1300 sysops, and even if they did (which is incredibly unlikely and no compromise before has involved this) stewards still have a four minute response time, on average, over the last three compromise situations. Bad policy is made by looking only at fringe cases, there needs to be a balance between possible harm and what would help in 100% of the situations that have happened so far. -- Ajraddatz (talk) 16:54, 27 November 2018 (UTC)

I'll also clarify that I wasn't trying to single out your idea as ridiculous: I've seen all sorts of situations explained over the last two days that are very unlikely and would still be better solved without unblockself than with it. The reality is that regardless of unblockself there are still far worse things that the attackers could have done with a compromised admin account, and we're lucky nothing worse has happened. Ensuring that admin accounts are secure is going to be an important consideration moving forward. -- Ajraddatz (talk) 17:04, 27 November 2018 (UTC)

"could be stopped by one admin under the new scheme" I'm trying to tell you that all active sysops could be blocked before anyone even realizes whats happening.--v/r - TP 17:14, 27 November 2018 (UTC)

I know what you think could happen, I'm saying it wouldn't happen that way. Even without rate limits there is a physical limit to how often an action can be processed through the API. Earlier in the year we had to deal with vandalbots using the API, and they couldn't manage more than 60 edits/min. It would take 21 minutes for a bot at that speed to go through the list of 1300 admins. Lets say the attacker made a bot that was 4x faster than that - it would still take 5 minutes to block all admins. During the last compromise, the response time from the first action to first block by an admin was 2 minutes. This is still a better solution than the status quo. And as usual, I'll note two things that people here are ignoring: a) the likelihood that this would happen, since it's never happened before and removing unblockself would have helped in 100% of the past compromises, and b) the fact that there are far worse things that a compromised account could do than block every admin, so if we are dealing with someone who has inside MediaWiki knowledge and a good familiarity with our systems we'd be in trouble for more reasons than a list of blocked admins. -- Ajraddatz (talk) 17:22, 27 November 2018 (UTC)

I'm not entirely sold yet, but I kind of like the idea from the phabricator ticket to allow blocked sysops to block the user who blocked them, i.e. retaliate. It might lead to escalation in the more routine "sysop goes rogue/dumb" scenario, but it would be limited. In the compromised/mass-attack scenario, it would stop the threat of mass-blocking. In either way, basically stop the bleeding and give time to sort it out. Short-circuits the issues with an elegant(ish) solution to uncommon and very uncommon problems. ~ Amory (u • t • c) 17:25, 27 November 2018 (UTC)

@Ajraddatz: SQL did the math. There are about 60 admins here per hour (300 per day/600 overall per week on average). Even with the limit you've given, all admins active on the project within the last hour could be blocked within 1 minute.--v/r - TP 17:32, 27 November 2018 (UTC)

Ok, fair, in which case someone would need to get a steward..... which they would need to do anyway. Again, doomsday scenario, unlikely to happen, far worse things could be done. I'll end by saying that there are also ways of reducing this one theoretical vulnerability and it looks like the devs are going to work on it. -- Ajraddatz (talk) 17:34, 27 November 2018 (UTC)

Amorymeltzer, It would solve the problem, so long as something crazy doesn't happen like 3 admin accounts being compromised at once. But, what are the chances of that happening? SQL^{Query me!} 17:37, 27 November 2018 (UTC)

Maybe I'm crazy, but is there some way we could test this out? Obviously not on enwiki, but setting up some test wiki with 1300 admins and with a similar configuration, and then see how long it takes. --Rschen7754 19:22, 27 November 2018 (UTC)

I'd actually like to do it. I was half tempted to say something like "I could write such a bot in 10 minutes" but I suspected some busybody would accuse me of threatening the 'pedia or going rogue and ask Arbcom to remove my bit over it. It'd help if we could get 1300 psuedo accounts with active log entries being made with a random 60 active during a given hour so that we have an accurate environment.--v/r - TP 20:14, 27 November 2018 (UTC)

Well, I'm not sure if it's needed... as you said above, it would be easy enough to just block the active ones and that would have the same impact. A better use of time would be to help the devs work around this one theoretical abuse angle. -- Ajraddatz (talk) 23:03, 27 November 2018 (UTC)

@SQL: Fair point, but if the attacker is using one or two accounts to bulkblock every sysop and saving the third to vandalize freely, we're no worse off than we were yesterday, and we've forced the attacker to burn two or three logins instead of just one. Obviously the more accounts an attacker has at their disposal the worse/harder it will be, but I'll take the net positive of half a loaf over none any day. ~ Amory (u • t • c) 20:01, 27 November 2018 (UTC)

"Earlier in the year we had to deal with vandalbots using the API, and they couldn't manage more than 60 edits/min." @Ajraddatz: my personal record is 2000 edits in 5 minutes. This is by no means a hard limit, there are several users who managed over 1000+ edits/minute. And if you wanted, you could go faster. Blocking the top 500 admins would take 75 seconds at 400 edits/minute. - Alexis Jazz 05:04, 28 November 2018 (UTC)

And so far my personal best that I have actively noticed was around 181 edits within a minute with TheSandBot, a feat which it has accomplished a few times. --TheSandDoctor ^Talk 21:18, 30 November 2018 (UTC)

Toolforge job-array is designed for running massive parallel math problems but can run massive parallel worker bots. I tried it once but the speed caused problems with disk caches and logging so I backed off but for the right bot it might be extremely fast. -- GreenC 22:04, 30 November 2018 (UTC)

Yeah, I'm not buying this whole "it gives admins more power to stop disruption" angle. It can just as easily be argued that "it gives rogue admins more power to disrupt". If the risk/benefit ratio was the same, fine, whatever, but honestly, what's a harder scenario to deal with, one admin who is able to unblock themselves a few times before they get locked/desysopped, or dozens if not hundreds of admins blocked and unable to unblock themselves before anyone realizes what's going on? Even worse, what's harder to deal with, a rogue admin who knows they can unblock themselves and thus isn't worried about detection, or a rogue admin who knows they can't unblock themselves, thus goes stealth-rogue and does something like delete hundreds of obscure articles with misleading rationales, or modify the protection on hundreds of articles, or something even worse like abusively merging histories, or create vandalism articles with their autopatrolled rights. There's any number of ways to go absolutely fucking nuclear without being immediately detected, and that's what removing the ability to self unblock is going to encourage. It's clear the people who unilaterally made this decision weren't thinking about the potential downsides at all, it was just a rushed, boneheaded move, not to mention a slap in the face to the supposed concept of a volunteer-run project. It's not remotely an uncontentious security improvement as you would have us believe, and it arguably increases the potential for harm.  Swarm  talk  22:17, 27 November 2018 (UTC)

No, it can't be just as easily argued. Removing unblockself earlier would have helped in every single one of the compromise cases that have actually happened across this network of websites since I've been in a position to respond to them, which is going on five years now. You are taking a remote possibility (but still a possibility, I'll give you that) and railing against an otherwise positive security change because of it. I'll also add that attackers are already incentivized to be stealthy, since there is an end point to attacks even with unblockself when the compromised account is locked. I don't think that moving the possibility of stopping an attack sooner than it can currently be stopped (2 minutes instead of 4 minutes in the last case) would cause a significant change of behaviour in the attacker. I'd say that these public discussions about all the possible things someone can do with a compromised admin account are much more likely to cause future problems than removing unblockself from the admin toolkit.

I'm not saying that the possibility should be ignored, and maybe I haven't been very clear on this up until now. I think we should be working with WMF security staff to identify and fix vulnerabilities, not rejecting their efforts outright. Ultimately they are the ones who are subject matter experts in what they do, and should be allowed to make decisions to protect the security of our site, but it should be a collaborative process. I think there's improvements to be made on both sides in that respect. Your own sarcastic comments thanking the WMF for their change are just as unhelpful to that effort as them forcing technical changes without community consultation - they feel like the community is too busy hating the WMF to work with them, and the community feels like the WMF doesn't care. In this particular case, staff are willing to both work towards fixing this vulnerability and allowing projects to opt-in to adding unblockself to the sysop kit with consensus, but feel that removing the permission is a better option to have by default. From the arguments I've heard, that seems fair to me. -- Ajraddatz (talk) 23:03, 27 November 2018 (UTC)

I get it, you like the positive aspects of this change, but you're also just repeatedly rejecting perfectly plausible scenarios in which it can backfire, which is something plenty of people are concerned about by the way, without resolving the actual concerns. The concerns don't just dissipate because you point out that we can stop a rogue account in 2 minutes instead of 4 now. And you're also acting like it's unreasonable to be outraged when the WMF makes a contentious global change to a longstanding status quo, willfully ignoring an ongoing community discussion that clearly shows said change to be controversial at best. I would think that as a Steward, your priority in this situation would be "customer service", but apparently it's to aggressively beat back those of us who dare to question a WMF staff member's decision that quite blatantly contradicts the fundamental principles that supposedly govern us. Chastising us for being "haters", really? The devs won't work with us because we just mindlessly hate the Foundation? What?? Please extend my sincere apologies to the Foundation for hurting their feelings with sarcasm. I should have realized that it's our fault when Foundation staff arbitrarily makes decisions without the community's input, without sufficiently acknowledging the community's concerns, without providing any explanation to the community, and without being accountable to the community. I totally understand how it's retroactively our fault, for using sarcasm, after the fact. You've convinced me that the devs always make the right call, and that we should not waste time critically thinking for ourselves. Academic experts aren't given any special preference here, but the staff are. Got it. Sarcasm aside, when the Foundation does something silly, and people get pissed off about it, it's not a good look to boil it down to "hating the Foundation". I have nothing against the Foundation, I don't know anything about the Foundation and I'm entirely indifferent about the Foundation. But the merits of this "content dispute" itself aside, the Foundation should not be making decisions like this in the midst of an active community discussion, and if they for some reason feel the need to, the responsible parties need to be accountable to the community. It's not unreasonable to call them out for failing in this regard, and it's actually pretty bizarre to see a Steward try and frame that kind of criticism as unreasonable. You just come across as a shill for the Foundation. If you want to actually facilitate a better working relationship between the Foundation and the community, use your weight as a Steward to remind staff not to do things that will very obviously piss people off, like ignoring community discussions, take our concerns seriously, rather than arguing with everything and sweeping dissent under the rug, and take a leadership role in bringing us together.  Swarm  talk  01:56, 28 November 2018 (UTC)

Swarm, do you have any concerns about this change that are not addressed by Gerrit 476080, which allows blocked admins to block the admin who blocked them? -- Tim Starling (talk) 04:38, 28 November 2018 (UTC)

I have not tried to aggressively beat down anyone here; I think that the concerns are overemphasized, that the problems exist with or without unblockself but the benefits only exist without. Responding to that effect is not intended to prevent discourse or criticism, nor has it done that. As to bring the community and staff together, I've tried to do that with this situation, and have been somewhat successful in other places. Here obviously wasn't one of them. -- Ajraddatz (talk) 04:46, 28 November 2018 (UTC) I've thought about this some more, and if I was coming off as obtuse and dismissive then that's probably what was happening - my apologies. I thought I had The Answer^TM here and it was just a matter of explaining it better, but that's probably not the case and even if so I obviously haven't done that. I do think your concern is valid and hope that the patch Tim linked to above will help resolve it. And if Commons was hit with edits that fast I'm probably remembering things wrong at Meta, confirming that this is something deserving of more thought. -- Ajraddatz (talk) 05:36, 28 November 2018 (UTC)

@Tim Starling (WMF): I tend to be biased toward my idea of a solution over others, but I can't say that I can think of a reason why your solution doesn't work.

@Ajraddatz: I appreciate your comments, but you'd still have been my favorite steward after this regardless. I'm guilty of thinking I have The Answer^TM all the time.--v/r - TP 16:48, 28 November 2018 (UTC)

@Tim Starling (WMF): Well, yes, I have articulated concerns in my comments other than the potential for a rogue account mass blocking admins. However, that is a major concern, and allowing a retaliatory mutual block seems like it would be a reasonable countermeasure, even if not perfect. I can accept the fact that the status quo wasn't perfect, and there likely is no 'perfect' way of dealing with this, but the point of contention about WMF staff showing a complete disregard for the community is a bigger issue. Completely unacceptable in any business situation, additionally insulting coming from an NPO towards its own volunteers, and even more so in the context of the precedent that Jimbo set to purportedly let the community govern. If you're going to take a decision out of the community's hands while they're actively discussing something, at least have the decency to be accountable for that. @Ajraddatz: Sorry if I came across as too aggressive towards you as well, I was directing my other frustrations at you, and it wasn't necessary. Best,  Swarm  talk  17:52, 28 November 2018 (UTC)

I know it can be surprising when we change the MediaWiki configuration without community consensus being demonstrated, but that is in fact the usual process, we change configuration details every week. We especially do not consider it necessary to consult with the community before making security-related changes, and this change was recommended by our security team. But in this case, there effectively was consultation, since Brian Wolff indicated that he had read the village pump discussion and taken it into consideration before he uploaded the configuration change to Gerrit. Most village pump comments seemed to focus on the prospect of a compromised admin account using a script to block all other admin accounts, a concern which was of course known to us, as it was the subject of the third comment on the Phabricator task in November 2016 and was also discussed at length on Phabricator this month. In my opinion, there was a need for judgement in weighing up the various concerns. Our judgement was influenced by the current vandal, who appears to be technically unsophisticated, and yet is damaging Wikipedia's reputation by, for example, twice placing a Goatse image on the main page 5 days ago. I think we should first deal with the vandals who are attacking the site right now, and worry about hypothetical technically competent vandals later. As for the precedent Jimbo set, well, it cannot be so easily distilled to a single principle. In the early days when Jimbo was highly active, he didn't tell developers to always defer to community consensus, in fact we were pretty much able to make any change to the software we wanted. This was an era before bureaucrats, stewards, oversighters and checkusers, I took on all those roles by means of shell access. When I introduced the block-by-name feature in September 2003, I established the policy of allowing administrators to unblock themselves with essentially no community consultation. I recall consulting on blocks in general, and in fact the feature was initially disabled on the French Wikipedia due to Anthere's objections, but I brushed off complaints about this detail, because allowing admins to unblock themselves was the simplest thing to code, and as a volunteer I didn't have much time to spend on it. So it's strange to see the status quo defended in such strident tones when it was an arbitrary, unreviewed decision by me in the first place. -- Tim Starling (talk) 23:30, 28 November 2018 (UTC)

I appreciate you taking the time to offer an explanation, I can understand where you're coming from, and I can also understand that you guys can make judgment calls without the community's approval. But, you're still suggesting that you don't even see what the big deal is here. There's a contentious community discussion going on, you guys make a judgment call on your end to handle it unilaterally, and to you, that's the long and short of it. To us, okay, you've unilaterally overridden a community consensus-building process, something we hold sacred, something that no member of the community, regardless of standing, would ever be able to do, and you don't even have the decency to explain to us what you're doing and why, not even to give us the slightest indication that you're listening to the community's concerns, or even that you take the concept of a community-based project seriously, at all. The fact that you find this backlash 'strange' suggests that you don't understand the high level of importance that longstanding precedent, and transparency, and communication, and accountability have here, and it's all just happily arbitrary on your end, that's concerning, because it reveals a large disconnect between the culture at WMF and the culture within the community itself. I don't think the WMF has disdain for the community, but those are the optics you project in situations like this. Not intending to single you out to give you a hard time, but I think you guys can maybe do with a reminder that the community deserves a degree of courtesy in situations where you might be perceived as stepping on its toes.  Swarm  talk  21:27, 29 November 2018 (UTC)

Earlier in this discussion, Ajraddatz wrote:

"Even without rate limits there is a physical limit to how often an action can be processed through the API. Earlier in the year we had to deal with vandalbots using the API, and they couldn't manage more than 60 edits/min. It would take 21 minutes for a bot at that speed to go through the list of 1300 admins."

No policy decision should be made based upon the assumption that the Wikimedia servers won't suddenly become thousands of times faster. All it would take is a decision that certain tasks have the potential to bog down the existing servers and thus should be moved to a dedicated high-speed server for the slowness we are depending upon to vanish.

There may be other reasons to adopt or reject a policy, but this should never be one of them. --Guy Macon (talk) 18:46, 28 November 2018 (UTC)

Fair, and as pointed out above, it is likely that they could already go significantly faster with up to 2,000 actions/minute. -- Ajraddatz (talk) 19:42, 28 November 2018 (UTC)

Blocking the admin who blocked you

Replying to this change that allows a blocked admin to block the admin who blocked them, I see three problems:

1. It allows for messy escalations of disputes between admins. What would have happened in Wikipedia:Arbitration/Requests/Case/Fred Bauder if Fred Bauder, instead of unblocking himself, had blocked Boing! said Zebedee (the admin he was edit warring with)?
2. It still allows for a "stalemate" situation in which all 1300 admins end up blocked. That might be better than some of the doomsday scenarios described above, but it is still very disruptive.
3. It still doesn't prevent the doomsday scenarios described above if two admin accounts are compromised. (First compromised admin blocks all the other admins while second compromised admin wreaks havoc. Second admin could even be scripted to repeatedly and rapidly unblock the first admin.)

Look at it this way. The vandal/hacker has the advantage of time, speed, and stealth. They have lots of time to plan, tweak, and automate, while we have to respond at normal human speed. We have the advantage of numbers and power: there will always be more good admins than compromised admins, and eventually the 'crats will swoop in for the kill. A good solution will take away the hacker's advantage without significantly affecting our day-to-day. A throttle is an obvious answer. Why not throttle the blocking of admins at, say, 1 per 10 seconds. Wouldn't it be be better to end up with 10 or 20 blocked admins than 1300? I'm sure there are other technical alternatives as well if throttling is too difficult. I just don't think this retaliatory block power is the answer. pinging Tim Starling & TParis & Swarm ~Awilley (talk) 18:00, 6 December 2018 (UTC)

Regarding item 1, Fred and BsZ would both be blocked and then... nothing would have happened. Clearly it offers an avenue for retaliation, but it doesn't escalate beyond that. Maybe an issue on small wikis, but not here. As for items 2 and 3, okay it doesn't solve every problem, but it solves some problems without making any others worse. That's a Good Thing to have, regardless of any other remedies/protections put in place. ~ Amory (u • t • c) 20:03, 6 December 2018 (UTC)

Complete auto-archiving of RFPP

Requests for page protection is the venue where editors request protection for pages, and admins review the requests and implement or reject them. It is an important venue for the encyclopedia, and activity there is often reviewed during RfAs. Personally, as someone who feels protection is often over-applied, I am frequently interested in finding out the context in which page protection was originally applied. I imagine that admins looking to protect a previously-protected page are interested in the context of its previous protections. All these purposes are frustrated by the inexplicable fact that RFPP only has a rolling 7-day archive, after which you are left to sift through the page history. I was inspired to come here by my experience finding the RFPP request that resulted in the current protection of International Space Station, and I challenge anyone thinking that the page history is a good enough record to do the same.

I propose that RFPP be archived in a complete fashion. Building retrospective archives would be awesome, but to avoid technical issues this proposal is specifically for the archiving of future requests. Implementation could look a number of different ways, but I think the ideal scenario would replicate the WP:PERM archive (surely a less important thing to archive than RFPP!), where MusikBot sorts completed requests into "Approved" and "Denied" and archives them by date. If I can auto-archive my talk page, and we can archive requests for rollback, then Wikipedia can archive its page protection requests. A2soup (talk) 17:40, 28 November 2018 (UTC)

• Do you know how to access the protection log for a page? You don't have to use the page history, and RfPP requests themselves contain no information that can't be found in the protection log, so I don't see what the point of permanently preserving every single one of them would be.  Swarm  talk  21:34, 28 November 2018 (UTC)

I know very well how to access the protection log. I don't at all agree that RfPP requests contain no information that can't be found in the protection log. Just very cursorily looking at our current RfPP, I see (excerpts):

• Drive-by IP vandalism due to rumors swirling in the college football world right now.
• not sure if full is best but considering ec/compromised accounts are messing around significantly, requesting something a bit stronger.
• The issue should mostly blow over in a month or two, so that period of protection ought to be enough.

All of these are valuable information about the context of the protection that is lost in the log entries. This is not to mention declined protection requests that obviously leave no log entries but may be important to access later. A current example: Declined, they stopped after warning. Please let us know if disruption resumes. A2soup (talk) 21:43, 28 November 2018 (UTC)

Okay. Well, I'll drop a note by WT:RfPP and see if anyone has any issues with this. If not, this can likely just be handled as an uncontroversial technical request.  Swarm  talk  21:35, 29 November 2018 (UTC)

Wow, thanks so much! A2soup (talk) 22:02, 29 November 2018 (UTC)

GlobalFactSyncRE/DBpedia project proposal

DBpedia, which frequently crawls and analyses over 120 Wikipedia language editions, has near complete information about (1) which facts are in infoboxes across all Wikipedias, and (2) where Wikidata is already used in those infoboxes. GlobalFactSyncRE will extract all infobox facts and their references to produce a tool for Wikipedia editors that detects and displays differences across infobox facts in an intelligent way to help sync infoboxes between languages and/or Wikidata. The extracted references will also be used to enhance Wikidata. For more see https://meta.wikimedia.org/wiki/Grants_talk:Project/DBpedia/GlobalFactSyncRE

Please let us know what you think, your opinion is important to us! Thank you! — Preceding unsigned comment added by M1ci (talk • contribs)

Should IPs be barred from turning redirects into articles?

Hello everyone, I am going to propose that redirects should plausibly be expanded into an article by registered users and not by IPs. I've noticed many serial sock puppeteer and even paid editors often use IPs to turn redirects into articles. --Saqib (talk) 15:21, 2 December 2018 (UTC)

• We have been adding lots more restrictions as of late (article creation to autoconfirmed, removal of patroller from autoconfirmed, removal of admin rights to unblock themselves) isn't the page curation enough since that lists redirects converted into article as far as I'm aware (example). Crouch, Swale (talk) 15:30, 2 December 2018 (UTC)
• It would be very consistent with WP:ACREQ Legacypac (talk) 15:42, 2 December 2018 (UTC)

  The concerns about speedy deletion and being bitey don't (generally) apply with redirects, if a redirect is converted into an article and its not fit for inclusion, it can just be changed back to a redirect. Crouch, Swale (talk) 15:50, 2 December 2018 (UTC)

• Do we have some recent examples where this has been an issue? Nosebagbear (talk) 19:34, 3 December 2018 (UTC)
• Do we have recent examples where there wasn't an issue? Jo-Jo Eumerus (talk, contributions) 19:46, 3 December 2018 (UTC)
• I don't know if there are stats on this specifically, but generally it's an extremely low percentage of logged-out editing that turns out to be problematic, like less than 2%. There are stats on that number, but I don't have them at hand. As for ACREQ, a redirect is kind of a predetermination that a title might be expandable to an article at some point, if anyone comes along that wants to bother doing the work. I think we should not impose new restrictions on the very large majority of logged-out users expanding redirects constructively because there are a relatively tiny bunch doing small amounts of harm. A while back we identified an issue with anons hijacking dabs and redirects to get around ACREQ, but we mostly dealt with that. In this case it seems the proposal would bring more harm than benefit. Ivanvector (^Talk/_Edits) 03:52, 4 December 2018 (UTC)

  There's some stats that could be imported from WP:PERENNIAL, actually, but they're about a decade old and based on very small samples. The page gives 76-82% constructive edits from logged-out editors. I know there are better stats than "I picked the most recent 250 IP contribs and judged which among them were constructive" but that's all I can find right now. Ivanvector (^Talk/_Edits) 03:55, 4 December 2018 (UTC)

  I would propose that there should be some kind of a public log that gets updated every time a redirect is retargeted or converted into an article, and indicates which editor or IP carried out the retargeting or conversion. That would give us a quick and useful sense of the scale of this as a problem. If there already is such a log, I'd love to know about it. bd2412 T 04:15, 4 December 2018 (UTC)

  This filter tags redirects being changed into non-redirects. They appear in recent changes as "Tag: Removed redirect". Ivanvector (^Talk/_Edits) 04:20, 4 December 2018 (UTC)

  I see. And this one catches the same, but limited to IPs. Some of these I can immediately see are bad. bd2412 T 04:55, 4 December 2018 (UTC)

• Why? The case has not been made that this is needed. --Jayron32 18:37, 6 December 2018 (UTC)

Removing Facebook tracking parameter from external links

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.

---

Hello all, I'd like to propose that we strip the tracking data from external links that Facebook seems to have added as of October 2018. It looks something like this. This information adds nothing to articles and removing it is in our interest to protect the privacy of our editors and readers. Jon Kolbert (talk) 12:25, 20 November 2018 (UTC)

@Jon Kolbert: do you have any examples of the links are being added? — xaosflux ^Talk 12:30, 20 November 2018 (UTC)

@Xaosflux: This search query shows a few examples of the variety of links being added with this appended referral data. Jon Kolbert (talk) 12:33, 20 November 2018 (UTC)

@Jon Kolbert: I was looking for some actual diffs of the content being added - to see if there is any additional information that we could use to stop it in the first place. Side note, your BRFA has been approved for trial. — xaosflux ^Talk 12:36, 20 November 2018 (UTC)

@Xaosflux: Ah okay, here's a few : Special:Diff/868769592, Special:Diff/868353000, and Special:Diff/866582270. Jon Kolbert (talk) 12:48, 20 November 2018 (UTC)

I have no problem with this, though it reminds me of the bot that was stripping certain parameters from Google (books) links. Was that KolbertBot? Might be better for that bot (whoever's bot) to do that. --Izno (talk) 18:20, 20 November 2018 (UTC)

It might be reasonable to edit filter + warn on attempt to save (not block). --Izno (talk) 18:21, 20 November 2018 (UTC)

@Izno: I'm guessing most editors inserting these have no idea they are doing it, we can set up a 'log' only filter to start tracking these and see where they are coming from. Edit filter warnings don't always play well with mobile editing and I'd rather someone put in a reliable source with this link than just abandon their edit. — xaosflux ^Talk 18:41, 20 November 2018 (UTC)

I'm guessing most editors inserting these have no idea they are doing it 100% agreed, as with most of the garbage that social trackers and websites using any sort of tracking add to URLs. I'm fine with logging too just to get a sense of it--just some thoughts in general--and would regardless support a bot to remove these (under previous precedent for tracking type URL parameters removal). --Izno (talk) 18:45, 20 November 2018 (UTC)

• Sounds a bit like PrimeBOT 17's task. @Primefac: what do you think? — xaosflux ^Talk 18:47, 20 November 2018 (UTC)

  That's the one I was thinking of. --Izno (talk) 18:50, 20 November 2018 (UTC)

The only "anonymizing" that KolbertBot did was change country-specific links to an "international" domain. I recall doing similar edits removing referral data from YouTube links on my personal account, but those weren't automated so I didn't submit a BRFA. Jon Kolbert (talk) 18:55, 20 November 2018 (UTC)

• Yes, Task 17 for my bot does this. The FB tracking isn't part of its remit, but they can be added to the list. I assume that if a consensus here determines that they're good, there shouldn't be an issue. Primefac (talk) 20:26, 20 November 2018 (UTC) (please ping on reply)
• I have unarchived this as we could really use more feedback from the community. SQL^{Query me!} 23:13, 3 December 2018 (UTC)
• We should absolutely remove this data. I agree that many editors probably don't know what this is when they add links. Morgan Leigh | Talk 01:35, 4 December 2018 (UTC)
• Would definitely support removing these, thanks for unarchiving SQL. Seems like PrimeBOT is already the best place for this, so I'd agree it makes most sense to fold this into its purview, especially as this doesn't appear to be an overwhelming issue. ~ Amory (u • t • c) 01:55, 4 December 2018 (UTC)
• Sure, remove it. —TheDJ (talk • contribs) 09:54, 4 December 2018 (UTC)
• Kill them with fire. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:52, 5 December 2018 (UTC)

• Go for it. I was thinking that we had a similar Bot job. (Must have been thinking of PrimeBOT 17.) It's easy to cause this problem if you just cut and paste URLs, and it is hard to detect on long ones. Hawkeye7 (discuss) 00:36, 6 December 2018 (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.

Proposal- Allow song pages on Wikipedia to have lyrics

Should we provide lyrics to songs that have a Wikipedia page? I was thinking we provide, after the lead-in and background/composition/content section, a Lyrics section that provides the full lyrics to the song, retrieved from any one of the multiple lyrics site on the web today? Schoolbus777 (talk) 02:40, 4 December 2018 (UTC)

• No can do. Lyrics are copyrighted. -- RoySmith (talk) 02:45, 4 December 2018 (UTC)

  Generally, lyrics from after 1923 are copyrighted. --Izno (talk) 03:10, 4 December 2018 (UTC)

  True. We have the full lyrics for Jingle Bells, for example. bd2412 T 05:06, 4 December 2018 (UTC)

• We can't include full lyrics. What we can do is provide snippets of the lyrics to the extent that reliable sources quote and discuss those lyrics, and explain what the sources say about them. A good example of this can be found in Sympathy for the Devil. bd2412 T 02:56, 4 December 2018 (UTC)
• Copyright restricts this but where discussed by RS and where copyright is not a problem, on a case by case basis it is ok. Legacypac (talk) 05:24, 4 December 2018 (UTC)
• No for the most part, since lyrics to songs published after 1923 are often copyrighted. ^Semi_Hypercube ✎ 21:58, 4 December 2018 (UTC)
• Comment I would say, as a general rule, it's not appropriate to provide full lyrics even when copyright is not a problem. That's more what Wikisource is for than Wikipedia. That said, I don't see any need for a blanket rule against it. --Trovatore (talk) 23:27, 4 December 2018 (UTC)
• Comment Apply established policy. For national anthems, for example, lyrics are generally included, and are not subject to copyright. ∰Bellezzasolo✡ Discuss 23:32, 4 December 2018 (UTC)

  and are not subject to copyright Not particularly true. --Izno (talk) 05:06, 5 December 2018 (UTC)

  Could we have an example of a national anthem under copyright? Specific performances of a national anthem, sure, those are copyright but the closest I'm seeing to any legal restrictions is that some countries make parodies of their national anthem illegal. Ian.thomson (talk) 17:23, 6 December 2018 (UTC)

  If the copyright hasn't expired because of age, and the country has passed no special legislation passing the song into the public domain as a national symbol, then a national anthem is copyrighted like any other musical work. As an example, the Swiss National Anthem was updated only three years ago and rewritten by a living person. GMG^talk 17:35, 6 December 2018 (UTC)

• Lyrics for songs that are out-of-copyright should go on Wikisource, with a link to them in the article. Short extracts can be quoted on arcticles, to illustrate points being discussed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:57, 5 December 2018 (UTC)
• Comment I understand your points regarding Wikisource and copyrights. Thank you for responding to my proposal!Schoolbus777 (talk) 01:09, 6 December 2018 (UTC)
• Question I'm aware that lyrics are copyrighted, but why are there so many lyric websites on the Internet at large? Surely they're violating copyright by publishing them, and are probably not paying any sort of royalties. — Frεcklεfσσt | Talk 16:39, 6 December 2018 (UTC)

  Comment Yes, Frecklefoot, they mostly are infringing copyright. Wikipedia doesn't do that. --ColinFine (talk) 16:42, 6 December 2018 (UTC)

  In theory, it is possible that sites like Genius and YouTube have purchased an ASCAP and/or BMI license, which is what radio stations and clubs have in order to be able to play copyright-protected music. I see no reason why such a license would not also permit republication of the lyrics. For the most part, however, lyrics-republishing sites seem a bit dodgy. Wikipedia can't republish lyrics subject to a license, because then our own articles could not be freely licensed. I think we should expand Wikipedia:Lyrics and poetry to provide a more thorough guideline specifying, both legally and stylistically, when and how it is appropriate to present portions of song lyrics. bd2412 T 16:51, 6 December 2018 (UTC)

  Not just theory; as you can see from the Genius article, it acquired licenses in 2014. As I understand it (and mentioned in the cited New York Times article), the music publishers started cracking down at that time. LyricWiki, for example, was acquired by Wikia and entered a licensing agreement with Gracenote. (On a side note, there are lots of different rights in play. As I recall, radio stations pay for a license to perform a recording; this covers the rights for the lyrics, the music, the specific recording, and in some countries, the performers who were recorded. It wouldn't allow for publication of the lyrics themselves.)

  Regarding YouTube, I imagine it doesn't worry as much about lyrics as the actual audio and video. YouTube has its content ID program, where it scans uploads looking for copyrighted material, and blanking out audio for unlicensed music, or blocking the video entirely. Some music publishers opt to allow the uploaded video in exchange for getting a cut of the advertising revenue. isaacl (talk) 18:29, 6 December 2018 (UTC)

  After exerting no real effort for all of two minutes to find the WHOIS data for lyrics sites, the only one I nailed down was Panama, which has a reputation for not being especially strict on copyright and has a nominal GDP per capita about a quarter of the US's. Whoever set up the site I was looking at could be quite well off locally but still well under what any record company would consider worthwhile to sue for lost royalties. They also make a "fair use" claim that wouldn't hold up in a US court but I could well see a non-US court accepting as being US law. And this is all assuming that it's not just a shell company running through Panama. Ian.thomson (talk) 17:23, 6 December 2018 (UTC)

• No Even ignoring the copyright issue, printing full lyrics of songs is outside of what Wikipedia should do in its articles anyways. It isn't really the realm of Wikipedia, which should have encyclopedia articles and not merely be lyrics. Wikisource would be more suited for this. On top of that, add the copyright issues, and that's a double "hell no". --Jayron32 18:36, 6 December 2018 (UTC)
• A big fat no for the most part. This is Wikipedia, not Wikisource. Unless the lyrics in question is needed for commentary, e.g. fluff about why is it impactful or controversial, that is. Blake Gripling (talk) 09:32, 7 December 2018 (UTC)

Proposal: Pending changes for reference desks, admin requests and other areas.

This may seem like feeding the troll or something along the lines of pre-emptive protection, but wouldn't it hurt to place them under pending changes protection to keep the flood of trolls from disrupting the normal flow of things? Of course, semi-protecting them indefinitely wouldn't cut it as there may be anonymous users who would like to ask a legitimate question or two, but there are those who have a gross sense of schadenfreude and delight at creating drama 4chan or Dramatica-style. Blake Gripling (talk) 09:35, 7 December 2018 (UTC)

No, it would be pointless because his shit will still be in the history until we rev-delete it, and also no because the nature of his attacks is to rapidly hit the desks over and over until they are fully protected. PC stops exactly none of that. --Jayron32 15:06, 7 December 2018 (UTC)

Additionally, between the high level of his activity and the high inherent activity level of these pages, PC becomes rapidly unworkable as it is exponentially more complicated to keep good edits and remove bad ones as they get inter-mixed in the pending queue. Nosebagbear (talk) 19:24, 7 December 2018 (UTC)