Wikipedia:Requests for adminship/Bureaucrat Unchecking/Poll: Difference between revisions

Browse history interactively

← Previous edit Next edit →

Content deleted Content added

VisualWikitext

Inline

Revision as of 01:41, 11 January 2010

RfC: Should bureaucrats be allowed to uncheck the sysop and bureaucrat bit when instructed?

Please consider joining the feedback request service.

An editor has requested comments from other editors for this discussion. Within 24 hours, this page will be added to the following list:

Wikipedia policies and guidelines

When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

Per the discussion here WT:RFA#Unchecking the box, is there consensus to allow bureaucrats to manually uncheck the sysop/crat bit when instructed per policy (currently by ArbCom, uncontroversial [not under a "cloud"] request by admin or crat to remove their own bit, in emergency desysop situations that would normally require a steward, and potentially in cases of WP:CDA, should that be implemented)? -- Avi (talk) 08:34, 10 January 2010 (UTC)[reply]

This page in a nutshell: Whenever a steward would have been asked to press the button to desysop/decrat, a bureaucrat can now press that button. The decision as to who gets desysopped does not change; only who presses the button once the decision is made. This is not at current, a referendum on 'crats judging consensus for desysops, and there is no consensus-based desysop process in place. Should that occur in the future, the role of 'crats in that process will be determined then (please see WP:CDA for that process).

Support

