User:Martijn Hoekstra/indef only

On the daily business of wikipedia, there is a lot of blocking going on. And I mean a lot. Like hundreds a day. And each one of those is blocked by (surprise surprise) an admin. And for each one of those, the admin has to decide on a duration for a block. Some of those are really clear cut. The indefblocks for vandalism only accounts. The other ones are open for interpretation and discretion of the blocking admin. Grounds taken into account are often the block history of the account, the frequency of disruption, the history of disruption, etc. Blocked users are also able to appeal a block. Blocks should be made undone if the editor shows he understands the reason of the block, and announces the behaviour leading to the block will stop. The best way to deal with the decision on the duration of a block, is to simply block indefinite, and unblock if you believe the cause for the block has been taken away.

Good reasons for blocking

Our blocking policy has two headers, that roughly cover the same ground. One is under the header Blocks should be preventive, and it defines that blocks should

• prevent imminent or continuing damage and disruption to Wikipedia;
• deter the continuation of present, disruptive behavior, and,
• encourage a more productive, congenial editing style within community norms.

The second is under the header Common rationales for blocks. It is a little broader, and firstly deals with protecting on the one hand the Wikimedia foundation, and on the other living persons, either as wikipedia users or others from harm done by editors, and secondly with preventing or stopping disruption to the project.

Good blocks then are used on accounts of editors that are displaying behaviour that is believed to be detrimental to Wikipedia. Blocking is the tool used to take away the editors measures to behave that way. If the user doesn't have an account that can't edit, the problem is stopped in its tracks. That is what blocking is for.

Good reasons for unblocking

We can fortunately also unblock accounts again. If blocking now is for preventing behaviour that is believed to be detrimental to Wikipedia, then once there is reason to believe the behaviour stops, the reason for the block is taken away. If there is no reason for a block anymore, then the block should be lifted.

Sadly, it's rarely quite so simple. We have difficulty believing the good faith of an editor, or we have difficulty believing in good outcomes. There is a problem with the editor, and strengthened by the knowledge of former behaviour, we're not unblocking the editor. This is a mistake. In by far most situations, we should not only assume good faith, but also assume good outcomes. People respond well to second chances. Unless we offer them, we will never know what possibly great editors we're tossing out.

Bad reasons for blocking

One of the most heard phrases when objecting to a block is 'blocks should not be punitive'. With that we mean we shouldn't block an account as a punishment for what a user did. I fully agree with this practice. There is absolutely no reason whatsoever to make a user 'pay for what he/she did' by blocking their account. Nobody gets any better from this. Not the person being blocked (though they might conceivably get annoyed, angry at or disappointed in Wikipedia), not the blocking admin (who has nothing to gain), and not the community (since the block was not made to prevent further trouble, but to punish for past behaviour, the community only loses out on the edits the editor still has to offer).

Another key principle here is the assumption of good faith. If there is no conclusive evidence of the opposite, we assume that editors act in what they view as the best interest of Wikipedia. They might mess up, make mistakes, or do the wrong thing, but the assumption should always be that they were trying to do the right thing. Blocking someone as punishment for trying to do the right thing is not in order.

Bad reasons for unblocking

We have heard some good reasons for unblocking. There are also pretty bad reasons for unblocking. The most common very bad reason to unblock is that the block has been long enough, and the block is reduced to time served. If a block is reduced to time served, this means that the unblocking admin believes the user of the blocked account is serving time, and thus the block being punitive, but the user has been punished enough.

Reasons to block for a limited time

A very large portion of the blocks we make are blocks that automatically expire. That makes sense, because there are some very good reasons to make blocks that automatically expire. One reason to make blocks that don't expire automatically is the expectation that the same behavior won't continue after the block. This is a prime reason to limit the time we block anonymous editors. We have no idea when the IP will change to another enduser. Keeping them blocked serves no purpose. This line of thought doesn't hold for editors with accounts. The only indications we might have that they will stop what they were doing is for them to tell us. If they haven't indicated the behavior will stop, we have no reason to believe it will. There is no reason for the block to expire. On the other hand, if they have indicated that the behavior will stop, and, assuming good faith as we should, we believe the editor, we should unblock them anyway. There is no reason anymore for the block, so waiting for the block to expire on its own isn't helpful. This reason to block for limited time might be a very good reason, but only for anonymous editors.

Another good reason to block for a limited amount of time, is the blocking of small proxies. Not the open, anonymising kind, but the proxies that companies or schools use to make use of a single IP for a large number of users. We block those briefly to prevent to collateral damage done to other users of the same IP. We know the block will likely hit unintended targets, but we aim to minimise that, by making the block as short as feasible. This reason also only pertains to anonymous editors.

All blocks for accounts should be indef

We have noted that there are very good reasons to block for a limited time, but none of those reasons pertain to accounts. Every block for a limited time is either a de-facto punitive block, or an unblock without any reason. We would be much better off without punitive blocks, and unblocking only when there is reason to unblock. This is not a case for a stricter blocking policy. I'm all for easy unblocking. But when we unblock, we should have a reason to unblock. An indication that the reason the behaviour leading to the block will not continue. With time limited blocks we have no such indication. Good faith should be shown swiftly, easily, and with very few exceptions. Unblocks should be the rule, and not the exception.

All time limited blocks could be seen as an indefinite block, being unblocked after a while by a bot, with no reason whatsoever. Looking at it like that, I see no reason why we would want to do that. There is no good reason to place a finite block on any user account.

Challenges

There are still a few challenges with this proposal. Below are listed some of them, with rebutals.

• There are administrative backlogs already. Putting twice the workload on every accountblock can increase the backlog.
  • Yet we should not base our policy on lack of manpower. We should recognise that with every limited block, we are making a less desirable decission based on lack of manpower.
  • Administrative backlogs on acute items (as this would be) don't tend to be large. AIV rarely has very long backlogs.
  • Putting some time and thought in any block or unblock is not a bad idea.
• An indefinite block is seen as an infinite block be default, and an unblock request is seen as an exception rather than a norm.
  • This will stay that way untill we start acting differently.
• Warning/blocking templates imply that the block will be infinite.
• Warning/blocking templates and messages say that users can appeal the block if the editor believes it is made in error. This should not be the case, you can just appeal because you'll stop the behaviour that caused the block.
  • An attempt at a template that handles this better can be found at User:Martijn Hoekstra/indef only/template. Someone better at templates could probably write better ones.
• Anons should (obviously) not be blocked indef. None of the reasons or arguments made on this page pertain to anons.
  • Well, duh.
• When talkpage access is revoked, and this is done indefinately, no case or protest can be made anymore.
  • This is often exactly the reason talkpage access is revoked. I believe that talkpage access could be done for a limited time. The only reason I can see for that is a cooldown-like block but all users should at some time have an easy venue to request an unblock. Unblock-l still exists, but this could be too much of a hurdle for a user.