Wikipedia talk:Blocking policy

This is not the page to report problems to administrators or request blocks.
	This page is for discussion of the Wikipedia:Blocking policy itself. Report incidents such as block evasion at Wikipedia:Administrators' noticeboard/Incidents. Report violations of the three-revert rule at Wikipedia:Administrators' noticeboard/Edit warring. Report active, persistent vandals at Wikipedia:Administrator intervention against vandalism.

Blocks should be preventative

Can blocks also be preventive? That is, can they be for the purpose of prevention as well as preventation? —Tamfang (talk) 17:18, 2 April 2015 (UTC)

Preventive and preventative have the same meaning. There is no such word as preventation, although such a word would be logical, or at least as logical as anything is in the English language.--Bbb23 (talk) 22:36, 2 April 2015 (UTC)

preventation, preventative and preventate are valid English words in the sense of violating no norms of phonotactics, but how are they generated? —Tamfang (talk) 23:53, 2 April 2015 (UTC)

You've lost me.--Bbb23 (talk) 00:23, 3 April 2015 (UTC)

prevent, preventive and prevention, like many modern English words, are built on the past participle of a Latin verb, to wit praeventum (the infinitive is praevenire). There seems to be no Latin verb whose past participle is praeventatum. —Tamfang (talk) 05:15, 3 April 2015 (UTC)

So, was there a question about the blocking policy in there somewhere? Beeblebrox (talk) 15:16, 3 April 2015 (UTC)

Heh, the opening question is a question but its relevance to the policy eludes me. Obviously blocks are meant to be preventative (WP:BLOCKPREVENTATIVE). Maybe Tamfang wants us to use preventive instead of preventative or maybe they just want the policy rewritten in Latin.--Bbb23 (talk) 15:23, 3 April 2015 (UTC)

Bingo! I'd say the word preventative must have been coined by a stutterer, if that were not a slur on stutterers. Call me stuffy but I generally prefer a better word over a worse one, especially if the better word is shorter. —Tamfang (talk) 18:37, 3 April 2015 (UTC)

Both forms seem to be correct per reference.com, but I would prefer "prophylactic", myself.—Kww(talk) 18:48, 3 April 2015 (UTC)

What does blocking do?

I was trying to read what blocking does and could not find anything here. Is this accurate? Did I miss this kind of information in this page? Blue Rasberry (talk) 13:49, 12 June 2015 (UTC)

I have removed it again. You should discuss the changes here first. Then when everything is right and there is consensus, add it in to the policy. -- GB fan 16:48, 12 June 2015 (UTC)

This is what the section said last.

Effects of blocks

There are different kinds of blocks. All blocked users may log into their Wikipedia accounts. If a person is fully blocked, they can do nothing on Wikipedia after logging in. If they are partially blocked, they may be able to do the following:

• They may edit their own user talk page for the purpose of addressing the block
• The use of some other functions, like Special:EmailUser may be available to contact other Wikipedians in a limited way for assistance concerning the block.
• If a user wishes to discuss their own block, then whenever possible, blocks should be discussed by them posting to their own talk page.

Blocking is treated as one of the Wikipedia:User access levels if applied.

-- GB fan 16:50, 12 June 2015 (UTC)

Sure. Who has an objection, and what is it? I have no idea how this works so I have no idea if this is accurate. Blue Rasberry (talk) 17:01, 12 June 2015 (UTC)

There are different settings that can be applied when an admin applies a block. We can Block account creation, Block user from sending email, Prevent this user from editing their own talk page while blocked or Autoblock any IP addresses used. In the section you said that someone can be partially blocked. I do not know what a partial block is. A username/IP address can be blocked and additional restrictions can be applied if necessary. If you don't know if something is accurate, you should ask someone first before adding it to a policy page. -- GB fan 17:30, 12 June 2015 (UTC)