Best to keep things local if possible. –Juliancolton | ^Talk 15:10, 10 January 2010 (UTC)[reply]
~~As long as "incontroversial" is defined, then definitely~~ I think this is an excellent suggestion. If local 'crats can flick the switch on when they have judged concensus has shown it to be desired, I think they should be able to flick it off if ~~concensus in a community discussion (or as instructed by Arbcom) shows~~ it is desired. -- PhantomSteve/talk|contribs\ 15:19, 10 January 2010 (UTC)[reply]
It would be defined as it is now "not under a cloud". -- Avi (talk) 15:28, 10 January 2010 (UTC)[reply]
Thanks for clarifying that, Avi (and adding it to the proposal above for clarity). -- PhantomSteve/talk|contribs\ 15:42, 10 January 2010 (UTC)[reply]
Yep. Per JC. Pmlineditor ∞ 15:29, 10 January 2010 (UTC)[reply]
I don't see why they should only be able to make the change one way. This is a quite separate discussion from the perennial "community de-sysop" debate. Guy (Help!) 15:41, 10 January 2010 (UTC)[reply]
Yes. If crats can hand out the admin bit, they should also be able to remove it - there's no reason for it to be a one-way process. As we're limiting the use of this proposed ability to uncontroversial cases, I don't see any problems with it. Robofish (talk) 16:05, 10 January 2010 (UTC)[reply]
Of course. If they can be trusted to give it out, then why not to perform the removal which has a much lower potential for harm. Jim Miller ^{See me | Touch me} 16:19, 10 January 2010 (UTC)[reply]
Seems only the logical wiki-way: If you can add something, you should be able to remove it again. And as JzG says above, it's separate from why they should be able to do so. This discussion is only about the "whether" they should be able to do so when desysopping, for whatever reason, is needed. The only reason one could oppose it is that a rogue crat might run amok and desysop all admins or desysop anyone they like but that same risk exists with stewards. But even such actions could be swiftly reverted, so the slight risks involved (which are involved everytime someone is granted any rights) are minimal. Regards So Why 16:21, 10 January 2010 (UTC)[reply]
(edit conflict × 2) Absolutely. There is no reason for them to be only able to go one way. People say that if they abuse it and remove all admin bits, we'll be in a deep hole. However, they're already trusted not to sysop people without an RfA. In my opinion, being able to sysop everyone is much more dangerous than being able to desysop someone. This proposal just makes sense. (X! · talk) · @727 · 16:26, 10 January 2010 (UTC)[reply]
It's really very simple—if we trust someone to give the bit, we should trust them to take it away again. As Jim Miller said, this has a much lower risk than simply becoming a bureaucrat. Ideally, I'd like this to be combined with a process for actually taking away the bit, rather than on an one-off basis. Regards, --—Cyclonenim | Chat 16:27, 10 January 2010 (UTC)[reply]
This is a no-brainer. Friday (talk) 16:28, 10 January 2010 (UTC)[reply]
Clearly sensible. — Martin (MSGJ · talk) 16:44, 10 January 2010 (UTC)[reply]
Sure, much clearer to have the relevant process in our logs than meta's. The decision mechanism when to desysop is unchanged (ArbCom), just the implementation is nicer. —Кузьма^討論 16:46, 10 January 2010 (UTC)[reply]
I think it is commonsense that anyone wanting to give up the mop should simply be able to do so by asking a crat on this wiki, and that a crat should be able to desysop an obviously compromised account. Ϣere SpielChequers 17:27, 10 January 2010 (UTC)[reply]
Clearly a good idea for them to be able to uncheck an admin in certain circumstances - Dumelow (talk) 17:47, 10 January 2010 (UTC)[reply]
Allowing our crats to flip the switch in the other direction will take load off foundation and make the action just that little more responsive.Josh Parris 18:06, 10 January 2010 (UTC)[reply]
I don't see any reason why we can't keep things local. If anyone's worried about bureaucrats desysopping people for no reason at all, I'm sure any bureaucrat who did that would have their bureaucrat rights removed pretty quickly. I'm also not worried about inactive bureaucrats having the feature either: they don't use their current bureaucrat tools, and I don't think that any of them would start using them just to desysop people for fun (I don't remember admins who hadn't been active for years coming back in huge numbers when the ability to give out rollback was introduced). Acalamari 18:23, 10 January 2010 (UTC)[reply]
Certainly. It's a good idea to keep these things local (as opposed to on Meta), and bureaucrats are already considered our most trustworthy users. Jim Miller hits the nail on the head: If we trust bureaucrats not to sysop without consensus, why shouldn't we trust them with the ability to desysop (which does in fact have a far lower potential for destructive effect anyway)? We don't need a community de-adminship process before granting 'crats this ability. For example, when ArbCom decides to desysop someone, why should we need a steward to flip the switch? A bureaucrat could do it. Why should an admin be required to request their own desysopping at Meta rather than simply posting at WP:BN? In my opinion, this proposal makes a lot more sense than the status quo. A Stop at Willoughby (talk) 18:25, 10 January 2010 (UTC)[reply]
As per everyone, it just makes sense. There are plenty of possible scenarios, each very unlikely and not, on the whole, that horrifying. I fully trust the 'crats with this responsibility and furthermore, it seems the community is aching for it as well. A number of the de-sysop mechanisms that have been proposed at least nudge toward a larger role for bureaucrats, and the RfB bar is set so high that it's logical to give them a small tool worthy of that invested trust. This seems definitely in-line with what is desired here. ~ Amory (u • t • c) 18:41, 10 January 2010 (UTC)[reply]
Yes, this really is just common sense. However, per the comment in the discussion section below, I'm not sure about letting Bureaucrats remove fellow Bureaucrats, as opposed to Administrators. --Tryptofish (talk) 18:42, 10 January 2010 (UTC)[reply]
I agree with the same sentiment expressed by most (all?) above: bureaucrats are trusted to determine consensus when adding the bit (in either case—RfA or RfB), so it's a logical step for them to determine when consensus exists for the bit to be removed. I also agree that having local control over this is a good thing, especially in cases of emergency. ···日本穣^? · 投稿 · Talk to Nihonjoe 19:18, 10 January 2010 (UTC)[reply]
Strong Support. 'crats are trusted to determine consensus to promote; no reason to suggest they can't determine any consensus to demote. Ironholds (talk) 19:31, 10 January 2010 (UTC)[reply]
As nom. To reiterate, this RfC is not discussing which situations are eligible for unchecking bits, just, when bits are supposed to be unchecked for acceptable reasons (voluntary resignation, ArbCom, etc.) who is able to actually uncheck the box. -- Avi (talk) 20:07, 10 January 2010 (UTC)[reply]
Support - If bureaucrats are trusted to make administrators, they should also have to power to take the mop away. Agree with Amory that the RfB bar is set quite high for the 'crats, so this is a logical duty for them. Talk about having been vetted! Jusdafax 22:20, 10 January 2010 (UTC)[reply]
It has never made sense to me that they should be. Let's take a hypothetical RfA where Crat_A passes the candidate, but that decision is challenged not by just the general community, but by other 'crats. The community disagrees with the 'crat who promoted the canddidate, and eventually the 'crat agrees that a mistake was made. As it stands now, the 'crat cannot simply remove the bit, but has to get somebody else to do it. IMO, if a 'crats decision is challenged by other crats, this would become time for a 'crat chat---during which time the candidate should NOT have the bit. But once granted, the 'crat can't remove them. Various abilities generally come with the ability to reverse the action, this makes complete sense as mistakes may occur or situations may arise requiring the reversal.---Balloonman ^{NO! I'm Spartacus!} 22:26, 10 January 2010 (UTC)[reply]
Support If crats are trusted to judge consensus to promote someone to an admin, they should be able to judge consensus to demote someone from an admin as well. The Thing _{Editor Review} 22:30, 10 January 2010 (UTC)[reply]

