Wikipedia talk:Community de-adminship/Draft RfC Archive 2

Certification vs Quorum

Rather than clutter the above sections (since this crosscuts two of them), I'd like to raise this down here before bringing it back up there. Right now we have the somewhat strange idea that 10 must certify within some period of time, and then 50 total must support removal total at the end. Why is this two separate ideas? Why not just eliminate the idea of "certification" and just have a minimum number of people supporting removal before the end of the period? Why do we need to have what amounts to two separate and overlapping quorum requirements? Gigs (talk) 23:25, 24 November 2009 (UTC)

To further clarify, this seems to me to be effectively pushing the early voting discussions off-wiki or at a minimum to user talk pages, while simultaneously silencing those who would oppose desysop until the first 10 votes are done. This seems counterproductive to me. Gigs (talk) 23:34, 24 November 2009 (UTC)

Think of it as a petition drive. If you can't get 10 people to "sign a petition" up front before formal discussion starts, then the process will be swamped by snow-close nominations. It's a trade-off between less transparency vs. much more overall efficiency. davidwr/(talk)/(contribs)/(e-mail) 03:08, 25 November 2009 (UTC)

I really don't like the idea that we will tolerate and encourage violations of wp:canvass for this.

People will have to:

• Spam at least 20 editors in order to get 10 that might co-nominate within the time limit. That pretty much fails the first prong of the canvass test regarding the scale of the canvassing.
• Canvass with an inherently biased message, you can only ask them to come support the desysop effort, you can't ask them to simply lend their opinion, since only people who support desysop can co-nominate. No one can oppose desysop until this "petition phase" is over, so it's impossible to solicit neutral input during this canvassing.
• Canvass a partisan audience. The examples given so far regarding this canvassing have been "hey you've been screwed by admin X, come nominate him with me". This is inherently a partisan audience.
• Probably wind up doing it on back channels, because of all the other problems above. This violates the transparency prong of the canvassing guideline.

So we will be creating a system that violates or encourages violation of every prong of the test given in the canvassing guideline. Creating a process that requires those using it to blatantly violate a behavioral guideline seems like a big mistake to me. It's a trade-off that we don't need to make, and a totally unnecessary trap for any would-be nominee. Gigs (talk) 14:37, 30 November 2009 (UTC)

I don't see this as an issue, as there will no doubt be a "new nominations" page where nominations live from their first nomination until they gather the required 10 signatures. People who follow RFA, etc. will likely follow this page. Likewise, there will no doubt be talk-page notices on the affected administrator's talk page, and people who have a specific interest in that administrator will likely be watchlisting the page. davidwr/(talk)/(contribs)/(e-mail) 15:37, 30 November 2009 (UTC)

This question also came up in the first section of the now-archived discussion of 10 editors to open. I agree with davidwr that scrutiny by the community will cover the issue better than a rule here would. It seems to work with RfAs, and it's really just a matter of applying the existing WP:Canvass. --Tryptofish (talk) 19:55, 3 December 2009 (UTC)

Before a CDA nomination

This may be premature considering that the CDA process has not even been formally proposed yet (and when it has, it has been rejected), but I think it would be a good idea for those editors working on this proposal to think about some principles of "what to do before a CDA nomination" while drafting this RfC.

I would suggest that at least the following steps should be taken before to any CDA nomination, and #2 should be mandatory:

1. An attempt to address the disputed behaviour(s) or issue(s) through direct discussion with the administrator;
2. An attempt to address the disputed behaviour(s) or issue(s) through community discussion at an appropriate venue (e.g., AN, RfC, AN/I, and so on);
3. A request to submit to voluntary re-call of admin privileges and, if desired, to re-apply for adminship through the WP:RFA process.

Assuming that the complaint against the admin is valid, then there would be a resolution in the absolute majority of cases by the end of the second step. For the few cases where the problem persists, a request for voluntary re-call by one or a few marginally-involved editors (the purpose of starting a community discussion is to invite the attention of these people) should do the trick most of the time.

I think it is important to consider this matter for two reasons: (1) it is relevant when deciding the purpose and structure of any CDA process; and (2) it is relevant when evaluating the need for a CDA process. At this time, I am neither strongly for nor strongly against the idea: I like the idea of a non-ArbCom process to de-admin, but I dislike the idea of another bureaucratic and drama-prone process. If, say, 95% of valid complaints/disputes can be resolved without any bureaucracy, then how much is really gained by having another formal process? –BLACK FALCON ^(TALK) 20:48, 12 December 2009 (UTC)

I agree with the substance of that. However, I think that the draft proposal does say most of those things already, and there are proposals above to spell them out further. --Tryptofish (talk) 20:51, 12 December 2009 (UTC)

Wikipedia:Guide to Community de-adminship#Before nomination does touch on this, but the wording is quite weak. It encourages users to take these steps, but does not make them prerequisites to a CDA. It also does not address the question of necessity, but of course I realise that the proposal is still being worked on and the final version proposed at RfC may be different. –BLACK FALCON ^(TALK) 21:13, 12 December 2009 (UTC)