I think the reason this page did not previously have a section liek this is that, as GB fan has indicated, blocking admins are able to set the block in a variety of ways. For example, an IP address can be blocked for anonymous users only, or it can be blcked for logged-in users as well if it seems warranted. Talk page and email access can be revoked if they are abused or if the user has made numerous unblock requests that have all been denied. And there are specialized blocks that, while technically the same as a block by any admin, can only be reviewed by checkusers, oversighters, or even arbcom. I'm not sure an explanation thorough enough to cover all the possibilities is something that would really improve the utility of this page, which is more about why we block. Beeblebrox (talk) 19:41, 12 June 2015 (UTC)

Beeblebrox I agree that this page is about "why we block" as you say, but I disagree that this page should focus coverage on that. Only about 100 Wikipedia contributors frequently apply blocks and this group already understands the content on this page. This page gets a lot of traffic and it is not from people who already understand blocks, but rather from people who want to learn more about blocks. This page should also be useful to people who know very little. I think some explanation of what blocking is and how users address being blocked would be useful. Please consider the below.

---

Effects of blocks

Blocks prevent users from editing Wikipedia articles. Beyond this, users may have additional restrictions on editing other parts of Wikipedia. When users are blocked, they get a message on their user talk page explaining why they are blocked. Most blocked users may still edit their Wikipedia user page. In most cases, users who address the reason for the block can request to have their block removed.

In the majority of cases, blocks are issued when good contributors to Wikipedia have misunderstood a Wikipedia rule and are requested to talk with an administrator before they continue editing.

In the case of a serious breach of Wikipedia's policies, some users may be blocked from editing their own talk page.

---

Is this accurate? Blue Rasberry (talk) 18:49, 15 June 2015 (UTC)

I would say it's getting closer, but there's a few things that are a little off:

• Any block stops a user from editing anything other than their user talk page, not just articles.
• The majority of blcoks are not of good contributors that have misunderstood a rule. I would guesstimate that over 75% of blocks are of very new users who are blocked for vandalism, sockpuppetry/block evasion, spam/advertising, or username issues. You don't hear about these as much as they are very routine and not as controversial as blocks of well known users previously in good standing, but they go on all day, every day. I would bet that 5-10 users have been blocked just while I was wrting this up, and most of them will never be unblocked
• Any blocked user can can request unblock, and we do have a fairly decent description of the various processes at WP:UNBLOCK
• Talk page access is usually not revoked right away, normally it only happens if the user has simply continued the behavior that led to the block, or has posted multiple unblock requests that show a WP:IDHT or WP:BATTLE attitude. There are exceptions, in particular sock accounts of long-term abusers who are considered lost causes

I'm wondering if maybe we should find one of those users who is good at making tables and graphs and we could just have a table showing the different kinds of blocks and what effects they have. Perhaps the WP:IMAGELAB could be of some help with that. Beeblebrox (talk) 19:39, 15 June 2015 (UTC)

I am very doubtful that any block is of a good contributor to Wikipedia who has misunderstood a rule. The controversial blocks to which Beeblebrox refers are of long-time contributors to Wikipedia who have disregarded or ignored a rule, such as the rule against edit-warring or the rule against personal attacks. By the time someone becomes a long-time contributor to Wikipedia, they don't misunderstand the rules (although a few long-time contributors do interpret the guidelines in their own ways despite others trying to reason with them). In some cases, you could get argument as to whether they are "good contributors" or are "net negatives" in spite of their excellent work at creating content. I don't know of any case of a block of a good contributor who has misunderstood a rule; they more likely disregarded the rule, probably due to anger. But as Beeblebrox says, many, probably most blocks are of editors who are just not here constructively for any of various reasons. Robert McClenon (talk) 20:51, 15 June 2015 (UTC)

I tend to agree that most of the time when a well-established user is blocked it isn't because they simply didn't understand a rule, but it does happen sometimes, mostly because of an incomplete or flawed understanding of what constitutes edit warring. Beeblebrox (talk) 00:27, 16 June 2015 (UTC)

That is occasionally true. If so, it probably means that the editor, while a long-time editor, had a case of WP:IDIDNTHEARIT with respect to previous efforts to explain what edit-warring is. Robert McClenon (talk) 05:31, 18 June 2015 (UTC)