Why not? The role receiving the extra option is the one that turns on the bit. This accords no new discretion or decision making powers. No big deal. Vassyana (talk) 22:35, 10 January 2010 (UTC)[reply]

Support. Minor change to procedure that will bring a small efficiency gain. Sam Blacketer (talk) 23:39, 10 January 2010 (UTC)[reply]

Makes desysopping local; less chance of a steward doing an action which he is ill-informed about. More transparency. —Dark 23:56, 10 January 2010 (UTC)[reply]

Better log system if we kept it local, and a one-way "flip of the switch" doesn't make much sense. It seems like the logical choice to enable this. Killiondude (talk) 00:21, 11 January 2010 (UTC)[reply]

Seems sensible. Cirt (talk) 00:26, 11 January 2010 (UTC)[reply]

Support I have believed this for a long time. Icewedge (talk) 00:42, 11 January 2010 (UTC)[reply]

Keep it local. I said it at CDA, and I'll say it again: 'crats are elected to judge RfX consensus and grant the +sysop and +crat flags. Let's give them a job they were basically meant to perform. JamieS93 01:19, 11 January 2010 (UTC)[reply]

I've never understood why the bureaucrat toolbox has lacked this ability. I've also been a pretty vocal advocate for there eventually being a community-mandated system in place for removing administrators, and as I consider such a process to be in the (eventual) purview of the bureaucrats, it makes sense for them to have that ability. EVula // talk // ☯ // 01:20, 11 January 2010 (UTC)[reply]

Oppose