If you can suggest further wording (please see also proposal 16, section 11 above), that would be very good. --Tryptofish (talk) 21:17, 12 December 2009 (UTC)

Thank you for pointing out that section to me, as I had actually missed that one... I've now indicated my support for that proposal, which takes care of most of my concerns. I would like to suggest only one addition, something to the effect of: "A CDA request may be initiated only after substantial community discussion at a suitable venue, such as Wikipedia:Administrators' noticeboard or Wikipedia:Requests for comment/User, has failed to produce a resolution." –BLACK FALCON ^(TALK) 05:18, 13 December 2009 (UTC)

Agree. It should be made completely clear that this process of Community de-adminship is a last resort and must be rejected or tabled, 10 nominations and all, if there has not been (to use Black Falcon's term) substantial discussion about the issue of the administrator's alleged problems beforehand. This will help ensure that the process will not be abused. Jusdafax 07:01, 13 December 2009 (UTC)

Yes, I agree with that too. I think that it is one of those things that everyone sort of assumed without previously noticing that it hasn't been stated explicitly. --Tryptofish (talk) 17:25, 13 December 2009 (UTC)

Proactively scheduled review

Without comment on specific proposals, I'd like to suggest that any community desysop proposal that might be adopted should contain a proviso to review the functioning of the process after the first few cases. For example, after the first 5 cases in which a community desysop is entertained, there would be a pause in the process for a formal evaluation of how well it's worked, where it might have fallen down, and how it might be tweaked or improved. If this sort of pause for reflection isn't written into the proposal, it would be naive to expect it to happen spontaneously. Just my 2 cents. MastCell ^Talk 22:27, 14 December 2009 (UTC)

That's a good idea. Perhaps having a talk page associated with the process page could serve that function, in a continuous way? Similar to WT:RFA, perhaps. --Tryptofish (talk) 23:11, 14 December 2009 (UTC)

Reasons for speedy close

We should have an essay on reasons to speedy close a nomination. They could be sockpuppet or meatpuppet nominators, fraud, overwhelming support for the administrator, reasons that would mean a speedy delete in an article (attack page, copy vio). Who can close early? - a Bureaucrat? Graeme Bartlett (talk) 11:35, 27 November 2009 (UTC)

Agree - Good thought. I would think a 'crat would be making the call. Welcome further comment, it's an important point. Jusdafax 19:18, 27 November 2009 (UTC)

I have a question: would this apply during the period of the 10 nominations, or during the 7 days that follow? Perhaps the nomination process will help weed out some of these problems; so should a Crat certify the nomination before it goes to the community? --Tryptofish (talk) 19:22, 27 November 2009 (UTC)

I'd like to see a bureaucrat be able to step in and shut a clearly compromised/gamed nomination and/or vote down at anytime for any good reason, up to and including WP:SNOW. So far only one 'crat has commented regarding this overall de-admin process (also one whose closing vote status in in discussion) but it may be that they think commenting is a COI. Jusdafax 00:10, 28 November 2009 (UTC)

I'm not sure we need new rules, the informal rules we already have in place for speedy-close such as bad-faith nom or white fluffy ice crystals do fine. In general, if this is to be a mirror of RFA then the general unwritten practices at RFA would probably carry over. davidwr/(talk)/(contribs)/(e-mail) 21:24, 28 November 2009 (UTC)

Maybe we do though, because I think if people really trusted a robust system for speedy closing, they wouldn't be insisting on what seem to me to be ridiculous requirements to get one of these CDA's open. Gigs (talk) 13:14, 30 November 2009 (UTC)

Agree that to get this entire Cda proposal all the way to the finish line (an approved, working Community de-adminship process will by its very existence give the entire encyclopedia additional credibility, and give admins who currently indulge in edgy-to-bad behavior some pause) we need to make it utterly clear how this Cda process has transparent oversight to prevent/halt misuse. A short statement making it clear that a 'crat can speedily close a Cda, and why, clears the air around this. Jusdafax 20:37, 13 December 2009 (UTC)

If it's clearly frivolous and/or snowing in favor of opposing, then just as with RFA, there shouldn't be much of a problem even for a regular uninvolved admin to IAR and close it instead of having to get a crat do it. –MuZemike 23:15, 22 December 2009 (UTC)

"All editors"

"Anyone may participate in the discussion" should include a clause that discounts sockpuppets and a way to remove sockpuppet !votes. ηoian ‡orever ηew ‡rontiers 03:44, 25 December 2009 (UTC)

Yes, that's a good point. --Tryptofish (talk) 14:59, 25 December 2009 (UTC)

Currently banned editors too. --Tryptofish (talk) 15:13, 25 December 2009 (UTC)

And people being intentionally disruptive. Chillum ^{(Need help? Ask me)} 15:46, 25 December 2009 (UTC)

Currently blocked (as distinct from banned) editors should be allowed partake as they will include the victims of Admin abuse. Sarah777 (talk) 15:17, 31 December 2009 (UTC)

Actually, when I wrote "banned", I paused over the block issue for exactly that reason. It's complex, because sometimes blocked users should be allowed to !vote, but sometimes they should not. Do we need some language to the effect that they may !vote only if they have been blocked by the admin being reviewed and if that block is materially-related to the reasons for the review? --Tryptofish (talk) 15:24, 31 December 2009 (UTC)

And so it begins. --Kim Bruning (talk) 16:40, 26 December 2009 (UTC)

Anon editors (IP only) should be allowed to vote and comment, but perhaps they should be given their own voting section. The would remove the desire by some to strike all IP-only votes and would also allow their comments to be noted (or ignored) if anyone wants to bother. I prefer IP editing and feel that it forces one to focus on the raw edit itself, rather than relationships with other named editors. 216.153.214.89 (talk) 06:45, 26 December 2009 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Short-circuit / Rapid System Development

The other thing that's interesting is that this is a (!)poll on whether to close a (!)poll. One could have predicted upfront that that would give you odd results. I joked to someone off-wiki yesterday that I was tempted to make a poll on closing the poll to close the poll ;-) (don't actually do that: WP:POINT, WP:BEANS).