Transparency

User:Callanecc recently said, "One of the recommendations we made was that CUs be required to put enough information [into the CU log] for themselves and others to determine the grounds for the check at the time and in the future." [1]

In the same spirit of accountability, I propose the following addition to this policy:

Administrators are required to put enough information into the block log for themselves and others to determine the grounds for the block at the time and in the future.

--Anthonyhcole (talk · contribs · email) 05:01, 17 June 2015 (UTC)

I certainly can't see any reason to object to that. I find it very frustrating when reviewing unblock requests to not have a clear indication why the user was blocked to begin with. It's kind of hard to evauate an appela when neither the blocked user nor the reviewing admin can see why the block was placed. It's not that common, but ti shouldn't happen at all. Beeblebrox (talk) 20:19, 17 June 2015 (UTC)

I think better wording is:

Administrators are required to put enough information into the block log to determine the grounds for the block.

Removes some cruft and gets to the core of the issue. Stuartyeates (talk)

Yep, that's better. --Anthonyhcole (talk · contribs · email) 10:24, 18 June 2015 (UTC)

It seems to fit best in the section Wikipedia:Blocking policy#Other important information. How does this look? I've made it more prescriptive than the present version ("should consider" → "should"):

If there are any specific recommendations or circumstances that a reviewing administrator would need to know, or that may help to avoid administrator disputes upon review of a block, the blocking administrator should consider including this information in the block notice. For example:

Administrators are required to put enough information into the block log for others to review the grounds for the block. Additional information such as specific recommendations or circumstances that a reviewing administrator would need to know, or that may help to avoid administrator disputes upon review of a block, should be included in the block notice. For example:

--Anthonyhcole (talk · contribs · email) 14:59, 18 June 2015 (UTC)

Done. --Anthonyhcole (talk · contribs · email) 08:04, 19 June 2015 (UTC)

Given that there's no requirement to place a block notice at all (I don't, nine times out of ten), there's certainly no requirement about including specific information.—Kww(talk) 14:20, 19 June 2015 (UTC)

I'm talking about changing the policy so that you have to leave enough information in the block log for others to review your block. One link is going to be enough for most blocks. I'm happy to change the last part from "should" to "may". So that would look like this:

If there are any specific recommendations or circumstances that a reviewing administrator would need to know, or that may help to avoid administrator disputes upon review of a block, the blocking administrator should consider including this information in the block notice. For example:

Administrators are required to put enough information into the block log for others to review the grounds for the block. Additional information such as specific recommendations or circumstances that a reviewing administrator would need to know, or that may help to avoid administrator disputes upon review of a block, may be included in the block notice. For example:

Anthonyhcole (talk · contribs · email) 18:18, 19 June 2015 (UTC)

• I'd support this, provided that when the information cannot be shared publicly, phrases such as "oversight block", "checkuser block", "arbcom block" are acceptable. Although, where possible, a reference for others with the relevant permissions should be given. e.g. "oversight block. ticket #1234567". Thryduulf (talk) 19:26, 19 June 2015 (UTC)
• In the vast majority of cases, one look at the contribs of the blocked user will make it obvious why it was blocked, whether or not there is any kind of block summary. Anyone reviewing the block should be reviewing the contributions of the blocked account; in fact, I'd say it's a more serious infraction to fail to review the blocked account's edits than it is to not include a block summary. Also, I don't know that one can mandate what is "sufficient information". What is the outcome you are looking for here? Are you proposing to desysop admins who do not do all this bureaucratic work for every block, whether of a longterm user or a poop vandal? Are you proposing that blocks be lifted if the paperwork isn't done to some arbitrary level? Is there any evidence that the goals of the project are adversely affected by administrators not using deeply informative block summaries or posting complex block notices? In other words, are you trying to address something that is major problem? In what percentage of blocks does the absence of this information become relevant? I suggest gathering some actual data, and reporting back, before pushing administrators to do work that is meaningless most of the time. Risker (talk) 19:28, 19 June 2015 (UTC)
• I guess the question that comes to mind for me is what constitutes "enough information" and "grounds". Certainly a block with a completely useless log entry like "lol" or something is something I would be annoyed to see any admin making, but on the other hand there's a wide spectrum information that might or might not be included in grounds-related rationales. For instance, is "disruptive" adequate? Is "[[WP:DE|disruptive editing]]"? What about "per discussion", as opposed to "per ANI", as opposed to "per ANI discussion at [permalink to thread]"? One I've seen pretty often and wondered about is things like "block evasion" with no further info - sure, that's grounds for a block, but it alone gives a reviewing admin nothing to work with as far as who the blocking admin thinks the new account is, etc. So yeah, in a perfect world I'd support a policy change that requires us to provide adequate grounds in the log, but in the current imperfect world I have no idea where we'd draw the line between adequate and inadequate. A fluffernutter is a sandwich! (talk) 23:11, 19 June 2015 (UTC)