There is no current community process that would require bureaucrats (or anyone) to "uncheck the box" on adminship. I think that enabling the technical ability for crats to desysop should be a follow-up step to the creation of such a process. Additionally, bureaucrats have not been selected for any tasks aside from those they already perform. The type of scrutiny applied to candidates when the ability to desysop is at stake is likely to be quite different than what they currently undergo, and I'm not sure we necessarily want to grant this right to all bureaucrats (particularly those who were selected 5 or more years ago). There will be a time to re-evaluate the role of a bureaucrat with respect to any desysopping process; it will be after such a process is developed or even approaches consensus. I am generally opposed to granting bureaucrats expansive new roles, particularly in dispute resolution and in controversial processes, and I don't see a convincing argument here to change my position. Nathan^T 16:18, 10 January 2010 (UTC)[reply]
To address the "emergency/voluntary" situations directly: has there been a problem with such requests through stewards in the past? I'm not aware of any situation where a delay encountered by the inability to reach a steward caused any significant problems in this project. Nathan^T 16:20, 10 January 2010 (UTC)[reply]
I do think that if there is a crat who desysops without consensus, they will be quickly decratted themselves. These crats were chosen to judge consensus fairly, and desysopping fits into the category of consensus-judging as sysopping. (X! · talk) · @727 · 16:26, 10 January 2010 (UTC)[reply]
Desysopping is not currently based on community consensus (nor should it be), so there it is not relevant to the current or historical purview of bureaucrats. Chick Bowen 19:04, 10 January 2010 (UTC)[reply]
This proposal has no bearing on community desysopping. –Juliancolton | ^Talk 21:05, 10 January 2010 (UTC)[reply]
Then why does it mentioned it in the header?????? --Hammersoft (talk) 21:11, 10 January 2010 (UTC)[reply]
Huh? I don't think you understand. Stewards already routinely do desysops as instructed by ArbCom or the user's request. This proposal doesn't change when we do desysops, but rather how we preform them. –Juliancolton | ^Talk 21:15, 10 January 2010 (UTC)[reply]
The position of supporters is that it has no bearing. I disagree with that position; there is no misunderstanding. They are intrinsically related, whether or not one is strictly dependent on the other. To put it a different way, I do not believe we would be having this discussion if it weren't for CDA. Chick Bowen 22:12, 10 January 2010 (UTC)[reply]

Also, Hammersoft's point is quite correct: CDA is mentioned at the top of this page, so it's a little strange to claim that there's no relationship between the two. Chick Bowen 00:12, 11 January 2010 (UTC)[reply]

It is mentioned in as much that if it is implemented, then once the decision is made by whatever process CDA decides upon a crat can flip the bit instead of a steward. Antecedents and consequents. It is there for completeness, because it is in current discussion, but in no way shape or form does THIS proposal allow a crat to "make a decision". Even if CDA is approved, it is still not clear WHO makes the decision. This is solely about who can check and uncheck a box. -- Avi (talk) 00:20, 11 January 2010 (UTC)[reply]
I think your supporters are confused about that. For example, in #20, Joe says, "it's a logical step for them to determine when consensus exists for the bit to be removed," and in #21, Ironholds says, "'crats are trusted to determine consensus to promote; no reason to suggest they can't determine any consensus to demote." Their rationales suggest that they are indeed imagining bureaucrats determining consensus, not just flipping the metaphorical switch. I believe you that this was not your intention, but I'm not sure it was as clear as it might be. Chick Bowen 00:27, 11 January 2010 (UTC)[reply]
I think that it's a natural jump to make (one I myself made in my comment), but that doesn't change the fact that this proposal is about the 'crats being able to uncheck a box (and only that). There's a relationship, yes, but not necessarily a direct cause-and-effect between the two proposals. We can have a community-dictated de-adminship system without 'crats unchecking the box, it's just more convenient if they can uncheck, just like we can have 'crats capable of removing bits upon request without having a CDA. EVula // talk // ☯ // 01:26, 11 January 2010 (UTC)[reply]

I thought it was clear in the description (as did others, see the talk) and I added a clarification nutshell. Other than renting a megaphone, I'm not sure what else I can do 8-). Any ideas? -- Avi (talk) 00:35, 11 January 2010 (UTC)[reply]
So what are you suggesting, that bureaucrats should only desysop if the CDA being closed is 100% in favor of desysop???? Come on. This proposal IS linked to CDA. You can't tell me we're not going to have bureaucrats making the decisions at CDA. Unless you intend on creating an entirely NEW class of users who are responsible for determining consensus at CDA. That's not going to happen and you know it. No sense in creating a new class when we already have a class that does the same thing (if in reverse). --Hammersoft (talk) 01:26, 11 January 2010 (UTC)[reply]