What's pretty clear to me though is that there's no real discussion being held. People are basically !voting on !points. What's going to happen on this page is that we're going to end up with a patchwork Frankenstein design. You *DO* realize that we're trying to design a system, right? I don't think anyone has ever even seriously proposed doing Systems design by vote. :-P

I'm making it a personal rule to always try to contribute something towards a solution. To that effect, here's some requirements that the final process needs to meet / properties it needs to have:

• (standard requirement) The system needs to be non-exploitable. This is easily achieved by keeping humans in the loop, and giving them plenty of leeway. As a corollary, making things automatic or based on numbers alone will typically open loopholes; so Don't Do That.
• (standard requirement) It is often wise to exploit the "natural" self organizing properties of the wiki itself, as opposed to stacking layer upon crufty layer of "artificial" governance on top.
• (specific requirement) Counter-balance: Some areas of admin-work cause people to slowly accumulate enemies (for instance: if you block someone, they're likely to oppose your continuing adminship). We need some way to counter-balance that effect.

Questions:

• Are there requirements I'm missing?
• Do these requirements need modification; if so, what modifications are needed?
• Can we figure out simple, self consistent designs that meet these requirements?

We can then figure out what system components (pages, templates, categories, people, methods of gaining consensus) can be fit together in what way to make an elegant system.

The above approach is systematic, gathers positive contributions from everyone (little to no disenfranchisement; as opposed to straight polling, where the minority opinion gets discarded), and is likely to lead to results quicker, somewhat ironically. ;-)

--Kim Bruning (talk) 14:52, 23 December 2009 (UTC)

I agree, using a poll to close a poll is silly, so we should stick to determining consensus to determine consensus, and let the people making arguments judge the strengths of the arguments. Angryapathy (talk) 19:13, 23 December 2009 (UTC)

Thank you, Kim. My proposal is that we make better use of existing processes. We can use RfC to gather evidence of abuse or poor judgment by admins, and get a consensus as to whether the community supports the admin or not. RfC's are tricky because somebody (or some people) very clueful need(s) to read the results. Grudge mongering, retaliation or point making need to be discounted. Meat puppetry and canvassing need to be evaluated. Votes need to be weighted by cluefulness. This is a tricky job best left to ArbCom. Since User:Newyorkbrad introduced the idea of motions, ArbCom can act very swiftly when presented with a ready-made decision in the form of a completed RfC. I think this process is the best solution. All we need to do now is use it effectively. If people are dissatisfied with RfC we need to understand why, and make whatever changes are needed. Jehochman ^{Make my day} 14:58, 23 December 2009 (UTC)

<grin> I'm in the "ok, to heck with political posturing, let's collaborate and figure out those changes then" mode now.