Fluffernutter, if there's been a discussion, "per discussion at [permalink to thread]" should be more than adequate. It's time cheap and is respectful to the blockee and anyone who wants to know what prompted the block. It's a pointer that's needed in the block summary. Not an ANI case. --Anthonyhcole (talk · contribs · email) 03:32, 20 June 2015 (UTC)

• Too vague and restricting. You only have a limited amount of space, for starters. Next, what matters most is what the admin puts on the talk page. Explaining complicated reasoning for a block is best done on the talk page, not the block summary. As has been pointed out, most of the time, it is obvious. I would also note that it is not at all possible to edit the summary once the block is made, whereas you can edit the talk page, so putting a requirement for a detailed summary is unreasonable. If you slip or forget, you are a "violator". Not reasonable on that point alone. It is still a good idea to give a good summary, but using words like "required" or "should" are out of place as there is no way for an admin to correct himself, short of reblocking the individual. Dennis Brown - 2¢ 00:37, 20 June 2015 (UTC)

Dennis, regarding, "Explaining complicated reasoning for a block is best done on the talk page, not the block summary." Yes. But a link in the block summary to that explanation - particularly when that explanation is somewhere other than the blockee's talk page - is easy and - WRT transparency and accountability - essential. --Anthonyhcole (talk · contribs · email) 03:32, 20 June 2015 (UTC)

That doesn't really make sense. First you block, then you template, then you explain. There isn't anything to link to when you are making the block, as the overwhelming majority of blocks aren't the result of some ANI discussion. This is adding bureaucracy for bureaucracy's sake, and it isn't any more transparent than what we do now. It is an unnecessary burden that won't work for a number of reasons. Monty explains some of it below. Dennis Brown - 2¢ 10:46, 20 June 2015 (UTC)

• Usually with a block for vandalism there isn't much need for documentation. An edit summary of 'block evasion' can drive a later admin crazy but realistically it may be hard to do better. Personally I'd be grateful if anyone issuing a block for edit warring would include the name of the disputed article in their edit summary. EdJohnston (talk) 02:54, 20 June 2015 (UTC)

In most instances, a link to the blockee's contribs or a diff will be enough - ten seconds of your life. --Anthonyhcole (talk · contribs · email) 03:12, 20 June 2015 (UTC)

It seems rather bureaucratic to insist on a link to contribs in the block reason when its so easy to just click the contribs link in the block log. And the vast majority of blocks are going to have obvious reasons when you combine the rationale and a quick look there. Its the other ones that are a bigger question and warrant further discussion about just how specific we should be. Monty₈₄₅ 03:36, 20 June 2015 (UTC)

OK. Forget the link. That was Risker's suggestion. If the block is for obvious vandalism, nothing other than "vandalism" needs to be said. --Anthonyhcole (talk · contribs · email) 03:43, 20 June 2015 (UTC)