No, that when somoene comes to voluntarily relinquish the bit, they do not have to go to meta to get it turned off, but can come to WP:BN the same way they do to get it back (uncontroverisal, of course). When ArbCom decides that such-and-such user needs to be desysopped based on an RFaR, they can ask a local crat instead having to go to Meta. It's rather clear, actually. -- Avi (talk) 01:33, 11 January 2010 (UTC)[reply]
And has asking a non-local person ever been a problem? Doesn't seem so. Has going to meta to turn off your bit ever been a problem before? I don't recall any incidents. What problem is this supposed to solve that is currently hampering the project? In a word, nothing. That's what. And I'm sorry, I find it odd that a user here with virtually every bit is asking for yet another power to add to his cap. That bothers me. --Hammersoft (talk) 01:41, 11 January 2010 (UTC)[reply]
Oppose Solution looking for a problem. First WP:CDA has not achieved acceptance (nor is it likely to), so there won't be some sudden flood of de-adminship requests. Second, ArbCom is well capable of de-adminning someone, and once requested it's not something that needs rapid resolution. Third, the need of a steward's presence to emergency desysop someone has always been met rapidly. The supporters of this should at least show one case where the project was damaged because a rogue admin wasn't removed in a timely manner. Fourth It's already damned difficult to become a bureaucrat. Adding another privilege to the mix is going to make it impossible. --Hammersoft (talk) 20:18, 10 January 2010 (UTC)[reply]
I believe you are misunderstanding this proposal. This proposal adds no new judgement to desysop someone. Just whenever we would ask a steward to to remove a bit, we can now ask a 'crat. -- Avi (talk) 21:44, 10 January 2010 (UTC)[reply]
I am misunderstanding nothing. CDA is mentioned in the intro to this proposal. I am not making a mistake. If I am, then you should be addressing the person who formed this RfC, namely yourself, not I. --Hammersoft (talk) 01:26, 11 January 2010 (UTC)[reply]

See above where I answered you, and yes, you somehow missed the antecedent of the hypothetical syllogism. I've said this a bunch of times on this board already, but for you I'll say it again. IF CDA ever comes around and should it do, IF whatever decision process be accepted in the proposal actually happen (be it a community vote, an RfAR, or the collected writings of a thousand monkeys) ONCE the decision is made by WHATEVER process is decided upon to be valid, THEN you can go to a crat and not a steward. Most often, this will deal with the requests we get at WP:BN for people who want to take a vacation from their bits that right now we have to send to the stewards. -- Avi (talk) 01:33, 11 January 2010 (UTC)[reply]
We are NOT going to be creating an entirely new class of user to decide CDA. It will be up to bureaucrats. --Hammersoft (talk) 01:41, 11 January 2010 (UTC)[reply]

Neutral

See detailed explanation below. MBisanz ^talk 21:05, 10 January 2010 (UTC)[reply]

Discussion

If this proposal passes, bureaucrats will have the technical ability to desysop administrators. Avi also proposes giving them the ability to de-crat fellow bureaucrats. That part is not really discussed in the sections above. So without taking a stance on the issue myself, I'd like to pose the question: Should bureaucrats have the technical ability to de-crat other bureaucrats as well, or should that only be reserved for stewards? A Stop at Willoughby (talk) 18:25, 10 January 2010 (UTC)[reply]

I think it's the same question. They are after all able to grant +crat as well so it's only logical that they should be able to de-crat as well. Regards So Why 18:51, 10 January 2010 (UTC)[reply]

Yeah, basically. It's not exactly a common process, so there's not too much to worry about. Besides, if de-cratting was something that ever needed to be done ASAP, we might as well have the chance for someone here to do it faster, and for nicer logs. ~ Amory (u • t • c) 19:02, 10 January 2010 (UTC)[reply]

All the comments above (in support and here) have said it better than I. In a nutshell, a 'crat can check the box on for another 'crat, after a successful RfB or a return to 'crat status after a vacation (ala WJB Scribe), so it is logical that they should be able to uncheck the box, in situations where the box needs to be unchecked (voluntary vacation, ArbCom, emergency, and, if CDA ever gets implemented, in that case too). This RfC is not about which situations get an uncheck, but given an English Wikipedia valid situation for an uncheck, who may check the box. For symmetry, efficiency, and keeping the logs here, it makes sense, in my opinion, that 'crats are able to do so. -- Avi (talk) 20:06, 10 January 2010 (UTC)#[reply]