The reason people appear dissatisfied with the arbcom route to date is that the arbcom has a very slow speed, and a very low throughput. (so that's requirement 4:

• (specific requirement) relatively quick response, and reasonable throughput.

The reason we never actually fixed that problem is that no-one has really found a better means to meet the counter-balance requirement. This has been the deal-breaker that has held things up since forever-and-a-day.

Your proposal meets that counter-balance requirement, and even makes a nod to the other requirements. Note that some of the pre-existing processes you are using actually *fail* some of the listed requirements, for hyisteorical reasons; though using them at least doesn't make things worse ;-)

• In the practical department: say we take your proposal as our current baseline. Can anyone bid a better improvement? If not, we'd have a winner. Can anyone point out fatal flaws? If so, then we'll have to fall back on what we already have.

If/when someone does come up with a better proposal, we'll use that as the new baseline, and the same process applies; we'll systematically "ratchet" up to the best proposal we can figure.

• In the brainstorming department: Sometimes people might have a process that is extremely efficient in only a couple of the requirements. Those might also be interesting to look at for ideas.

let's have fun! :-) --Kim Bruning (talk) 15:14, 23 December 2009 (UTC)

Using RfC to identify problem admins can greatly leverage the available bandwidth of ArbCom. As a practical matter, we can do all of the investigation and analysis, saving them time. If we do a thorough job at RfC, a full case should not be needed; the matter could be handled by motion. It then becomes ArbCom's job to filter the RfC statements, extract a useful signal from any noise, and finalize the results by voting on a motion. The ArbCom members are elected by the community. They represent our most clueful and most trusted users. We should make use of those assets to ensure the integrity of the de-sysop process.

An RfC gives "the accused" a chance to respond and hopefully agree to improvements that would satisfy the concerns. Additionally, I have added the section Wikipedia:Administrators#Requests for comment on administrator conduct, which specifically says that the community expects admins who "fail" an RfC to resign voluntarily. By using RfC's to achieve compromises or resignations, we can further economize the use of ArbCom resources and speed up the resolution of matters. Jehochman ^{Make my day} 15:40, 23 December 2009 (UTC)

That's an excellent start! I wonder if folks think that this is sufficient to cover all the requirements? Is more needed? Can we streamline this further? --Kim Bruning (talk) 16:00, 23 December 2009 (UTC)

• As an arb, I would be tempted to see this suggested process as best; the RfCU allows for a proper investigation and defense, but ArbCom remains the "gatekeepers" to removal of the bit which then becomes mostly the formality of recognizing the RfCU result by motion. — Coren ^(talk) 17:23, 23 December 2009 (UTC)
  • As a non-arb, I too would support something like this, and suggested similar things in the past. I want the final desysopping decision to be maintained by ArbCom, but having much of the work (allegation, investigation, defense, community input) done first would streamline the process and allow for more efficiency. -- Avi (talk) 18:26, 23 December 2009 (UTC)
    • One additional thing we need is for uninvolved admins and bureaucrats to monitor the RfCs to help maintain order and decorum. This can be done informally. Perhaps when an admin conduct RfC is opened, a notice could be posted to WP:BN to get the attention of those who frequently help maintain RfAs. Jehochman ^{Make my day} 18:32, 23 December 2009 (UTC)
      • Yes, this all makes sense. I agree that admins, bureaucrats (and all editors) should be notified, empowered and encouraged to help keep things civil and respectful. -Pete (talk) 18:57, 23 December 2009 (UTC)
  • So the ArbCom can say: Yes, the admin has lost the trust of the community but we are not convinced by the reasons the community gave for this loss of confidence? Sole Soul (talk) 18:50, 23 December 2009 (UTC)
    • There are two valid reasons for loss of adminship: (1) abuse, (2) egregious or repeated poor judgment. If neither of those things is evident, then there is no reason to desysop. If somebody properly blocks an editor, a hundred of that editor's angry friends cannot come along and demand a desysop. Jehochman ^{Make my day} 19:03, 23 December 2009 (UTC)
      • An RfC is the ultimate example of "consensus is not a vote" (and that it should not). I would not expect the committee to accept an RfC that did not demonstrate that the administrator was just not liked, only when actual misbehavior has taken place. That is the primary reason why it's important that ArbCom keeps that sanity check — even if most times it would just be a rubber stamp. It's clear that we can't desysop an admin because n editors were annoyed that their buddy was blocked, or because "omwtfbbq that evil admin protected the WRONG VERSION!!1!! the Truth must be known!1!!". — Coren ^(talk) 19:10, 23 December 2009 (UTC)
        • Coren, you mean "TEH TRUTH™", of course. -- Avi (talk) 19:18, 23 December 2009 (UTC)
        • We trust the community to give the bit without fearing of "maybe they are giving it to their friend". Plus, because it is a consensus and the large number expected to participate, there is no chance that all of them are just friends. Sole Soul (talk) 19:58, 23 December 2009 (UTC)
  • Too much talk. Too little action. Give us something we can vote on. A huge number of users want change. I'm uninterested in anyone wishing to protect their arb power or the status quo. If I were an admin, I'd rather it be hard (impossible) to desysop an admin. Admins might not block? They don't block now! (They just threaten to.) The world will go spinning right off its axis if we change something? We have to change something. The status quo isn't working, because too many people flaunt the rules -- including admins, the very people we depend on for corrective action when another user is flaunting the rules. Plug my bleeding heart. These are volunteer positions. Nobody's ability to support their family would be taken away. Fancy rules mean nothing without enforcement, with teeth!
    You're gonna get books that ArbCom won't read.
    Anything would be better than what we have now -- nothing. -- Rico 19:22, 23 December 2009 (UTC)

Dude, your wires are crossed or something! (IHBT?) Jehochmans' proposal was a simple tweak to RFC rules, and he's already gone and done it :-). This here is the *do* section, 'cause real consensus means doing stuff. Talking too, but discussing stuff about how we're doing. We're not voting, or voting on voting, or voting on voting on voting. Capice? While you were busy having your "real live voting" on your end, we're changing the wiki on ours. Feel free to join in when you're done voting. :-) --Kim Bruning (talk) 21:45, 23 December 2009 (UTC) TL;DR Consensus enfranchises you more than (!)voting can, enfranchise yourself!

ps. The rule is: There are no rules; so no one can or may enforce them either; The wiki works by peer pressure. :-) --Kim Bruning (talk) 21:48, 23 December 2009 (UTC)