• Obviously we should have enough information in the block log to make it clear the reason for the block. But beyond a reason, when we start to include evidence in the block log entry, we run into two problems. First, we would direct more attention to what ever wrong thing the person did. In the case of edit warring, that isn't a problem, more eyes on a content dispute is a good thing. But when it comes to a blatant vandal, directing more attention at what ever they did is counter productive as discussed in the WP:DENY essay. Second, we have no opportunity to take back, or revise, or extend any the reason once its in the block log. So we should be careful what we say there, and err on the side of saying less in the log, and more on the talk page, where anything wrong can be more readily addressed. Monty₈₄₅ 03:32, 20 June 2015 (UTC)

In the case of an obvious vandal, just "Vandalism only" is more than adequate. As for the amount of detail to include in the summary of a complicated block - if it's complicated, there will be/should be a discussion somewhere that you can link to. For edit-warring, as Ed says just above, naming the article/s would be plenty to be getting on with for a colleague who wanted to review your work. --Anthonyhcole (talk · contribs · email) 03:40, 20 June 2015 (UTC)

I'm mainly focused on how we draw the line of obviousness. Consider this block [2] for block evasion. Now in my view, it was pretty clear they needed to be blocked immediately. But how much time should we spend trying to run down who the ultimate sock master is BEFORE blocking so it can go in the log, and how much time should spend running it down at all in a clear cut case like that one? Or we could sidestep the issue and just call it a vandalism block, even though calling it a block evasion block better explained what was going on... Transparency is great, and I'm always happy for people to review any block I make, but I'm still wary of adding a bunch of paperwork in cases where its really not required for effective transparency. Monty₈₄₅ 03:52, 20 June 2015 (UTC)

You don't need to make a case in the block summary - just put the relevant link in there, and only do that when a quick look at the blockee's contribs and talk page isn't enough for a colleague to go to the cause of the block; like, for instance, when the problems are laid out in an ANI thread, not the user's talk page.

In the case you cite above, since the contribs history contained only two entries, and one (this diff) involved an effective admission of editing under another account, I don't think you'd need to say anything but "block evasion" in the block summary. This isn't a make-work proposal. Where what's going on is obvious, you don't need to do or say anything. This addresses those cases where a very quick glance at the user's contribs and talk page doesn't make it very clear what was at the bottom of the block. --Anthonyhcole (talk · contribs · email) 04:06, 20 June 2015 (UTC)

I'm sorry, but when you start throwing around words like "require", it does become a make-work project, in that an action that was not previously necessary is now required; it's (by definition) more work. What percentage of blocks get appealed to start with? How many appeals a day do we get? How many appeals a day do we get where the reason for the block isn't fairly obvious (whether by looking at the user's contribs, whatever block summary is there, or whatever is posted on the talk page)? If we're talking one a week (or even one a day), it is not worthwhile to impose this rule, given we make hundreds of blocks a day. If it's one per hour, that's a different matter. So let's see the data showing that this is an important issue, and not just "I don't know why so-and-so did that". Risker (talk) 04:30, 20 June 2015 (UTC)

User:Risker, regarding, "are you trying to address something that is major problem?" Accountability is important. Most of the blocks I've reviewed have been for reasons that are obvious upon a quick review of the blockee's recent edits, or displayed on their talk page. In those instances a simple note in the block log like "vandalism only" is plenty. But some require quite a bit of trawling just to find even the precipitating event. It is a courtesy to your peers and those to whom you are accountable - the wider community - to make reviewing your work easy and transparent. When it's not obvious, the blocker needs to make it so, either with a link or useful description in the block log or on the blockee's talk page. That's what this policy should prescribe - clarity. I don't care what wording we end up with.

Regarding "make-work", perhaps it's a cultural thing. Where I come from a make-work proposal is one aimed specifically at making work with no intended benefit. --Anthonyhcole (talk · contribs · email) 09:17, 20 June 2015 (UTC)

This does nothing for accountability. Admin are required (yes, required) to explain any block they make as it is now, and answer to it at WP:AN or the talk page, via WP:ADMINACCT. That is accountability. Putting details in a block log doesn't make it more accountable, just more burdensome and more prone to having BAD information permanently stored in the logs. And as soon as an admin flubs up the link in the summary, someone will sure as hell drag them to WP:AN saying it was evading accountability or some such nonsense. Dennis Brown - 2¢ 10:57, 20 June 2015 (UTC)