At the end of the day, there is really no danger in implementing this; certainly far less danger than giving someone the bit in the first place. Any bureaucrat who goes rogue will soon find themselves without the bit, and the damage done is very simple to reverse. There is far more risk giving someone the bit, as they could allow unruly bots, and administrators (albeit for not very long before being caught). Solution without a problem or not, I don't see any harm from this and potentially a lot of benefit. Regards, --—Cyclonenim | Chat 20:46, 10 January 2010 (UTC)[reply]
There are several reasons I have opined in the neutral on this proposal.

Stewards will not act if a local wiki has the ability to do something. That means if crats can deflag an admin, stewards will not do it. This is their policy and not ours, so if we approved this change, crats would become the only people capable of de-adminning. Given that the stewards already have an emergency request system in place and are positioned around the globe to give 24/7 coverage and the crats are biased towards English-speaking countries, this would result in a decrease of coverage.
If someone can do something, they will. We saw how the turning on of the ability to grant rollback was done before we had a policy on granting it, and I believe this is putting the cart before the horse.
While crats would in theory (at least I would) only de-flag on user request or on arbcom decision, this new capacity would put crats in the uncomfortable position of seeing a consensus to do something, but being restrained by policy from doing it. I am thinking of several user conduct RFCs and admin recalls which indicated a broad consensus that someone should resign as an admin and pair that with the moans that arbcom is a cabal refusing to desysop fellow admins quickly. The same complaints would be placed on crats who refuse to implement an RFC or admin recall decision.
Stewards by their nature are impartial since they do not edit enwiki. Crats are by their nature highly involved in enwiki affairs. Desysopping, both due to the social stigma of it and the social consequences for the person performing it, seems better left to entirely uninvolved parties.
Finally, I am aware of at least one crat war at meta-wiki, where a crat closed an RFB as a promotion and another crat disagreed and undid the promotion. As of now this technical feature prevents such an event from occurring and I am not certain that changing it permit such an event to possibly occur is wise.
However, I do agree that the split enwiki and meta logs are annoying and that it would be better if all transactions were placed in the same log.
Additionally, I agree it makes sense that things on the wiki should be able to be undone by the person performing them.

But, I also think that crats should not be seen as aggrandizing more power, even technical, to themselves, so that is why I am neutral on the proposal. MBisanz ^talk 21:04, 10 January 2010 (UTC)[reply]

Re (1), the hundreds of suppressions by stewards on enwiki suggest this is no longer the case. If we make it clear we are happy for stewards to continue to desysop in emergency cases, I am sure they will to do so even if crats gain the ability to do so as well. WJBscribe (talk) 21:47, 10 January 2010 (UTC)[reply]

I can't refute point two, but points three and four seem to be focused around the same idea of a 'crat being biased towards a decision if they're somehow involved in the "enwiki affair". Why is this any different to any system we have in place today? It has always been a firm advisement that administrators, bureaucrats or arbitrators remain uninvolved in situations where they may have a conflict of interest. I don't see why bureaucrats would not do the same in this situation. I don't have experience in administrative or bureaucratic activities so I may be severely misinformed, but that's how I see it. Regards, --—Cyclonenim | Chat 22:05, 10 January 2010 (UTC)[reply]

I don't think MBisanz is so much saying that an involved 'crat would take an action, but rather that people might perceive it as such (desysops always leave someone unhappy). It could make 'crats more of a target than they are now, as opposed to Stewards, who are decidedly neutral and largely beyond such petty criticisms. ~ Amory (u • t • c) 22:30, 10 January 2010 (UTC)[reply]

Interesting point, but if that is the case then it really is entirely irrelevant, because what Wikipedians percieve is irrelevant. What is true is what counts, at least in theory. We trust bureaucrats to make consensus-based decisions, and if they cannot act impartially, as Avi says below, they should not be a 'crat and that would most likely be picked up by the community/other 'crats. Regards, --—Cyclonenim | Chat 22:44, 10 January 2010 (UTC)[reply]