And that is your opinion, which is just as valid as everyone else's :). That is the issue, there are hundreds, if not thousands, of valid opinions, and as a project, we have to have something that an achieve a consensus of us all. So it isn't as simple as TEAR IT ALL DOWN!!!! -- Avi (talk) 19:38, 23 December 2009 (UTC)

So how about building it all up? :-)

I usually find that Things That Work tend to have consensus more than things that don't. So my proposal here is to figure out a thing that simply works. If you have something that simply works, everyone is gonna use it anyway, no matter what kinds of pretty fireworks people attach to any clunky alternatives.

Ergo, I'm aiming for de-facto consensus. ;-)

Now enough talk. Let's get back to doing.

Can you improve on Jehochman? Anyone?

--Kim Bruning (talk) 21:54, 23 December 2009 (UTC)

Let me think on it a bit. One thing that I'd tweak would be to change the language to "expected, but not required, to resign", to clarify that ArbCom is the sole "forced" permanent desysopping unit. -- Avi (talk) 22:02, 23 December 2009 (UTC)

I looked carefully at Kim's three "standard requirements" at the top of this talk thread, but with a different approach, one of trying to see if they can be used in the draft proposal discussed here in order to improve it. The second one, about the natural self-organizing nature of the wiki process, leads me to think that things like the number of days for the nominating period should go longer, towards 7 rather than towards 3 days. More basically, it makes me think that there is something very good about having a community-based system, as opposed to relying exclusively on Arbcom. The third point, about counter-balance, strikes me as a very valid point, and one we would all do well to think about here. One aspect of it is something that we have already discussed here: that we should modify Uncle G's original language to get away from short !vote-like bullets, and, instead, ask participants to comment and discuss. The discussion of that here was very much a snow of agreeing that discussion is the way to go. And that allows editors to point out and discuss those counter-balance issues as they come up. I don't see any good way of pre-emptively legislating safeguards against making it hard on admins who do difficult work, but, again, the best protection is to ask the wiki community to shine a light on how the nomination of the admin came about, and to have some faith in the community to eventually get it right. As for the first point, being non-exploitable, although I realize that a few editors think that any process where the community is asked to support or oppose is, de facto, exploitable, I am of the opinion that, for the same reasons that the self-organizing wiki process works, this process can be made to work, and if there are still ways we can revise the draft document to remove exploitability, then let's find them and incorporate them. --Tryptofish (talk) 15:48, 24 December 2009 (UTC)

Need

Why the above examples why a community based desysopping system is needed

It is too difficult to remove the flags of an admin gone to the bad, so therefore it is becoming difficult for the community to give the flags to good editors in case they become poor or casually abuse admins (but stay below the ArbCom radar), which in turn gives those who have the flags an artificially high "status", making it difficult to persuade the functionaries with the power to remove the bits from doing so in all but the most serious cases.
Really, if it was easier for sysops to be both created and demoted via community interaction then there is the potential for there to be a high number of useful good admins, rather than the few hundred "super" admins there are now. Getting the flags should be no great deal, so neither should having them removed - like blocking, removal of the flags is not "punishment" but simply a means of protecting the project (and like blocking, removal need not be permanent but only for as long as it is judged that a problem may remain). Really, think about it. LessHeard vanU (talk) 23:04, 23 December 2009 (UTC)

Yeah, good thought. See section above for why we haven't managed to get a good system before today. Can you improve on the current best plan? --Kim Bruning (talk) 23:07, 23 December 2009 (UTC)

Well, I have been working with Tony1 (talk · contribs) in respect of a method of investigating claims of admin abuse - it has been over a year in the making - and I contributed to some of the earlier discussion above here. I also contributed to a page on the subject started by Ched Davis (talk · contribs), and even had my own aborted page - which I linked to on a plea on Jimbo's talkpage that he used his discretionary powers to institute a community desysop method. Finally, I asked a general question that was put to all the candidates of ACE09 relating to their support for a community based method of determining if admins should be deflagged. I am not actually fussy in respect of the actual method (I support Jonathan's preferred system - I just don't think all other discussion needs to be closed down) as long as it is easy to use, relatively free from gaming, and quick and painless(ish). LessHeard vanU (talk) 23:19, 23 December 2009 (UTC)

You explained that really well.--v/r - TP 23:26, 23 December 2009 (UTC)

I have never seen any evidence of a relationship between the difficulty in removing an admin and the difficulty in passing RFA. Supporters of a non-arbcom method of desyssoping have been throwing that around for years without any supporting evidence at all, and I am growing rather tired of it. After all, RFA standards were actually lower in the early years of the arbcom when it was much more reluctant to desysop. When I went through RFA almost four years ago, arbcom had only desysopped in extreme, fairly obvious cases, but there's no doubt that the tone and culture of RFA were much less unpleasant then. My own feeling is that standards have gone up for four reasons: because that's the nature of standards--the old standards will always seem weak once they're familiar; because edit counts have become inflated by automation, making it harder to sort through someone's edits and thus more tempting to seize on one particularly bad one; because the whole site is so much bigger, making it less likely that a given voter will already know the person running; and because of the proliferation of wikipolitical factions surrounding deletion, which sometimes cause kneejerk responses to a cadidate. All of these would still apply if desyssoping were easier. Chick Bowen 02:28, 24 December 2009 (UTC)