I really don't understand most of the opposition here - the aim of the proposal is to ensure that in all cases the block log entry is sufficient for the blockee or another administrator, potentially years later, to understand the block. Looking at the most recent 150 blocks, we have for example:

• Thegamer098 (talk · contribs): "Vandalism-only account" - nothing more needs to be said.
• 24.182.235.52 (talk · contribs · WHOIS): "Disruptive editing, specifically your repeated removing of sourced material from the Pippa Middleton article in spite of many warnings, plus your previous vandalism on same" - perfect.
• Zacjohnsson (talk · contribs): "Spam / advertising-only account" - again, that tells you all you need to know
• 101.191.21.222 (talk · contribs · WHOIS): "Vandalism" - a look at the contribs should be sufficient, but it isn't obvious to me at first glance which contribs were vandalism.
• Mhubng (talk · contribs): "Disruptive editing: removing AfD notices in spite of warnings" - perfect.
• HeGabor (talk · contribs): "Abusing multiple accounts: User:Cryx88" - perfect.
• 190.215.215.120 (talk · contribs · WHOIS): "Disruptive editing repeated unosurced additions" - perfect.
• 216.16.55.81 (talk · contribs · WHOIS): "vandalism of Archimedes Plutonium" - perfect.
• 89.240.129.213 (talk · contribs · WHOIS): "sock" - this one isn't helpful as there is no mention anywhere in the contributions or on their talk page of who this is a sock of, there is no linked discussion, and it is not obvious from the contribs why they were blocked. Better would have been "sock of <user>", "sock (of <user>?)", or "sock (see <linked page>)".
• Funkyking (talk · contribs): "Abusing multiple accounts: Please see: Wikipedia:Sockpuppet investigations/Chowkatsun9" - perfect.
• 2607:fb90:5b3:1af0:8ddf:7c25:b139:236f (talk · contribs · WHOIS): "Vandalism" - this one is fine as their talk page has warnings with relevant links.
• 151.225.119.55 (talk · contribs · WHOIS): "part of mass attack, cf. User:86.2.52.154" - this is all-but perfect (the link should be to user talk:86.2.52.154, but that is trivial) as the linked page contains the explanation.

So most admins are doing enough already, and you see how little work is actually involved in getting it right. Thryduulf (talk) 11:25, 20 June 2015 (UTC)

