The project page associated with this talk page is an official policy on Wikipedia. Policies have wide acceptance among editors and are considered a standard for all users to follow. Please review policy editing recommendations before making any substantive change to this page. Always remember to keep cool when editing, and don't panic.
I guess that with recent cases (like this) it will mean that a compromised account will be brought to a full stop rather than "ah, but I have admin rights so I'll simply unblock myself". --Redrose64 🌹 (talk) 10:52, 27 November 2018 (UTC)[reply]
Small change to "Edits by and on behalf of blocked editors"
I would like to make a small change for clarity to the following sentence, from:
"Anyone is free to revert any edits made in violation of a block, without giving any further reason and without regard to the three-revert rule."
to add "directly by a blocked user", so:
"Anyone is free to revert any edits made directly by a blocked user, in violation of a block, without giving any further reason and without regard to the three-revert rule."
The reason is that a policy that gives permission to break 3RR should be explicit and clear. The subsection is entitled "Edits by and on behalf of blocked editors", and since the above is the first sentence following the title, I interpreted it as meaning that "Anyone is free to revert any edits made by or on behalf of blocked editors in violation of a block, without giving any further reason and without regard to the three-revert rule." However, after some disagreement from other editors, and reading it again, it seems that it's only meant to apply to edits made directly by a blocked user, and that edits made by another editor on behalf of a blocked user are covered in the following paragraph. For the latter then, a reason must be given for a revert, and 3RR does apply, as with any normal edit. I thought I should double-check that this is in fact the intended meaning, before I made the change. If it's correct, I will also update the corresponding text at WP:BANREVERT. Thanks... --IamNotU (talk) 14:50, 20 December 2018 (UTC)[reply]
Since nobody responded after a week, I made this edit [1], but it was reverted by someone who complained that it hadn't been discussed. So, anyone care to discuss?
Again, the point is not to change anything in the policy, but to be more explicit, that the three-revert rule can only be disregarded when reverting edits made directly by a blocked editor (i.e., a sock puppet), but not after such an edit is reinstated by a non-blocked independent editor who takes responsibility for it.
I added the text shown in italic:
Anyone is free to revert any edits made by a blocked user in violation of a block...
Editors who for independent reasons subsequently reinstate edits originally made by a blocked editor take complete responsibility for the content, and the three-revert rule applies as usual.
The "for independent reasons" comes from the preceding paragraph about proxy editing, which distinguishes an independent editor from one who isn't, on that basis. The latter (a "meatpuppet") is also subject to the block. So, if an independent editor reinstates a sock's edit, the three-revert rule then applies again. It's "as usual", because there are other things that may modify the applicability of it.
Thanks for the comment. Well, at least one reasonably intelligent native English speaker required it, because they were edit warring, as it's not that difficult to misread it as meaning "any edits" from a sockpuppet can be reverted without regard to 3RR, even if reinstated by other editors. That reading is also not completely out of line with WP:BMB, which says that banned users may not edit at all, even if the edits seem good. So another editor's reinstatement "because it was useful" would seem to be in violation of the ban/block. Apparently that's not the intended meaning. Is there a simpler way, without adding too much creep, to make it more obvious that another editor's reinstatement becomes subject to 3RR? --IamNotU (talk) 14:23, 29 December 2018 (UTC)[reply]
Agree with Lourdes. We don't need this. An edit not made by a blocked editor is simply not a violation of a block (proxy editing is a separate issue and is already covered). And the "for independent reasons" addition is not correct.. I have restored blocked editors' reverted edits for exactly the same reasons that they were originally made, Mass reverts of socks' edits sometimes catch perfectly valid edits. Why would we ask for an independent reason to restore a typographical correction, for example? Meters (talk) 00:41, 30 December 2018 (UTC)[reply]
You're right that an edit not made by a blocked editor is simply not a violation of a block. The problem is Theseus's paradox. If an edit made by a blocked editor is removed, and someone puts it back, one could interpret it as still being the same edit, reinstated. I suppose it should be obvious that it's actually a different edit with the same content - but it wasn't obvious to me. It resulted in people getting angry and swearing at me, which was rather unpleasant and could have been avoided with a few well-placed words of clarification. What about just this:
Editors who independently reinstate edits originally made by a blocked editor take complete responsibility for the content, and the three-revert rule subsequently applies.
I had added "for independent reasons" to distinguish it from meatpuppetry, as that's how it's defined in the section above about proxies. A meatpuppet doesn't have independent reasons. In the case of restoring a typographical correction, the independent reason is "because it's correct", as opposed to "because puppetmaster123 told me to". --IamNotU (talk) 00:18, 2 January 2019 (UTC)[reply]
There is consensus to add the proposed text to the blocking policy. The majority of editors supported the addition, and argued that it is necessary to clarify when it would be (in)appropriate for an administrator to block another administrator who blocked them. A minority of editors asserted that the addition constitutes instruction creep, as retaliatory blocks are already prohibited in the "Blocks should not be punitive" section. — Newslingertalk05:23, 28 January 2019 (UTC)[reply]
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.
Asunblockself is now gone but sysops now have the ability to block the admin that blocked them instead, I think it makes sense to update the blocking policy to include language making this clear that it is only to be done in exceptional circumstances such as a compromise and never for the purpose of extending a dispute or getting revenge on the other party: namely since it’s functionally replaces unblockself, it should be viewed through policy as such. Therefore I am proposing the following be added to the blocking policy:
Administrators who are blocked have the technical ability to block the administrator who blocked their own account. This ability should only be used in exceptional circumstances, such as account compromises, where there is a clear and immediate need. Use of the block tool to further a dispute or retaliate against the original blocking administrator is not allowed.
Support, at least in principle, per TB. To be honest I think "exceptional circumstances" is a bit woolly; we could simply leave it at "when an administrator account has been obviously compromised", or try to formally define "when an admin account has gone off the rails". Vanamonde (talk) 07:57, 21 December 2018 (UTC)[reply]
I was trying to leave it open enough that if there is some reason other than a compromise where it may be reasonable, we could trust reasonable people acting in good faith to use their judgement. Something like my going crazy and running a script to block everyone on the project. Basically have this be similar to the NEVERUNBLOCK wording which envisions there may be times when you can in fact do some of those things, it’s just very rare. In practice, this would all but be prohibited except in matters involving site security/admin going absolutely off the rails. TonyBallioni (talk) 08:06, 21 December 2018 (UTC)[reply]
Support Common sense till now; probably required to be placed explicitly here, given the propensity of increasing admin vs. admin cases that have been noticed recently. As Vanamonde says, wording could be probably improved; usage of words like "getting revenge" also sounds quite Van Damme. Lourdes07:59, 21 December 2018 (UTC)[reply]
Yeah, I agree on the last point. It’s what you get when you’re writing late. Switched to “retaliate against” which captures the idea and sounds better. Early enough in the RfC and no actual change in meaning/intent so I don’t think anyone will mind. TonyBallioni (talk) 08:19, 21 December 2018 (UTC)[reply]
Looks good, and good idea to codify it here I suppose. If I had my complete druthers, I'd suggest two changes. The first is to emphasize that it should be uncontroversial and any other sysop would do the same, e.g. ...be used in exceptional and wholly uncontroversial circumstances, such as account compromises, where there is a clear and immediate need and any other administrator would do the same. Secondly, I'd suggest making it stronger in the end, substituting "never" for "not" and perhaps making clear it is misuse and/or abuse, e.g. ...against the original blocking administrator is notabuse of the tool and never allowed. Gets a bit wordy, I suppose. ~ Amory(u • t • c)11:11, 21 December 2018 (UTC)[reply]
Support. Similar to BMK I'd append "and may lead to sanctions." (or similar) at the end but I wouldn't replace "is not allowed" (but I'd have phrased it "is prohibited"). I am happy with it as it stands though. Thryduulf (talk) 11:14, 21 December 2018 (UTC)[reply]
Regarding the wording - to address the instruction creep concerns, the last sentence could also just be, "Use of the block tool for other purposes is never allowed and may lead to sanctions." Mz7 (talk) 19:16, 21 December 2018 (UTC)[reply]
Support as it makes sense to explain the capability and when it should be used. The follow up would be to request an unblock if the the original block was invalidly done. Graeme Bartlett (talk) 11:29, 21 December 2018 (UTC)[reply]
This is instruction creep. Too many words for an event that never happens and that anybody who is an admin would know not to do. This is grounds for immediate loss of admin access obviously. So are 100 other scenarios that we don’t need to enumerate specifically. JehochmanTalk12:58, 21 December 2018 (UTC)[reply]
Oppose. I'm on the same page as Jehochman above. The question should not be "should this be policy?", but, "is this not already covered by policy?". I tend to think it is - the policy says very clearly near the very top, "Blocks should not be used: in retaliation against users;". Then we should be asking whether this suggested policy addresses an existing problem. I don't think there is one, even if you include the previous status quo where an unblocked admin might have been tempted. There's also various other aspects of this policy which say to me, no need for any such addition. -- zzuuzz(talk)13:18, 21 December 2018 (UTC)[reply]
Its the same as with self-unblocking was in the past: this is needed as a bright line. Even if there are various aspects of the policy that already cover it (I’m not entirely sure there are to the degree it needs to be covered) there is also a lot of value in establishing bright lines in itself. TonyBallioni (talk) 14:34, 21 December 2018 (UTC)[reply]
Support weakly, I don't see this as really necessary but I don't see anything wrong with it either. For one thing, admins should already know that blocking someone who has just blocked you is a speedy path to Arbcom and having your mop smashed over your head into little tiny pieces. On the other hand, a vandal compromising admin accounts and mass-blocking everyone is not going to give a shit that we made this clarification to policy. If this was suggested as a technical restriction I would be 100% opposed, but if we're just saying "don't do that" then that's fine. Ivanvector (Talk/Edits) 15:08, 21 December 2018 (UTC)[reply]
Just adding a general comment: I'm not changing my vote, but the more we make our policies into exhaustive lists of every possible behaviour that is forbidden, the more people will have a justification to say "well you didn't say I couldn't do this obviously disruptive thing". Ivanvector (Talk/Edits) 17:19, 21 December 2018 (UTC)[reply]
Oppose Vindictive blocking is already covered by policy. Blocking a compromised account is already covered by policy. This policy is therefore not needed on WP:NOTBURO grounds as it "solves" a hypothetical that is already addressed in the same way by existing policy. If this RfC does not gain consensus, it can still be used to show consensus that vindictive blocking of someone who blocked you was not supported by the community and ARBCOM can deal with it appropriately. Best, Barkeep49 (talk) 16:15, 21 December 2018 (UTC)[reply]
I think prohibiting “vindictive blocking” is actually a lower standard than the current proposal, which says “never block when blocked unless the stars have aligned”. Think about how many disruptive actions on Wikipedia were originally intended to be good-faith, not intended to be vindictive in any way. Similar to how “don’t unblock yourself” was like a cardinal rule of being an administrator, I think this is the new cardinal rule we need to establish in order to update the blocking policy for the post-unblockself era. Mz7 (talk) 18:46, 21 December 2018 (UTC)[reply]
Support reluctantly. I don't think this is strictly necessary and should be already covered, but with the number of people that will wikilaywer everything to death, we might as well make it explicit. (I do like Amory's suggestions though) Natureium (talk) 16:53, 21 December 2018 (UTC)[reply]
Blocking someone who blocked you is already a violation of being an involved admin, and it still is even in the case of blocking a rogue administrator. I would prefer instead of saying the ability can be used in exceptional circumstances, state that this scenario falls under the ignore all rules policy of blocking to prevent harm in spite of breaking the involved policy (strike previous statement; I think I prefer just reinforcing the involved policy). A block-in-kind will result in a community review at some point, and comes with potential peril if you've misinterpreted the circumstances. I suggest something like the following under the "When blocking may not be used" section, in the "Conflicts and involvement" subsection:
When administrators are blocked, they are involved parties with respect to the event that triggered the block, and must not block other involved parties, such as the administrator who blocked them.
I prefer not to go into exceptional circumstances; ignore all rules already covers it. Given the rarity, I think bringing it up here would weaken the statement against blocks-in-kind. isaacl (talk) 17:22, 21 December 2018 (UTC)[reply]
My proposal is actually more bright-line than yours: it says administrators must not block the administrator who blocked them, and makes no reference to exceptional circumstances. Not blocking to further disputes is already covered in the current subsection. isaacl (talk) 17:25, 21 December 2018 (UTC)[reply]
I actually disagree. Exceptional circumstances is a higher standard than the exceptions INVOLVED. The reason that something is needed here is to avoid the ArbCom case where someone claims an exception to INVOLVED or that there isn’t a pattern of behavior. Despite what is claimed by those opposing, there is nothing in policy that would guarantee a desysop currently. My proposed wording (plus some additions suggested above that seem to have support) does that. TonyBallioni (talk) 17:32, 21 December 2018 (UTC)[reply]
I'm not sure I understand: my proposal explicitly says if an administrator blocks you, you must not block them, or any other party involved in the triggering event. How is this a lower standard than saying if an administrator blocks you, you should only block them under exceptional circumstances, which opens the door for a block-in-kind? This situation is so rare that there isn't a need to worry about guarantees; a discussion is going to happen anyway, and the justification for the block-in-kind will be examined closely. isaacl (talk) 17:40, 21 December 2018 (UTC)[reply]
Because it relies on INVOLVED, which has the big loophole of “any admin would do it”. Exceptional is above that. It doesn’t need a discussion then or review: it needs a policy basis for ArbCom to act decisively without creating policy on their own. This is what we had i.r.t. self-unblocking. TonyBallioni (talk) 17:44, 21 December 2018 (UTC)[reply]
I don't see this as a big practical issue, but the proposal can be modified to be more blunt then:
When administrators are blocked, they must not in turn block the administrator who blocked them. Additionally, they must not block any other parties involved with the event that triggered the block.
If another admin unblocks them, the admin is now an involved party and should not block other involved parties. Recall the most common situation where this will happen is with editing disputes, not the admin-gone-amok scenario. isaacl (talk) 17:56, 21 December 2018 (UTC)[reply]
Oppose - pointless instruction creep for a situation that is fully covered in existing policy, WP:NOPUNISH: "Blocks should not be used: 1. in retaliation against users;" Simple and straight to point.--Staberinde (talk) 18:33, 21 December 2018 (UTC)[reply]
Support I can see this sort of thing popping up when an INVOLVED administrator steps out of bounds and blocks another INVOLVED administrator, who then decides that in reality both sides are at fault and blocks the original administrator. While both are already breaking INVOLVED, I see no problem with reinforcing the notion that this shouldn't happen. I agree with TonyBallioni that mentioning the 'exceptional circumstances' is necessary, as a flat ban on blocking the admin who blocked you defeats the entire purpose of being able to block a rogue admin who is damaging the project. I also appreciate the point that IAR is a thing, but our P&G are a bit labyrinthine as they stand, and to me this is a great way to consolidate into a single coherent policy on blocking. We aren't contradicting anything in another P&G that I can see, so in this case I think the clarity is worth the extra wording. CThomas3 (talk) 20:35, 21 December 2018 (UTC)[reply]
Comment In response to all of the "this is already covered" comments above: this isn't currently covered for these circumstance. I find this particularly frustrating as we just had an ArbCom case where a significant portion of the community thought that someone who unblocked themselves multiple times shouldn't have been desysoped even though that has been for years basically the one thing in policy that guarantees you a desysop. This is an equally big deal, if not bigger, and we should have a clear line in policy establishing this as something that will not be tolerated. If we do not establish a policy on this there will be a divisive ArbCom case in the future without a clear outcome where ArbCom will be asked to make policy rather than to enforce what the community has decided.
That's not good for anyone, and if this is so obvious and already covered, then there is nothing that not having such a standard set does to harm it. There is literally no downside to having policy on this, and the major upside of avoiding future community disruption. Anyway, I've already spoken too much, but I wanted to address the major objection, which seems not to be with the substance, but with the idea of instruction creep, which simply isn't the case here. TonyBallioni (talk) 21:04, 21 December 2018 (UTC)[reply]
+1. I feel like the same opposing arguments here could have been applied against the "never unblock your own account" rule – you could say that WP:INVOLVED already covers that, but it helped to spell it out as a cardinal rule because it really is that important. It's one of those things where if you don't spell it out, somewhere down the line someone is going to argue that their block was not involved and not vindictive, despite not being in the kind of emergency situation that this technical change was intended to address. Consider the recent arbcom case where an admin unblocked himself – if the blocking policy did not make this action unambiguously inappropriate, I suspect the arbcom case would have been far longer and more contentious than it ended up being. Mz7 (talk) 21:17, 21 December 2018 (UTC)[reply]
Oppose. Well yes, the ability to block a fellow administrator should only be used in exceptional circumstances, period. That includes making the initial block as well as any possible "retaliatory" blocks. I'm disappointed at the level of traction this "instruction creep" is getting when the real need for clearer standards on civility were dismissed as "creep" by so many. – wbm1058 (talk) 23:18, 21 December 2018 (UTC)[reply]
Ambivalent. Not a lot will happen if this passes and not a lot will happen if it doesn't. Also, change the last three words of the first sentence from "their own account"to"them". Moriori (talk) 00:51, 22 December 2018 (UTC)[reply]
Fix bad wording, and then I can support. When we say should, we're giving strong advice but not making anything mandatory, i.e. the wording gives wiggle room beyond "exceptional circumstances". If we add this, it needs to be "must", because there's absolutely no reason to use this ability in normal situations. However, the in retaliation against users on which others rely has the same problem: blocking in retaliation isn't outright prohibited by anything except common sense. It's a really bad idea to leave room for wikilawyering, and we ought to close this potential loophole by saying "must not" in anything save exceptional circumstances. Nyttend (talk) 04:34, 22 December 2018 (UTC)[reply]
Oppose the current wording because I would prefer that if we get a block deadlock (A blocks B, B then blocks A) that a moderated explanation of why they felt the need to block the other participant in the deadlock in the same way that we proxy in Blocked users commentary to an AN* discussion for unblocking. Hasteur (talk) 16:48, 22 December 2018 (UTC)[reply]
Support this welcome clarification to policy in light of the recent technical changes to the (un)block tool. Policy should clearly reflect practice and this is a good step in that direction. 28bytes (talk) 17:55, 22 December 2018 (UTC)[reply]
Support but wording should be clearer. Rather than "exceptional circumstances, such as account compromises", just say "account compromises". In fact I would prefer "You must not use this ability unless you are sure that the account which blocked you has been compromised". Undoubtedly there are other exceptional circumstances where this would be appropriate but they are already covered by a policy with higher precedence: WP:IAR. Every user who would block their blocking admin believes themselves to be in an exceptional circumstance. Send them a clear message that they are not. — Bilorv(c)(talk)19:00, 22 December 2018 (UTC)[reply]
Reluctant oppose though it can easily be interpreted as a neutral, I just don't think there's much point in being neutral. I don't see this RfC as having a substantial benefit; it's already covered by policy. The only potential positive is preventing wikilawyering, which is legitimate but not persuasive to me personally. Wugapodes[thɑk][ˈkan.ˌʧɹɪbz]04:45, 24 December 2018 (UTC)[reply]
Just popping in to note my amusement on accidentally parsing the proposed addition as meaning that the operator of a compromised account, if blocked, is allowed by policy to in return block the admin that had blocked them. ansh66607:43, 24 December 2018 (UTC)[reply]
Support This should definitely be recorded formally in the policy, to squash any potential shenanigans later. — AfroThundr (u · t · c)16:04, 24 December 2018 (UTC)[reply]
Oppose. This specific use case was addressed and settled thirteen years ago in Wikipedia:Requests for arbitration/Stevertigo. Administrators always have to justify a block; a block that would fall within this use case is so obviously unjustifiable that the additional language is redundant. Given the discussion above, this would also introduce uncertainty about what to do in the rare case where an administrator account is compromised and misbehaves. Mackensen(talk)16:47, 26 December 2018 (UTC)[reply]
Weak oppose I can see that this could help preventing compromised accounts from damaging the site, but I'm not convinced that this in needed --DannyS712 (talk) 07:56, 1 January 2019 (UTC)[reply]
Support helps clarify the situation; better to state the obvious here than leave it unsaid or worked out in the future during some dispute resolution. I disagree with 'rule creep' as above; whether or not this is written down per se, it will still be followed as a 'rule' either way, because of its obvious nature. --Tom (LT) (talk) 10:50, 1 January 2019 (UTC)[reply]
Oppose. This is instruction creep that borders on WP:BEANS territory. Getting into a counter-block war is unambiguous wheel warring. If there is a compromised admin account blocking everyone with a script, it's an emergency situation anyways, so just go grab an arbitrator or a steward. Titoxd(?!?)23:04, 2 January 2019 (UTC)[reply]
Comment. As someone who has twice been caught up in IP-range blocks by WP:BUREAUCRATs whose email was closed and who I could therefore not contact, I feel entitled to comment on the substance if not the procedure. I could not even post {{unblock}} on my Talk Page. I only managed to get out of the jam by emailing a senior WP:ADMIN who knows me – twice. His first attempt to get the block lifted failed, his second succeeded (and was worth a Barnstar). What a waste of time and effort!
Second time round, another contact (who I'd also emailed) told me about UTRS. I also found an obscure backwater, and was given the temporary WP:EXEMPT privilege.
Query: How many honest editors have given up on WP because they've been hit by a rangeblock and don't know what to do about it? Solving all that faffing about took me the best part of two working days. Narky Blert (talk) 01:24, 6 January 2019 (UTC)[reply]
Support. Perfectly reasonable. And it's not instruction creep when it's simply giving emphasis to what should already be established common sense. -- Ϫ08:29, 6 January 2019 (UTC)[reply]
Support First of all, the proposed extension explains that blocked administrators have this ability. This is perhaps not immediately known to new administrators or to those who are not yet aware that unblockself is gone. Secondly, in the light of the recent case, it is best to make clear that this option is reserved for exceptional circumstances – even if it is somewhat redundant to the more general blocking policy. --AFBorchert (talk) 09:16, 12 January 2019 (UTC)[reply]
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.
Seeking comment on WMF funding request for blocking research
I am writing to request comments and feedback on a request I have for US$5000 Wikimedia Foundation funding to coordinate machine learning research on Wikimedia blocks on English Wikipedia and elsewhere in Wikimedia projects. Please comment on meta at
I expect in the future that other researchers will do similar analysis and prediction to rank Wikimedia blocks, just as the WMF has their experiments with the mw:ORES. I appreciate anything anyone has to say about my funding request in itself or as a model and precedent for similar research in this space. Thanks. Blue Rasberry (talk)17:19, 28 December 2018 (UTC)[reply]
