Wikipedia talk:Admin neutrality

message: The first result is an increase in disputes because every dispute means fewer people who can block you. Second result is the lack of an end to existing disputes because forgive and forget now has the nasty consequence of increasing the number of people who can block you. The end result is the people who can block are limited to those who know the least about the person and once they know ebough to block are by definition now involved in a dispute and can't do it again. The needed rules to make all this not happen can be summarized by saying this policy does not apply - so why apply it in the first place. 4.250.201.171 22:17, 9 December 2006 (UTC)
thread_title: Result

message: "However, if the blocked editor can demonstrate that the admin who blocked him was involved in a content dispute with him prior to the block, the blocked editor enjoys the presumption of innocence and should be unblocked until a new policy violation draws the attention of a neutral admin."
I don't like that. Maybe upon a situation like this, the reviewing admin, who must be different from the blocking admin, defers to the blocking admin and requests diffs/evidence. Set a time period window for the blocking admin to respond, eg. 12/24/x hours. If the blocking admin shows diffs, and the reviewing admin agrees with the block on the basis of the diffs, then the block stands. If the reviewing admin disagrees with the block, then the block is lifted. If the admin doesn't respond, then the block is lifted by default.
Although it may sound like instruction creep, it seems silly to let editors who deserve to be blocked being unblocked because of a procedural flaw. Product, not process. 
Thoughts? Daniel.Bryant [ T · C ] 08:07, 10 December 2006 (UTC)
thread_title:  Hmmm... 

message: Oppose, at least in its current form.  An admin blocking editors with whom he is engaged in an active dispute is already abusing admin powers; such situations have appeared at AN/I and RFC many times.  I understand and appreciate the motivation behind the proposal, but giving this idea its own projectspace page won't dissuage the occasional bad or simply overzealous admin, but will add even more reading material for those trying to stay abreast of Wikipedia's slow instruction creep.  Serpent's Choice 09:21, 11 December 2006 (UTC)
thread_title:  Instruction creep 

message: I suspect I was the one who indirectly caused this page to arise and it's probably a good idea to adress this problematic. Yet I feel that the the text as it is now has nothing to do with the problem itself. 
In my case, the administrator was not directly involved in the content dispute. What she did was not being neutral and taking sides too easily without looking at the complexity of the dispute, growing personal animosity against me because I disputed (out of ignorance) her initial warn and eventually exploding and getting me blocked for a nuisance long after I had corrected my behaviour very clearly. 
So the problem is not getting in content dispute, what wasn't the case, but getting into personal animosity and having a favoritism for another used who has been descirbed as disruptive editor, harasser, etc. The problem is in issuing a block without sufficient guarantess in cases of alleged PAs, which are described in all relevant policies as needing of much greater caution before issuing a block. 
Someone suggested that blocks should need two admins to enforce, so it would be harder to commit such errors/abuses. Of course this has other disadvantages and in my opinion the best would be that blocks would be reviewed by a panel of admins on request of the blocked user, either during the block or after it has expired. Supposedly now that's done at ANI, yet what I found is that no admin dared to take the case on their shoulders and review it issuing another resolution, either supportive of the block or rejecting it. This forces me to go to ArbCom as the only space where I can ask for such review. --Sugaar 10:42, 11 December 2006 (UTC)
replies: text: For the record, the incident which inspired this was SlimVirgin blocking ManEatingDonut. --NathanDW 02:32, 12 December 2006 (UTC)
replies: text: Since the block of user:ManEatingDonut was handled properly, there's no need to create a new policy to change the outcome. -Will Beback · † · 04:02, 12 December 2006 (UTC)
thread_title:  It really doesn't deal with the issue 

message: The great threat to Wikipedia's credibility is not that admins are allowing precious opportunities for banning lesser editors to slip through their fingers, like a traffic cop that isn't making his quota of tickets. The threat to Wikipedia's credibility comes from gangs of POV-pushing admins who impose their bias on important articles throughout the project, and block anyone who objects. 
Someone above in the discussion is worried about the possibility that an uninvolved admin might not know the editor who needs to be blocked. All the better. If it is really a blockable offense, it should be obvious to an outside party. --209.244.42.86 15:28, 11 December 2006 (UTC)
replies: text: No, the problem is that admin are already snowed under dealing with the hordes of self-promoters and content-sellers trying to increase their net traffic, stupid vandals, and POV warriors.  Please supply some examples of these 'POV pushing admins who block anyone who objects' - I've never seen this. Proto::► 11:01, 12 December 2006 (UTC)
thread_title: "Think Outside the Hivemind"

message: I prefer the wording to Wikipedia:Administrator Code of Conduct over this essay... Addhoc 15:18, 22 December 2006 (UTC)
replies: text: I took a look at this, and it looks all right. Has it ever actually been enforced? I can think of so many violations it makes my head spin. And I know, from following some of what goes on at WP:ANI, that admins routinely excuse each other's transgressions on the basis of, "Oh well, his intentions were good, and the victim was probably a troll or a troublemaker." --NathanDW 21:15, 22 December 2006 (UTC)
thread_title:  [[Wikipedia:Administrator Code of Conduct]]