Wikipedia talk:Community enforced administrator recall

message: I think there must be an explicit assumption that the closing Bureaucrat must monitor the contributions by various factions. If an admin is simply being demonized by a group (s)he has crossed swords with, it could lead to ambivalence on the part of the admin to engage where appropriate. The admin should be allowed some leeway to complain if they feel they are being targeted in this manner. Ronnotel 16:22, 9 October 2007 (UTC)
replies: text: Of course yes, but that's why there is a high threshold of support required for a desysopping to be granted. If it really is a small faction, then this will have a low effect on the overall result and the 7 day discussion before the vote should calm people down or make people see sense and weed out any people that may be abusing the system. Ryan Postlethwaite 16:25, 9 October 2007 (UTC)

text: I don't see it as necessarily punitive. A.Z. 02:58, 14 October 2007 (UTC)
thread_title: Explicit need for B'Crat to monitor cliques

message: Making this a vote makes it too much of a troll magnet, as the opposers have frequently pointed out.  The only feasible way I can see for such a thing to work is that we need to rely on crat discretion.  If, in the crat's judgment there is not a good case for misuse of the tools, they tools do not get taken away.  Otherwise everyone you've blocked simply lines up, and reasonable editors need to waste their time opposing the recall in order to make it not succeed.  I realize the proposal as written already hints at this, but it needs to be more clear IMO.  Friday (talk) 17:39, 9 October 2007 (UTC)
replies: text: No, I agree that it can't be a vote alone. But I don't think it should be all 'crat discretion either. I think it needs to be a combination - some high threshold of community support for desysopping, as reflected by the !vote, with a putatively rational human monitoring the process for abuse. Ronnotel 17:56, 9 October 2007 (UTC)
replies: text: This basically is a vote. ((1 == 2) ? (('Stop') : ('Go')) 01:18, 10 October 2007 (UTC)
replies: text: That's exactly what's wrong with RFA and most of the proposed bit-removal processes. We have crats for a reason; why are people so reluctant to trust their judgment?  Crats should view it as a mistake on their part when they promote someone who turns out to be a bad admin.  They should take a personal interest in cleaning up the mess they made- so they need the ability to correct the occasional mistake.  This seems entirely obvious; why is there such resistance?  Friday (talk) 14:15, 10 October 2007 (UTC)

text: Clarification to the above: I'm not saying a mistake makes one a bad crat.  Mistakes are an inevitable part of any process we have here.  That is why it is crucial to have some means of fixing mistakes without jumping through too many hoops.  Friday (talk) 14:36, 10 October 2007 (UTC)
thread_title:  It cannot be a vote 

message: This is probably better than other desysopping proposals. However, I think there are a few issues:
#Standards for challenging/endorsement are a bit low. It may be sensible to restrict this to administrators (possibly too much cabal if this was done, however)
#A pure vote could lead to problems, especially troll magnet, sockpuppetry etc.
#Reapplying via WP:RFA should probably have a minimum wait period.
Other than that, it looks fairly sound. GDonato (talk) 18:27, 9 October 2007 (UTC)
thread_title:  Better 

message: See :Category:Wikipedia administrators open to recall. That is a voluntary process for recall. It works, as has been proven by experience multiple times. It is not a troll magnet, because of provisions it has within the process, as has been proven by experience multiple times. I've been a member of the category, and a supporter of its existance, since the time it got started. So does that mean, since I support a voluntary recall process, that I think an enforced one is a good idea? No. Any reasonably fair and trollproof process that could be devised in which the community would reach consensus that an admin had to lose his or her bit involuntarily would, in my view, necessarily be less efficient and more divisive than just taking the admin to ArbCom. Why? If the community COULD assemble the evidence to support such a call in this new process, it could ALSO do so in an ArbCom case. If the community COULD reach consensus that the change was needful, so would arbcom. Or else we've selected the wrong bunch for ArbCom, which I highly doubt. A voluntary process, with ArbCom as a check on the admin reneging works. Several arbcom members are themselves members of CAT:AOTR. However the vast majority of admins are not members.  That is, in my view, perfectly fine. A forced process in my view is a bad idea, and involuntary recall is a solution to a nonexistant problem. (Anyone already an admin who is advocating for a forced process ought to, in my view, be a member of the current voluntary process, but I digress) ++Lar: t/c 18:41, 9 October 2007 (UTC)
thread_title:  Forced vs. Voluntary ([[CAT:AOTR]]) 

message: For one thing, I could Ctrl+C, Ctrl+V most of what Lar wrote above. For the other, if you at all consider this seriously, I'd reevaluate the threshold of five "established users". It should (again, if considered at all) be expanded twofold:
#Increase the limit to, say 10 - it is not at all that hard to game the system by creating 5 socks every 3 months (and to accumulate 500 edits on each is trivial these days - could be done in a week) for the sole purpose of harassment of an unpopular admin.
#The quota must include at least one other sysop (if not two) - after all, we're not even considering taking away the buttons for "petty crimes". If the sysop to be recalled has really shown considerable misconduct, it shouldn't be that hard to find another admin sharing this view, no?
4 users + 1 admin was my personal non-written criterion on which I would consider accepting a recall request a while ago (now I'm more leaning towards accepting the outcome of an RfC) - but that's the voluntary nature of CAT:AOR - since no one forces me, I can specifically say "No, I don't like you and you, so shoo away! I have changed my conditions." - if you wish to make it a sanctioned process, you are taking away the "shield of voluntarism", so you must provide a replacement.
However, as closing words let me state this. Should all administrators be open to recall? Yes. Should they be forced into it? No. Миша13 19:28, 9 October 2007 (UTC)
thread_title:  5 users 

message: A threshold of 75% in favour of deopping is far too high. In cases where the community had so thoroughly been convinced that someone was unfit it is likely (as Lar points out) that the Arbcom would be too and thus this would be redundant. I'd say 50% is the highest number that could be considered. Check out how this process works on other Wikipedias. I support community based admin recall in principle. I think it's proven itself to work well and not be a troll magnet, both on the English Wikipedia and on other Wikipedias. It helps assure contributors that Wikipedia has a community-based system of organization rather than being ruled by a clique. Haukur 20:49, 9 October 2007 (UTC)
replies: text: FWIW, I think it should be 90% if we are voting. Mercury 20:59, 9 October 2007 (UTC)

text: No number is the right number.  Unless there is actual repeated misuse of the tools, the bit should not be taken away.  I don't care how many children, whiners or trolls demand it.  Friday (talk) 21:01, 9 October 2007 (UTC)
replies: text: Possibly bureaucratic discretion could be used to find out whether there is consensus to remove the mop? I know many of you here do not like it, but is there another option that would rule in the number of people commenting and the discussion/reasons at the same time? Captain panda 00:50, 10 October 2007 (UTC)

text: And this proposal ain't right either.  Good work to the author, but it is not what we need.  I also echo friday's sentiment here as well. Mercury 21:17, 9 October 2007 (UTC)
replies: text: I think a 2/3rds threshold clearly indicates that the admin has a problem and should be desysopped. --Fahrenheit451 04:12, 10 October 2007 (UTC)
replies: text: We should not even consider setting a "vote" limit. How about reasonable evidence of abuse? How about sour grapes? This will turn being an admin into a popularity contest when it should be about doing the thankless work that will not get done otherwise. ((1 == 2) ? (('Stop') : ('Go')) 05:02, 10 October 2007 (UTC)

text: Anyone can "vote" in an RfA, not just admins, they don't pick who participates. Regardless, why would we want to extend this popularity contest to de-admining? ((1 == 2) ? (('Stop') : ('Go')) 05:12, 10 October 2007 (UTC)

text: Anyone can vote, but admins predominate in and seem to consistently swing RfA elections.  If admins get elected by a popularity contest, there is nothing wrong with getting diselected by an unpopularity contest.--Fahrenheit451 05:27, 10 October 2007 (UTC)
replies: text: I have seen that people with compelling arguments based in reason sway RfAs, that they happen to be admins may be a sign of experience. Since we agree that this method of desysoping is basically a popularity contest, I think we can be okay disagreeing on if that is a good thing or not. ((1 == 2) ? (('Stop') : ('Go')) 05:28, 10 October 2007 (UTC)

text: While compelling arguments can sway an RfA, in my experience, that is the exception and not the rule, which is admin mob rule. --Fahrenheit451 05:39, 10 October 2007 (UTC)
replies: text:  You're actually claiming that administrators have a disproportionate say in who gets chosen as an admin?  <hollow laugh> --Tony Sidaway 14:46, 10 October 2007 (UTC)

text: Tony Sidaway, yes I am stating that.--Fahrenheit451 16:06, 10 October 2007 (UTC)
replies: text: I seems like a baseless claim to me. It would take some real evidence to convince me of that. Show me one RfA where "admin mob rule" override the consensus of the community. ((1 == 2) ? (('Stop') : ('Go')) 15:06, 10 October 2007 (UTC)
replies: text:  I'm sure many administrators could join me in reciting a long list of good potential administrators who they know would not pass a popularity contest.  We need to find a way to prise RFA gently but firmly from the hands of those who do not have Wikipedia's interests at heart, but that argument is for another page, not this one. --Tony Sidaway 15:21, 10 October 2007 (UTC)
replies: text: Really?  I can't think of any such list.  But this may be once again a religious issue- those who staunchly oppose any new method of removing the bit can't think of any list of bad admins who haven't already been dealt with.  This is why I think it's generally more useful to discuss general principles than specific editors. Friday (talk) 15:27, 10 October 2007 (UTC)
thread_title:  Threshold 

message: Sounds fair. Admins are servants of the community and should be responsible before it.-- Piotr Konieczny aka Prokonsul Piotrus | talk  18:10, 12 October 2007 (UTC)
replies: text: Agreed. A.Z. 03:23, 14 October 2007 (UTC)
thread_title:  Support 

message: I think 25% of users' support is better, because people become administrators with 75%. We can't allow that someone with 60% opposition continues being an administrator while someone with the same amount of opposition can not become an administrator. This would be giving undue importance to the status quo. Nevertheless, even if people don't accept the change to 25%, I support the proposed system anyway. 
I also think there should be no such thing as appeals to the ArbCom. If the user wishes to become an administrator again, just go through an RfA. A.Z. 02:50, 14 October 2007 (UTC)
replies: text: Here, I disagee. First, consider that 'recall' votes may have higher number of people dissatisfied with the user then standard rfa. We should not allow a tiny minority to recall an admin they dislike. Perhaps 50% would be a better treshold, but if I had to chose between 75% and 25% I'd go for 75%. Second; what's wrong with appeals to ArbCom? ArbCom can take the adminship away; it should be able to restore it. It's good to have more than one way of doing something - it makes it much less likely Wikipedia will be dominated by some oligarchical cabal or undemocratic majority.-- Piotr Konieczny aka Prokonsul Piotrus | talk  21:34, 14 October 2007 (UTC)
replies: text: I think ArbCom makes it more likely that Wikipedia will be dominated by some oligarchical cabal... A tiny minority is already able to stop anyone from becoming an administrator, so I don't see how that would be a reason not to allow them to take adminship from someone as well. What do you think about 75% support to remove admin status, but we change the RfAs to require 25% support to make someone an administrator? This would be like requiring consensus for someone not to become an administrator. A.Z. 22:11, 14 October 2007 (UTC)
replies: text: Oligarchies are not elected.  ArbCom is.  --Thinboy00 @985, i.e. 22:38, 5 January 2008 (UTC)
thread_title:  25% for de-adminship and no ArbCom

message: I note that this proposal's talk page has only attracted comment from about a score of editors.  Less than half a dozen people have made edits to the proposal itself.  While actual opposition has been small, it has been significant, and moreover there is no substantial support.
Looking at the links to the proposal, I see that it has had only minuscule exposure.  As it hasn't been listed in the usual places and hasn't attracted much attention yet, I'm reluctant to tag it as historical or rejected now.  I suggest its proponents now consider listing it in Wikipedia:Village pump (policy), Wikipedia:Centralized discussion, and so on.  After more substantial discussion we can gauge consensus. --Tony Sidaway 14:50, 1 November 2007 (UTC)
replies: text: I was not so reluctant, I see very little chance of the lack of consensus and objection to this policy changing. If others disagree I invite them to revert and seek more input, but right now it is stagnating. 1 != 2 18:00, 7 November 2007 (UTC)
replies: text:  I think you're right.  It seems to be dead. --Tony Sidaway 02:28, 12 November 2007 (UTC)
thread_title: Prognosis