User talk:EVula/opining/RfA overhaul

All discussion for the first round of this page has been archived at User talk:EVula/opining/RfA overhaul/archive, round 1.

One-year trial with ArbCom endorsement required?

I like the overhaul. I'm thinking that this should go into operation, but not be binding; a "successful" RFDA would essentially be a referral to ARBCOM for action; ARBCOM would then make the final decision, using the RFDA as the basis. This would obviate the need for a formal request for arbitration, because all the evidence and statements would already be at the RFDA. Then, after a year we can have an RFC on how the RFDA system has worked, and consider whether to make it binding, continue as is, or can the whole thing. Thoughts?--Aervanath (talk) 03:19, 8 July 2009 (UTC)

Well, if the RfDA process is modeled after the RfA process, it's a simple matter of the closing 'crat gauging consensus, rather than an individual or group (be it 'crats or Arbs) gauging the candidate. I worry that attaching ArbCom will attach the lengthy bureaucracy as well; I think the ideal system should be very slim... although my first proposal was a bit too slim for some. This one has a bit more meat on its bones.

I think the key elements to the RfDA process are the community having their voice heard (akin to RfAs) and it running for a short but not insignificant amount of time (a week, similar to RfAs). I worry that attaching ArbCom would inhibit those to a certain degree (though I obviously don't think ArbCom would demote a user that's got a 90% support rate, or keep someone that's got 52%), though if ArbCom is just attached while this thing finds its footing, I'd be fine with that. EVula // talk // ☯ // 03:39, 8 July 2009 (UTC)

Keeping ArbCom attached while it finds its footing was more my idea. The reasoning behind keeping ArbCom as a check to it for a lengthy period of time is that currently ArbCom generally only takes cases which have been through prior dispute resolution steps. For an admin, this would generally mean an WP:RFC/U, which usually lasts for a month, and then another multi-week WP:RFAR with the initial statement and evidence pages and additional discussion that precedes a final decision. In this case, it would still go through ArbCom, but would shortcut the WP:RFC/U and normal WP:RFAR processes; the WP:RFDA would only be a week, the closing bureaucrat would make the decision to refer the case to ArbCom (or not refer it, as appropriate), and then ArbCom can have a simple up-or-down vote on whether to desysop, which would at most take a few days. At that point, the normal process would take over, with an ArbCom clerk making the steward request at Meta. (Although we might want to start asking stewards to grant themselves userrights privileges on en.wiki when this happens, and then doing the desysopping here, so there's an internal record in the former admin's userrights log. But that's a totally different proposal.) So, with my modification to your proposal, we'd have at most a two-week interval from transclusion of the RFDA to desysopping, whereas now the process can take months. While this isn't as fast as your proposal, which would, at most, take a week, it's still shorter than the current process, and (in my opinon) more likely to be accepted by the community.--Aervanath (talk) 07:31, 8 July 2009 (UTC)

I was really tired when I wrote my above response, which is why I totally missed out on the temporary nature of the ArbCom tie-in. :) EVula // talk // ☯ // 17:28, 12 July 2009 (UTC)

No sweat. :) --Aervanath (talk) 17:32, 12 July 2009 (UTC)

RFDA

I definitely think this is something we need. Somewhere in-between RFC/U and the almighty ArbCom should be a community procedure where the day-to-day editors can express a consensus that an admin. is not using the tools in the proper manner. Perhaps if this RFDA procedure existed - the entire RfA ordeal would be less of an ... ordeal. — Ched :  ?  05:01, 9 July 2009 (UTC)

On the last item on this proposal - not sure I can speak to the "handsome" part - I haven't seen the BRC pic, and it's doubtful if I'll make the Nashville meet-up., ;) — Ched :  ?  05:08, 9 July 2009 (UTC)

Your loss! ;) EVula // talk // ☯ // 16:50, 12 July 2009 (UTC)

I know I'm approximately a year late on this one; what happened with it? And why not an RfDA that is exactly the mirror of RfA, which would mean for instance:

• Anyone can nominate, hopeless nominations closed per WP:SNOW
• 70-something percent support needed to desysop
• standard and optional questions for elaboration
• crat closes discussion

A few minor things would have to change, for instance a SNOW nomination could lead to a warning, and a steward would have to endorse the closing 'crat's decision, but otherwise... --Pgallert (talk) 15:14, 1 June 2010 (UTC)

Too complicated and bureaucratic (do term limits instead)

Have re-elections after 2-3 years instead. There are a huge number of inactive admins who would be culled (no loss). The page has the room for it. It would change the dynamic on initial elections (giving an out). It would change behavior of some of the more arrogant moderators.

The concern has been raised that no one would ever block, but I don't buy it. HJ Mitchell got reelected just fine and he had done some blocks. You should trust the community more.

As is now, the whole thing is a roach motel and some content creators don't even want to come and participate. you would have a whole different dynamic with reelections. — Preceding unsigned comment added by TCO (talk • contribs)

Reelections work on smaller projects (like Wikisource), but I'm not convinced that they would work well here. This is partially due to the sheer size of our admin pool, but also the fact that, frankly, sometimes admins need to piss people off. Vandals and spammers don't like it when we walk all over their hard work, but oh well. For reelections, they'd come out of the woodwork. By making it so RfDAs can only be filed with evidence of abuse, the average axe grinder's opportunity to throw someone to the wolves is mitigated.

As for trusting the community, the whole point of this system is to put the choice in the hands of the community. Also, having scheduled reelections doesn't actually do much to remove bad-fit admins semi-immediately. If there's a shitty admin doing stuff, the earliest they could be removed is in a year or so; that doesn't strike me as the best solution to the problem. EVula // talk // ☯ // 16:51, 11 July 2013 (UTC)

New Concern: I don't think it would make individuals view RfA as "less of a Big Deal"

I was wondering what your/Xeno's (and anyone else who cares to respond, but that wouldn't mean I wouldn't still like a response from the proposers) thought would be on this issue.

If the primary purpose of this is to encourage editors to think picking an admin as less final, and thus warranting less...aggressive consideration then I don't think it will succeed.

It could still be beneficial just as a method of removing admins via a community consensus process, but its primary goal seems potentially wishful thinking. Nosebagbear (talk) 17:00, 3 April 2019 (UTC)

That's actually why I never put it forward four years ago. It has the potential to deplete the existing administration pool, and could even discourage applications (why put myself up for a position where the potential for an RfDA exists), rather then encourage participants to be less circumspect. Further reading: Special:PermanentLink/671056303#Additional bureaucrat tasks –xeno^talk 17:32, 3 April 2019 (UTC)

I tend to agree with Nosebagbear that this proposal won't fundamentally change RfA - most concerns I see these days are about temperament of the nominee or application of existing policies (as the questions about edit count and other "checkbox" items seem to be in decline). As such, I have my doubts that this proposal would change attitudes at RfA, but it would seem to be beneficial for other uses. --Enos733 (talk) 20:28, 3 April 2019 (UTC)

I think your thoughts that editcountitis et al are reducing may be a tad optimistic - we get so few admins through that it's quite hard to tell if it's a trend or if the most recent admins just happen to have satisfied them and thus it's not really shown up. Nosebagbear (talk)

Personally, I'd try to get consensus for certain minimum levels of edits, articles created/grade created, etc that once reached, any oppose on those grounds would be discarded (e.g. If an editor had 14000 edits, then any opposes per too few edits wouldn't be counted). However I guess too much of the community wouldn't want to impose limits on their discussion rights. Nosebagbear (talk) 20:42, 3 April 2019 (UTC)