Hi, Matt. Let me try and address your concerns individually:

That is a policy specific to oversight and checkuser, I beleive, not switching bits, as the steward has to grant themselves the CU/OS on the wiki prior to running the check. This is different firstly, as changeuserrights is something stewards have by nature anyway, and two, all of us are clear that we would like them to be available in cases of emergency (as they are in CU/OS anyway). When it is not an emergency, keeping everyting on EnWIki instead of Meta is sensible.
Which is why this RfC is coming BEFORE any requests to developers to change the 'crat rights package. Only if this has a consensus will the developers be approached to adjust the crat package.
And so? We have strict policies on EnWiki regarding these situations. If a bureacrat cannot be trusted to adhere firmly to the policy and guideline despite personal discomfort, that person should not be a 'crat.
Lar does not edit Enwiki? Bastique does not edit EnWiki? Pathoschild does not edit EnWiki? etc.
So for one instance we should prevent something sensible? And let us say that happens with a bot - which can have its bit removed by crats? That is similar to blocking/unblocking, which we allow even though the potential for a wheelwar exists. If that happens again, ArbCom can be called in. Anyway that is less likely because of chats.
Concur
Concur

-- Avi (talk) 22:31, 10 January 2010 (UTC)[reply]

Ok, but they actually aren't allowed to run CU's in an emergency, as we saw during numerous grawp-attacks when no local checkuser was available or during that weird grawp-attack that required an account to be renamed, in neither case did or could a steward step into the local wikis shoes since we are too large to qualify for small wiki monitoring efforts.

Second, Lar, Cary, and Pathoschild do not do rights changes on enwiki specifically because the steward policy prevents them. MBisanz ^talk 23:38, 10 January 2010 (UTC)[reply]

Re #1, They would have, I believe, had need been severe enough. Re #2, my point was that stewards edit here frequently and can be trusted to control themselves, so merely being frequent editors of a wiki does not make someone have an inherent COI --either steward or crat. -- Avi (talk) 00:02, 11 January 2010 (UTC)[reply]

I think Matt's point #3 is an excellent one and I don't is adequately addressed by anyone here. After all, the word "consensus" is used frequently on this page even though there is no process to desysop by consensus (since arbcom doesn't work by consensus but by strict voting). This suggests that there is already confusion about what circumstances will lead to desysopping. My concern (and I gather Matt's) isn't that the bureaucrats will succumb to that confusion but that other people will. Chick Bowen 00:11, 11 January 2010 (UTC)[reply]

That is an error on the part of the people using the word then; I think I re-clarified in the nutshell above that there is no decision being made here. There is no change to what causes a desysop, only who implements the valid decision. -- Avi (talk) 00:22, 11 January 2010 (UTC)[reply]

What problem is this supposed to solve?

Could someone please answer the simple question of what problem this is supposed to solve? --Hammersoft (talk) 01:31, 11 January 2010 (UTC)[reply]

Having to send requests for bit vacations to Meta and not handling it on EnWiki
Having the +bit and -bit logs on two separate projects
Preventing an accident from being corrected quickly (only happened once though)

-- Avi (talk) 01:35, 11 January 2010 (UTC)[reply]

Ok, in order (1) has this ever been a problem? Requests not handled properly or timely? Backlogged? (2) Does having the logs on separate projects create some problem I'm not aware of? (3) Only happened once and it's a problem to solve? --Hammersoft (talk) 01:38, 11 January 2010 (UTC)[reply]

Can we go on as we are doing now? Of course. However, the purpose of this RfC is to determine whether or not the project and its members believe that we can do things better. Many people beleieve the proposal is better; you do not. You are more than welcome to both feel that way and to post your opinions as clearly and forcefully as you can to best state your case. That's exactly what the RfC is for. Howeever the mere fact that things are function now is no excuse not to explore what may be better options. Having local people doing local project work and keeping the logs in one place is preferable to me, and apparently many others. -- Avi (talk) 01:41, 11 January 2010 (UTC)[reply]