Perhaps you've not had the opportunity to run into them, Thryduulf, but there are a significant number of serial trouble-makers who want nothing more than to see their "original" username littered everywhere all over Wikipedia. If you want, I will email you some of their names, but I'm not going to publish them publicly. It's an essential part of their trolling of our project (and sometimes other projects as well), and WP:DENY does have a useful role in a lot of cases. They've even been known to "appeal" the blocks of some of their socks for strictly lulz purposes. I know I'm old and cynical, but this has been a genuine issue since before I even started editing, there is nothing really that can be done to make it better, and it's one of the reasons that proposals such as this (which don't have anything to do with accountability, although I believe that Anthyonyhcole and others have mistakenly thought it does) have never succeeded in the past.

Those who choose to deal with a significant number of unblock requests get a skewed view of what constitutes a problem block. The administrator corps as a whole blocks hundreds of accounts every day, and even more are blocked/locked at a global level; there are in the range of 5,000 blocks and locks a week - and I'm probably being conservative. If there are two unblock requests a week that seem to have insufficient information, that is less than 0.001% of blocks. And you're going to be told to jump in the lake if you push stewards to explain why they globally locked another big stack of accounts; the most you'll get is "spam" or "vandalism" out of them. Risker (talk) 14:10, 20 June 2015 (UTC)

101.191.21.222 is obvious if you look at the edit filter, and even if you don't look at that for everyone. An edit to Wikipedia:Edit filter/False positives/Reports is a major flag, I'd say at least half the false positive reporters are upset their vandalism got blocked, and are either ready for a block, or close. Monty₈₄₅ 14:49, 20 June 2015 (UTC)

• What about trying to improve accountability from another angle; we could put together a group, (probably just whoever wants to be involved) to proactively review blocks to see if they have reasonable explanations and if they are consistent with normal blocking practices. The group would then make suggestions to blocking admins on best practices, and in the case of a bad block that can't be resolved with the blocking admin, to bring it to AN or AN/I for review. The load could be adjusted, but lets so hypothetically a bot would pick 2 random talk page revocations, and 2 random regular blocks each day, and post them to a project page, where the members of the project would discuss them, and if there were any problems, reach out to the blocking admin to create a dialogue. Monty₈₄₅ 15:02, 20 June 2015 (UTC)

I wouldn't hold my breath waiting for an influx of support for that idea. Sounds like a make-work task for people who already have more than enough work to do. I really don't see what the big deal is here, this is just a minor wording change reflecting what admins should already be doing. It's effect is minimal because most of the time this problem doesn't exist. It costs us nothing to add this advice to the policy, but whatever. Beeblebrox (talk) 16:45, 20 June 2015 (UTC)

I've just looked through the 500 blocks over the last 6 hours. Mostly bots blocking proxies. But of the 100-odd manual blocks, all the logs were transparent. Beeblebrox is right. Requiring transparency is simply formalising what good admins do. I think that's what policy is meant to do. Clearly, properly worded, this proposed change won't add a jot to the workload of typical, responsible admins. I'll think about this and redraft the proposal in light of the above feedback. Thanks for all your comments. --Anthonyhcole (talk · contribs · email) 21:23, 20 June 2015 (UTC)

Not to nitpick, but the current wording is advice. The proposed wording would be a requirement and the basis for contention at block review. That is the point. Almost always, admin already give good summaries. Beefing up the requirement is answering a question no one asked; fixing a problem that doesn't exist, and adding more problems down the line. Simply put, it is unnecessarily bureaucratic, and we should avoid adding more rules unless we are specifically fixing a real problem. Dennis Brown - 2¢ 02:44, 21 June 2015 (UTC)

The problem exists. I encountered it several times with a subsequently de-sysopped user, and I've encountered it in reviewing blocks by users currently active in good standing. As for the wording, I hear what you say and am dwelling on it. --Anthonyhcole (talk · contribs · email) 09:20, 21 June 2015 (UTC)

If the sysop who wasn't using summaries was desysopped, then maybe the existing system works? ;) I agree that a blank summary isn't excusable, but that is rare. I just don't want to get slammed for a summary when I explain in full detail on their talk page, ie: drama. Dennis Brown - 2¢ 21:15, 21 June 2015 (UTC)

If you have explained on their talk page you just need to include the words "see user's talk" or "per user's talk" or something like that if you want to be absolutely certain. However a user's talk page is the obvious place to look so it isn't explicitly needed. This is intended for summaries like "per discussion" when that discussion is not on the user's talk page and there is no hint as to where that discussion is. An edit summary of "drama" when it is obvious from their contributions where they are causing drama is fine, the same edit summary where it is not obvious (e.g. if they're ip-hopping or it has been rev-delled) should be expanded to "drama at page". We don't want essays, we want pointers. Thryduulf (talk) 21:32, 21 June 2015 (UTC)

• Summarizing: The snapshot results indicate that there is no serious issue with administrators failing to explain the reason for blocks; in fact, the snapshot shows that there were no problems at all with the absence of reasoning. There is no evidence that there is a need to require this information, because in almost all cases it is already present. Nobody seems to be proposing that there be specific consequences (either desysop or automatic lifting of the block) should an admin block without completing a block summary and/or block message on the blocked user's talk page. There is no objection to the current wording, which strongly urges exactly the behaviour being sought with this proposal - and there is no evidence at all that there is significant deviation from following that advice. Nobody has produced an example where an unblock request was adversely affected by a lack of a block summary/posting on the blocked user's talk page. Evidence has been given that there are certain WP:BEANS situations where a block summary directly linking an account to a sockmaster is more likely to cause harm than resolve situations, and there has been no example given where the lack of identifying a sockmaster has adversely affected an unblock request. In other words...there is no evidence that there is any point whatsoever in making this a requirement, as opposed to the best practice already outlined. There are no policies that *require* people do to certain things (there are a few that require them to *not* do certain things like make personal attacks, and those situations have specific potential consequences attached to them), and the proposed use of the "required" terminology is culturally out of place, particularly with no indication that there will be any consequences attached to failing to adhere to the "requirement". Bottom line, nobody's shown any evidence that lack of summaries/block notices is having an adverse effect on blocked users, unblock request reviewers, the encyclopedia, the admin corps, or the community as a whole. Risker (talk) 22:16, 21 June 2015 (UTC)

