Open main menu

Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab Miscellaneous 

New ideas and proposals are discussed here. Before submitting:

« Older discussions, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155

Contents

Time to incubate the substubsEdit

NOT DONE:
I think everyone here appreciates that Dr. Blofeld is trying to remedy an issue they perceive with their own work. However, in the weeks this has been open a consensus has emerged that any mainspace content is better than hiding it away in draft or user space (The article incubator having been closed for some years now) He is of course still free to tag them individually for speedy deletion, but mass userfying/draftifying is not supported by the community at this time. Beeblebrox (talk) 19:19, 9 December 2018 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

I 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. GMGtalk 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. GMGtalk 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). GMGtalk 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. GMGtalk 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. GMGtalk 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. GMGtalk 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... SemiHypercube 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 (talkcontribs) 21:56, 22 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 ReactionCreation 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)

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.

Should administrators be able to unblock themselves?Edit

Devs applied Version A, please discuss below this section. SemiHypercube 18:28, 27 November 2018 (UTC) (non-admin closure)
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 BOnly bureaucrats can unblock themselves. Other admins cannot unblock themselves.
  • Version C – Status quo. Any admin can self-unblock.

SemiHypercube 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. SemiHypercube 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. SemiHypercube 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. SemiHypercube 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. SemiHypercube 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 (talkcontribslogs) 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 (talkcontribslogs) 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.[citation needed] --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. SemiHypercube 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 (talkcontribslogs) 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. SemiHypercube 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. –Davey2010Talk 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. SemiHypercube 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 (TALKCONT) 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. SemiHypercube 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 (talkcontribs) 00:53, 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 (utc) 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. SQLQuery 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 OptionEdit

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. SQLQuery 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 (talkcontribslogs) 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. SemiHypercube 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) SemiHypercube 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. –xenotalk 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)

ThrottlingEdit

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 (utc) 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 (utc) 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? SQLQuery 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 (utc) 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 AnswerTM 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 AnswerTM 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 youEdit

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 (utc) 20:03, 6 December 2018 (UTC)

GlobalFactSyncRE/DBpedia project proposalEdit

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 (talkcontribs)

Should IPs be barred from turning redirects into articles?Edit

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)
  • As someone who frequently patrols these articles for NPP, I'm pretty ambivalent; if we keep the current method fine and I wouldn't object if we changed it. On the one hand it's easy to fix in the ways many other new articles aren't - simply restore the redirect. On the other hand many of the articles appear instantly in Google because of the age of the redirect which is less than ideal. These are fairly easy to patrol on the whole but NPP is also getting progressively further backlogged so not spending time on these could be good. It is consistent with ACPERM, but again restoring the redirect is very simple and sometimes we might get new notable encyclopedic content out of it. Best, Barkeep49 (talk) 05:14, 13 December 2018 (UTC)

Removing Facebook tracking parameter from external linksEdit

Following on the prior tracking discussions, this has general support and doesn't need another month for this specific parameter. This is ideal work for bots, and there is no issue if multiple bots work on it so long as they have approved BRFA's. — xaosflux Talk 20:11, 6 December 2018 (UTC)
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)

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. SQLQuery 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 (utc) 01:55, 4 December 2018 (UTC)
  • Sure, remove it. —TheDJ (talkcontribs) 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 lyricsEdit

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. SemiHypercube 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. GMGtalk 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.Edit

NOT DONE:
I think we'd all like to see soemthing that would curb this, but PC is not the right fit for the job. Beeblebrox (talk) 19:21, 9 December 2018 (UTC)
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.

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)

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.

Request for Ideas About MediationEdit

On 12 November 2018, in this project, a Request for Comments was closed which shut down the Mediation Committee. The question, was asked by the minority who opposed the shutdown, what would happen when there was a dispute that would have been handled by MedCom that was beyond the scope of DRN. Some of the answers were that DRN could be expanded, or that something would be done if an issue arose for which heavy-weight mediation was in order. I have a time-sensitive question for those who supported the shutdown (and also for those who cautioned against it) of how to resolve a specific open dispute. The content dispute, which is waiting for a moderator at the Dispute Resolution Noticeboard, concerns Origin of the Romanians. It is clear from the record and the number of times that issues about this article have been around that improving the article will take longer than the one to three weeks that disputes at DRN take. It appears to be a content dispute, not much affected by conduct issues, but too complex to be easily addressed in one to three weeks. In short, this is just the sort of dispute that the Mediation Committee used to handle when it had a workload and mediators. So my question for anyone is: Does anyone have any suggestions for how this dispute should be resolved?

I have asked for a volunteer to conduct heavy-weight mediation, possibly lasting several months. I haven't found one. I have one volunteer who is willing to try tag-team mediation with two or three volunteers taking turns mediating, but I don't have the second or third volunteers. So my question for anyone who said that we did not the Mediation Committee is: How should this dispute be resolved? Does anyone have any creative ideas for how to handle this? Does anyone have any obvious ideas that have been overlooked? What should be done next? There is a dispute waiting for a mediator.

Robert McClenon (talk) 03:53, 10 December 2018 (UTC)

  • From a cursory glance at the relevant dispute, all that needs to happen is enforcement of the existing discretionary sanctions. What's happening there is not a 'content dispute', it's groups of nationalist editors fighting to push their respective points of view. No matter how much you 'mediate' such a dispute, some vested party will not be satisfied. RGloucester 04:39, 10 December 2018 (UTC)