Four years ago there was not the perception that admins might be abusive (they might utter abuse at vandals, but that was not thought particularly bad) in their use of tools to promote their interests at the expense of the project. Now there is, and it appears that some of those concerns are justified. I agree that there is no evidence that making desysopping easier will foster a more relaxed attitude in handing out the mop, because there is no method by which desysopping is more easy - you still have to convince ArbCom or a Steward that there is a Big Problem RIGHT NOW or an obvious pattern of actions. I only make the argument that you to have the opportunity to provide the evidence. I am positing a theory. LessHeard vanU (talk) 14:07, 24 December 2009 (UTC)

Wow. That's a really big claim. What evidence can you offer that

• Admins are being "abusive in the use of their tools to promote their interests at the expense of the project"?
• Wikipedia's existing processes are unable to address such cases if and when they might arise?

I will also note that four years ago, we didn't have pages like WP:COIN to attempt to address conflict-of-interest issues in a centralized, high-visiblity manner. You have to offer some evidence, not just vague weasel words — what does "it appears that some of those concerns are justified" mean? This is why I find it so hard to support these elaborate desysopping process proposals — no one seems willing to come out and tell me what specific problems it will solve; it's all just hand-waving. TenOfAllTrades(talk) 16:24, 24 December 2009 (UTC)

Again, I'd like to discourage finger-pointing at past or present cases of admin abuse of the tools. In my view, it can only lead to the slippery slope of incremental incivility. Today being Christmas Eve, I'd like to wish everyone the happiest of holiday seasons! Jusdafax 16:58, 24 December 2009 (UTC)

If LHvU is willing to withdraw his unsubstantiated claims of conflict-of-interest tool abuse, then I won't ask him for examples. And we can't discuss reasons why this process is needed because someone's feelings might be hurt? Seriously? TenOfAllTrades(talk) 17:35, 24 December 2009 (UTC)

Um, the Eastern European Mailing List ArbCom is the most recent to comes to mind - I really do not wish to trawl ArbCom archives but there have been several cases where admins have either had their bit removed or resigned them under a cloud for improper use of the flags or conduct unbecoming. I am even a little startled that anyone should question that there has been disquiet or complaint of the misuse of tools in the furtherance of certain agenda's in the recent past, and that there has been some people losing or giving up the tools as a consequence. LessHeard vanU (talk) 00:26, 25 December 2009 (UTC)

If the only cases you can come up with are ones where the ArbCom has responded and acted, I'm not sure how that's a justification for creating a parallel bureaucracy. Moreover, this sort of process would be entirely inappropriate for a case like EEML, which involved a huge number of editors and large quantities of confidential, sensitive, privacy-policy-governed information. TenOfAllTrades(talk) 21:35, 28 December 2009 (UTC)

Looming deadline

It appears that the "motion to close" above seems to support us continuing with this process, but it does indicate a certain impatience in some quarters with the length of time this is taking. In fairness to people who oppose this, I think we need to redouble our efforts to get this knocked into a shape that can then be open to discussion so they can put their views in. Will this be ready by 4th January? What needs to happen by then? I suggest:

1. Polished RFC setting out succintly and clearly what is proposed and structured in a way that maximises the value that we get from comments (particularly opposing comments)
2. Bringing nearly all debates about technical points of the proposal to a close
3. Deciding which ones will be left open for further discussion during the RFC
4. Creating and expanding a section which compares CDA with ArbCom de-Admin and really answers the question "Why?". My thoughts:
   1. Speed - would CDA be quicker than ArbCom?
   2. Throughput - would it relieve the strain on ArbCom? Is ArbCom struggling at the moment?
   3. Threshold - would it make de-Admin more likely? would it change the type of actions that would lead to de-Adminship?
   4. Community vs Heirarchy - would it disrupt the so called "power structure" in WP? Would this be a good thing?
   5. Involvement - would it increae the retention of non-admin contributors
5. Have we got any examples of admins who have been through an RFC/U which has had a negative conclusion but for whatever reason, ArbCom hasn't acted to remove their tools?

Have I missed anything else? AndrewRT(Talk) 21:21, 28 December 2009 (UTC)

We do need to pick up a little pace now, I agree. I don't like the idea of those wishing to close early pushing us into action, but we are nearing the original deadline (in the busiest time of year, I have to say). How about we archive the motion for closing if/when closing has less than 50% support? Actually closing early would be impossible without a very large majority (shall we say 80% for the sake of balance), and was a foolish thing to even attempt in my opinion - all it has done is steel people's resolve. I'm determined now to see something come to pass. I'm still reading up on surrounding issues, but this page isn't the friendliest to new eyes (especially those who belonging to new Wikipedians). People are entitled to come here, and theoretically they can vote any way on the matter, so there is no mischief in that at all. Incidentally, I made some userboxes to show support (and concerns, or lack of support) for the idea of a CDA process in general - they are linked to from #Purpose_of_this_discussion above. Matt Lewis (talk) 21:39, 28 December 2009 (UTC)