@@ Line 60: / Line 60: @@
 #::::So what are you suggesting, that bureaucrats should only desysop if the CDA being closed is 100% in favor of desysop???? Come on. This proposal IS linked to CDA. You can't tell me we're not going to have bureaucrats making the decisions at CDA. Unless you intend on creating an entirely NEW class of users who are responsible for determining consensus at CDA. That's not going to happen and you know it. No sense in creating a new class when we already have a class that does the same thing (if in reverse). --[[User:Hammersoft|Hammersoft]] ([[User talk:Hammersoft|talk]]) 01:26, 11 January 2010 (UTC)
 #:::No, that when somoene comes to voluntarily relinquish the bit, they do not have to go to meta to get it turned off, but can come to [[WP:BN]] the same way they do to get it back (uncontroverisal, of course). When ArbCom decides that such-and-such user needs to be desysopped based on an RFaR, they can ask a local crat instead having to go to Meta. It's rather clear, actually. -- [[User:Avraham|Avi]] ([[User talk:Avraham|talk]]) 01:33, 11 January 2010 (UTC)
+#::::And has asking a non-local person ever been a problem? Doesn't seem so. Has going to meta to turn off your bit ever been a problem before? I don't recall any incidents. What problem is this supposed to solve that is currently hampering the project? In a word, nothing. That's what. And I'm sorry, I find it odd that a user here with virtually every bit is asking for yet ''another'' power to add to his cap. That bothers me. --[[User:Hammersoft|Hammersoft]] ([[User talk:Hammersoft|talk]]) 01:41, 11 January 2010 (UTC)
 #'''Oppose''' Solution looking for a problem. '''First''' [[WP:CDA]] has not achieved acceptance (nor is it likely to), so there won't be some sudden flood of de-adminship requests. '''Second''', ArbCom is well capable of de-adminning someone, and once requested it's not something that needs rapid resolution. '''Third''', the need of a steward's presence to emergency desysop someone has always been met rapidly. The supporters of this should at least show ''one'' case where the project was damaged because a rogue admin wasn't removed in a timely manner. '''Fourth''' It's already damned difficult to become a bureaucrat. Adding another privilege to the mix is going to make it impossible. --[[User:Hammersoft|Hammersoft]] ([[User talk:Hammersoft|talk]]) 20:18, 10 January 2010 (UTC)
 #:I believe you are misunderstanding this proposal. This proposal adds no new judgement to desysop someone. Just whenever we would ask a steward to to remove a bit, we can now ask a 'crat. -- [[User:Avraham|Avi]] ([[User talk:Avraham|talk]]) 21:44, 10 January 2010 (UTC)
 #::I am misunderstanding nothing. CDA is mentioned in the intro to this proposal. I am not making a mistake. If I am, then you should be addressing the person who formed this RfC, namely yourself, not I. --[[User:Hammersoft|Hammersoft]] ([[User talk:Hammersoft|talk]]) 01:26, 11 January 2010 (UTC)
 #:See above where I answered you, and yes, you somehow missed the antecedent of the hypothetical syllogism. I've said this a bunch of times on this board already, but for you I'll say it again. '''IF''' CDA ever comes around and should it do, '''IF''' whatever decision process be accepted in the proposal actually happen (be it a community vote, an RfAR, or the collected writings of a thousand monkeys) '''ONCE''' the decision is made by '''WHATEVER''' process is decided upon to be valid, '''THEN''' you can go to a crat and not a steward. Most often, this will deal with the requests we get at WP:BN for people who want to take a vacation from their bits that right now we have to send to the stewards. -- [[User:Avraham|Avi]] ([[User talk:Avraham|talk]]) 01:33, 11 January 2010 (UTC)
+#::We are NOT going to be creating an entirely new class of user to decide CDA. It will be up to bureaucrats. --[[User:Hammersoft|Hammersoft]] ([[User talk:Hammersoft|talk]]) 01:41, 11 January 2010 (UTC)
 ===Neutral===