I don't think the Mediation Committee would've helped at all. In these sort of nationalistic battlegrounds, everyone involved in the dispute aren't going to agree to mediation nor are they going to accept the result if it doesn't go their way. Galobtter (pingó mió) 07:34, 10 December 2018 (UTC)

Patriarch is not misogyny (see misogyny)Edit

Closing as a clearly unproductive thread. --Yair rand (talk) 06:56, 13 December 2018 (UTC)
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.

Create a layman option for the people that do not know all the rules but see a glitch that needs fixing. Example: Misogyny list PATRIARCH as a word that defines it. This is wrong. {Biblically} Patriarchy is not meant to be misogynistic. It is the one person in every family that is the head of that family. There can only be one head of family responsibilities. It was the God of all mankind that assigned the man to be head of the family. So each man must treate his family with love. Man is commanded to treat his wife as he would treat his own body. This is a direct contrast to misogyny.

It is the PERVERSION of patriarch that makes it misogynistic. — Preceding unsigned comment added by 107.77.219.86 (talkcontribs) 23:00, 10 December 2018 (UTC)

No, that's still pretty misogynistic. GMGtalk 23:02, 10 December 2018 (UTC)
When you make an edit to an article, Patriarchy in this case, and it is reverted, the best place to start the discussion is at Talk:Patriarchy. The edit summary of the revert cited Wikipedia:No original research as the reason. --Dennis Bratland (talk) 23:23, 10 December 2018 (UTC)
Misogyny and intolerance wrapped in religion is still misogyny and intolerance. Depending on the faith, it can also be seen as heresy. —A little blue Bori v^_^v Bori! 20:50, 11 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.

Tagging fair use images with the date of their freedomEdit

As I'm sure most on here know, in just three weeks, for the first time in the history of Wikipedia, the United States will see a year's worth of copyrighted works become public domain. There are a number of images currently being used under a claim of fair use that will be able to be re-tagged as public domain (for example, most any image in an article in Category:1923 films). Something that would be nice to help with that effort would be if we can start tagging images with the date that they will become public domain (if known). Obviously, some things won't be known because their authors are still alive and others are not easily ascertainable because we have no idea when it was originally published, but for those things with a clear publication date, it would be nice to have Category:Public domain in 2019, Category:Public domain in 2020, etc. Perhaps a bot could go through and tag all fair use images as Category:Public domain date not assessed and then if it's unknowable, we move it to Category:Public domain date unknowable, but otherwise put it in a correct yearly category. That will facilitate uploading or restoring high-res versions and retagging it as public domain once the respective date hits. --B (talk) 20:39, 11 December 2018 (UTC)

It doesn't sound too bad of an idea, but there are some questions on how far would the bot tag into the future. I would not want different categories for every single year, as that would be kind of unnecessary. Instead, the bot could do something like Category:Public domain by year/2020, like how many bots sort alphabetical lists. I would also appreciate some information on how you would plan on making the bot functional? Integral Python click here to argue with me 14:37, 12 December 2018 (UTC)
@IntegralPython: A human is going to have to review a lot of them, maybe even all of them. In the fullness of time, the various templates and the upload form could be modified to incorporate the necessary fields (publication year, publication country, author's death year) so that the templates can be self-tagging. For example, for File:HairyDawgSanfordStadium.jpg until Thomas Sapp (the guy who designed the mascot) dies, we have no idea when the copyright will expire. Or for File:Batman181.JPG, it doesn't give us the publication date in anything machine-readable (or the publication country for that matter), but a human can see that it was published in the US in 1966 and so the copyright will expire January 1, 2062. So for that case, if the upload form and templates allowed you to specify such things, the date could be calculated automatically. But for now, a first step is to create the categories and allow things to be moved there manually (with the goal that templates can automatically categorize images in some cases). --B (talk) 19:11, 12 December 2018 (UTC)

Proposal: Applying Value-Sensitive Algorithm Design to ORESEdit

ORES has been out and served for the Wikipedia community for a while, for the purpose such as counter-vandalism. Having seen the wide usage and effectiveness of ORES in the community, we'd like to continue working on ORES development. We plan to improve and redesign ORES algorithms by incorporating feedbacks of all the stakeholders involved in the entire ORES ecosystem, such as ORES application developers, ORES application operators, etc. We want to understand their concerns and values, and come up with effective algorithmic designs that can balance trade-offs and mitigate potential conflicts of interests (such as edit quality control v.s. newcomer protection) to further improve ORES performance.

We will work with Aaron Halfaker (User:EpochFail) and his team to make improvements on ORES quality control models, and identify its limitations. Here is the project proposal on Meta-Wiki. If you are interested or have any thoughts, please feel free to reach out to me. Thanks! Bobo.03 (talk) 14:43, 13 December 2018 (UTC)

See mw:ORES for more information about ORES. In short, ORES is a machine learning platform that my team maintains. It helps with vandalism detection, new page patrolling, WikiProject task lists, and a few other types of Wiki work. --EpochFail (talkcontribs) 14:48, 13 December 2018 (UTC)