Some thoughts: It's clearly true that it's difficult for new eyes to sort through this, and in fact quite a few of the points above have already been discussed at various of the sundry pages where this project has been discussed. At this point, I too am losing track of where everything is, but I think a fairly large amount of past discussion of those things is in the archives at WT:CDA; maybe some of the editors who have been doing the archiving can help point out where else they have put things? Anyway, my understanding (for whatever it's worth!) is that there is no way anything will be in final or near-final form in the first few days of January, nor is there any reason that it needs to be. Don't sweat it, WP:There is no deadline. What's important is to get it right, not to get it done tomorrow. At the time I write this, the motion to close is at exactly 2:1 against closing, and given the originally planned date of closing, it is fast becoming moot anyway. I would suggest, for the rather few remaining days, that we hold off on archiving anything more. Let's let people say whatever they would like to say, and that includes the harshest critics. Let's not try to write anything before January 4. Then, after the 4th, let's look thoughtfully at all the feedback that has accumulated here, and think carefully about what it means, not just tally up !votes. (On the 4th, I for one will be in airports and on airplanes much of the day, and not doing much here.) We will have to revise Uncle G's material through the normal editing process. Only after that can we consider placing anything before the community. --Tryptofish (talk) 14:55, 29 December 2009 (UTC)

100% agree with Tryptofish. Jan 4th is the date this discussion closes and the actual RfC is ready when its ready. Ideally it will be sooner rather than later but none of us being paid a bonus for early delivery. I also agree about avoiding further archiving - most of us think the discussion is too complicated but some of us grumble when our pet bit is archived. At this point it's easier to let it be and sort out some simplified results after Jan 4th.

I like AndrewRT's list and I think much of it could go into an FAQ. The "specific examples" bit is tricky of course and I'd prefer to play that down if possible with a rather general link of some kind. Happy Christmas to all btw. Ben MacDui 17:55, 29 December 2009 (UTC)

I think some of the questions raised above by AndrewRT are in need of answers, and others create as many additional questions as they may answer.

Speed - While I think this may be quicker in some appropriate situations, it is not designed to promote undue haste.

Throughput - I believe that there can be times where an admin has lost their only qualification (trust of the community) that may not rise to level of requiring ArbCom involvement. I also believe that there have been, and will continue to be situations where the results of an ArbCom case may be unacceptable to the general community and the community needs and deserves a means to overturn such decisions.

Threshold - I am sure that this will lower the threshold. But this is an ongoing matter of debate anyway. The continual repetition of the concept that being an Admin is "no big deal" is so completely contrary to the sheer depth of process required to undue that appointment that we must either make removing the tools the same size deal as granting them, or admit as a community that being an Admin does carry with it some sort of authority which can be abused without the actual use of Admin tools.

Community vs Heirarchy - as long as one "superuser" retains the sole power to appoint Arbitrators (even if he does tend to follow the results of community voting, there is no requirement for him to do so), the ArbCom cannot truly be considered a community process.

Involvement - The idea that a new user has the ability to begin this process cannot be minimized. Part of the appearance of authority that Admins hold is in the fact that there is no reasonable method for a less experienced user to institute some kind of process against an admin without becoming too deeply embroiled in process, wikilawyering, committees, ANI, RFCs, etc. etc. etc.

As for examples, they will only bring out the worst of all possible discussions regarding the process. I am sure most users can think of a situation that would apply, and I am sure there would be heated disagreements about each of those examples. The only way this process can move forward is by keeping personal details out of it. There is too much that could be rehashed here from prior ArbCom cases, and too much personal baggage attached to those debates, to allow for a reasonable dicussion on this actual proposal. Jim Miller ^{See me | Touch me} 23:00, 29 December 2009 (UTC)

Motion to extend the closure deadline to 15th January

Given the lack of a specific plan of action starting to appear in focus we need to extend the deadline here. It is clear that consensus (as demonstrated in the failed "motion to close") demonstrated the feeling of the community that the current measures available to control Admin abuse are inadequate and are not working. There are also legitimate concerns about the number of non-Admins are aware of this discussion. (I would have missed the "motion to close" had I not been contacted by a concerned editor - despite having being invited to take part in this discussion). I think we need the additional time to (1) work on the most favoured options on the list above; (2) refine them into a proposal that gains a simple majority in a vote by a deadline (15 January); than (3) set up a vote on the formulation supported by a simple majority and circulate news of the vote widely across the community. This vote to have a deadline of 31 January. Sarah777 (talk) 15:36, 31 December 2009 (UTC)

• Support; as proposer. Sarah777 (talk) 15:36, 31 December 2009 (UTC)
• Oppose in specifics, support in spirit. As I said above, I agree that we need to work thoughtfully on the feedback we are getting, before anything can be ready for a community referendum. But I don't think we are going to get many more comments on what we ask here if we extend the comment period; more likely we'll get more motion-to-close type comments. So I think that we can start in the next week to discuss what editors have been saying here, and to start working it into a refined proposal. But I wouldn't want to set any deadlines for finishing that. I'd really prefer to just take things slowly and deliberately, and go through the normal editing process to improve upon what Uncle G wrote, and move forward when we collectively feel ready to move forward. --Tryptofish (talk) 18:19, 31 December 2009 (UTC)
• Support a delay to 15th January, although also don't entirely agree with the specifics. We clearly haven't got this knocked into a good enough shape yet; although I agree that there isn't a deadline on Wikipedia, and it's better for us to finish a good proposal than rush a poorly thought through one, I think, in fairness to admins and people who oppose the concept we should focus on getting this opened as soon as reasonably possible. In that light, a timetable can be useful. AndrewRT(Talk) 19:19, 1 January 2010 (UTC)
• Support the January 15th (2010) deadline. GoodDay (talk) 20:15, 1 January 2010 (UTC)
• Support Not sure of this, but mainly because I don't want it to backfire. I don't have time at this exact minute to even make my mind up on this! Ultimately - two more weeks would be good for me at least. I found out about this just before the holidays, as did a number of others. A two week extension to decide how to go about making the next steps (which isn't that simple) is perfectly reasonable and won't hurt anyone, so I suppose I support. This is far too important to rush too. I don't imagine this motion will get too many opposes - I know a number admin are very much against CDA, but fair is fair - people are entitled to a proper, fair and reasonable say now that it has been decided that this is a legitimate matter. That 'motion to close early' wasted time too, and has further confused the whole page - we must at least archive that after the 4th! Matt Lewis (talk) 21:10, 1 January 2010 (UTC)
• Support – Although I am not actively editing and voting on proposals for the RFC, I have been watching here and trust the participants to iron things out. To support a reliably sound finished product, there are good reasons, including the distraction of the unnecessary "motion to close", to allow additional time for completion of this phase. Sswonk (talk) 21:57, 1 January 2010 (UTC)
• support across the board I think having deadlines is good, and the 15th/31st seem reasonable. Hobit (talk) 20:45, 2 January 2010 (UTC)

• Comment: There is already a deadline and it's up in less than an hour. Secondly, there is nothing preventing those who have not yet involved themselves doing so in the next phase i.e. in deciding exactly how the RfC will proceed. However this does not need to be a either/or issue. I therefore intend the following.

1. Closing the main discussion.
2. Moving all detailed comments to the archive page and leaving only a summary here. The summary will involve identifying unresolved issues that will need to be sorted out prior to the RfC going live.
3. Leaving a section here for "late" comments, open until 8pm GMT on 15th January 2010. This has the advantage of allowing those who wish to to add their voices to this part of the proposal's development without the need to hold everything up whilst waiting for them.
4. Discussion of the RfC based on the summary (and as required any "late comments") will then continue at Wikipedia talk:Community de-adminship. A good New Year to you all from snowy Scotland. Ben MacDui 19:13, 4 January 2010 (UTC)

I have commenced, but not completed the above process of summarising. No.2 still needs more work. I'll be back later but feel free to pitch in! Ben MacDui 21:22, 4 January 2010 (UTC)

Well at least this is some form of action, and I suppose that someone can always revert to the above consensus for an extention if this somehow goes awry (ie like a number of people, I'm not prepared to let this slip away). I'll contribute to the summaries and new discussion on Wikipedia talk:Community de-adminship. For good or bad, well done on taking charge - the logic of proceedings being better with positive people leading the way than negative ones, is sound. And we at least know where we stand with the archives above. Some of it (esp 5.4 imo) shows promise, so we should have no problems continuing this. Matt Lewis (talk) 22:15, 4 January 2010 (UTC)

Thanks Matt. I think that will do for now, archive-wise. I've left lengthier discussions lower down on this page as some of them contain substantive points. Next step would be a summary of action to take to WT:CDA. Ben MacDui 22:21, 4 January 2010 (UTC)

(ec) I would like to echo what Matt said about thanking MacDui. It's inevitably a thankless task, where everyone is going to say how they could have done it better. What I think is important going forward, now, is to continue to feel free to comment, and to start thinking in terms of creating a presentable proposal, but also to take as much time as we need to carry out that creation thoughtfully and correctly. No hurry.

And in that regard, I want to point out now something that I think is very important. It's very tempting, when looking at the summaries above, to simply count !votes. That would be a big mistake. Many of us made nuanced comments that get hidden by simple counts. I'll make an extra effort to point out specific instances of that as we go along. --Tryptofish (talk) 22:26, 4 January 2010 (UTC)

Quite agree - the following is just a start. Ben MacDui 22:40, 4 January 2010 (UTC)... and I have finished for today.

Question: the to-do list below refers to an RfC — is that RfC the actual decision on whether or not to implement the proposal as policy, or is it a request for further comments on the draft proposal, prior to submitting a final proposal for consideration as policy? --Tryptofish (talk) 20:28, 5 January 2010 (UTC)

It's the final RfC, where we put the finished proposal to the community. Matt Lewis (talk) 23:46, 6 January 2010 (UTC)

Thanks. Good, that's what I hoped. --Tryptofish (talk) 23:48, 6 January 2010 (UTC)