Proposed addition to Wikipedia:Blocking policy#Blocking bots

At end of first paragraph. "Administrators should take care not to apply an autoblock to a bot as this will result in the autoblock propagating to all the other bots that share IPs on Wikimedia Labs." --NeilN ^{talk to me} 05:18, 17 June 2015 (UTC)

Seems logical to me. Chillum 12:29, 17 June 2015 (UTC)

Bit of a "duh", but never hurts to write it down anyway as some may not have been aware of it until they actually tried. WP:DDMP anyone? RegistryKey^(RegEdit) 05:39, 19 June 2015 (UTC)

Problem would be solved if "autoblock" wasn't automatically checked in just about every block form, regardless of whether using the basic one or a scripted one. Perhaps a block form specific to bots might be useful, or a warning message that the account is flagged as a bot should appear on the block form. Risker (talk) 19:31, 19 June 2015 (UTC)

I like your idea to automatically uncheck if the user has the bot bit. Or take away the option in software if the target has the bot bit. Dennis Brown - 2¢ 00:40, 20 June 2015 (UTC)

There might be valid reasons to leave autoblock on (i.e. if the operator is also blocked), so it might be good to leave the option available, but making it no longer the default is a good idea. --Rschen7754 01:18, 20 June 2015 (UTC)

Good point. Dennis Brown - 2¢ 02:21, 20 June 2015 (UTC)

Most bots don't run from the same IP as the operator's account does; the majority of bot activity on this project comes from the Labs, and most of the rest run from dedicated off-site servers. If for some reason it is necessary to add an autoblock, it can be added. It just should not be the default. Risker (talk) 04:33, 20 June 2015 (UTC)

I am not familiar with the twinkle code, but I imagine it would be able to check for the bot bit easily enough and default to autoblock off with a short message. I can't think of any good reason not to. Who is the person to ping about that? Chillum 04:39, 20 June 2015 (UTC)

Perhaps MusikAnimal, he's been doing the block module work, I think. Kharkiv07 (T) 02:31, 21 June 2015 (UTC)

Good idea! Since account names of bots almost always end with "bot", we can do a simple check for that when blocking accounts and disable autoblock if present. I've added this to the to-dos. Should be fairly easy to implement so hopefully will go out with the next update — MusikAnimal ^talk 03:35, 21 June 2015 (UTC)

Thanks. Is adding the proposed text to the policy now necessary? --NeilN ^{talk to me} 04:09, 21 June 2015 (UTC)

Is there a downside in simply giving Labs-hosted bots IP Block Exemption? Better to do it on bot creation than make everyone do something special later down the line.—Kww(talk) 15:24, 21 June 2015 (UTC)

It would help, and would probably address about 70-80% of issues. There are a few other bots that are run on non-WMF proxy servers and have been caught in range blocks before. Perhaps IPBE could be added directly to group of permissions attached to the bot flag? Is there a downside to this? I'm having a hard time thinking of a situation where a misbehaving bot would need both its "account" and its IP blocked, and we are pretty insistent that all bots be properly flagged (unlike several other projects). Will this be an issue for global bots? Risker (talk) 21:15, 21 June 2015 (UTC)

Oh hold on. I've just now looked at the User Group Rights, and all flagged bots automatically have IPBE. Unless I really misunderstand, that should mean that even IP autoblocks should not affect flagged bots. Risker (talk) 00:02, 22 June 2015 (UTC)