Wikipedia talk:Community de-adminship/Archive 2

Further discussion should be directed to Wikipedia talk:Community de-adminship

The following discussion 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.

---

Original closure proposal

Re closure by (say) a minimum of 3 Bureaucrats, a majority of whom must agree that consensus has been sufficient to enable the procedure to be implemented, or it will be closed as "No consensus" or similar.

This would be an unprecedented requirement. What's the point of this page anyway? Gigs (talk) 14:42, 30 November 2009 (UTC)

To figure out what needs to be done in order to optimise the RfC wording. When it looks like it is in decent shape it can go onto the draft RfC project page. The protocols may be blindingly obvious to those with plenty of experience of them, but this is a learning curve for me. The above is simply an idea. Clearly there are alternatives, but do you think it is credible that a proposal of this nature can simply be closed by the RfC nominator? Ben MacDui 22:25, 30 November 2009 (UTC)

What would "closure" even mean? It's not like there's a decision to be made at the end. We just start using the process that we decided upon. If people want to shape that process, they should speak now. If you envision some kind of "final up or down vote" then I don't see any point in that at all. If there are things people don't like about the process we come up with, then let them build or demonstrate consensus to change it after the fact. Gigs (talk) 22:33, 30 November 2009 (UTC)

I'm not sure I'm understanding you correctly - I think there is a clear decision to be made - whether to implement a CDA or not. If the consensus of the RFC is not to implement, then it shouldn't be implemented. Discussions to date have been very useful, but it really needs a clear consensus in favour of this before it goes "live". AndrewRT(Talk) 23:05, 7 December 2009 (UTC)

The point is, whatever we wind up with at the end of the RfC will reflect consensus, if we do it right. It is not useful to think of it as "CDA", since it may work entirely differently from what the original CDA proposal was. We have consensus and a mandate for some kind of new, community based, de-sysop process. This consensus being established, the only thing left is to build consensus about the details of the process. I have no illusions that the 10 or so people here can build something that will satisfy the 200 or so people that may review the final RfC, which is why I'm explicitly opposed to anything vote-like. We need to be soliciting actual constructive feedback all the way through, including in the so-called final RfC... Gigs (talk) 14:00, 8 December 2009 (UTC)

Pardon me for being the FNG to this conversation, but I've read through a few times and I feel like I'm missing a salient point... how would this process start? Can anyone pissed at an admin start a "RfD", "CDA", whatever the acronym will be...? Tan | 39 15:19, 15 December 2009 (UTC)

Tan, as currently written, the proposed Cda can only start after all other attempts at mediation, etc. have failed, and ten nominators ("in good standing") have initiated one. A recent wording change proposed by Avi (which I !voted for yesterday) even allows penalties for those attempting to game the system or otherwise use it as a disruption. The entire process is subject to bureaucrat oversight, and they can shut it down if it is judged to be without merit, or have no chance. As I see it, a Cda is the last step in a measured chain of events that currently exists up to ArbCom. If ArbCom is split or conflicted and can not, or will not, take what the community may see as appropriate action against an administrator(s) (or even feels a Cda, if enacted, is more appropriate), a Cda then allows the community a final chance to express their will, via a supermajority !vote (exact percentages are being discussed, but 70% - as in an Rfa - is currently a ballpark figure to take the mop away). Jusdafax 16:21, 15 December 2009 (UTC)

Well, I hate to jump in to a quagmire to which I have not been personally invited (oh, wait, I was...), but I couldn't disagree more with this entire proposal, strategy, whathaveyou. Metawikipedia needs far less beaurocracy and process, not more. I do not admit or deny there is a problem with desysopping "bad" admins - but adding yet another super-complex layer to an already super-bloated process is not an answer. I feel that if people here are frustrated with ArbCom's repeated unwillingness to do anything of any value whatsoever (a frustration I sometimes have), then the answer is to fix ArbCom, not create yet another timesink. Tan | 39 17:03, 15 December 2009 (UTC)

Would you be opposed to a lightweight community de-sysop process? Is it the complexity of the current proposal that bothers you, or the entire idea of consensus based desysop? Gigs (talk) 17:06, 15 December 2009 (UTC)

Both, if that makes sense. The process should already exist via ArbCom. Tan | 39 17:08, 15 December 2009 (UTC)

It should, but often doesn't, or is perceived as not, though I see recent signs of change which bode well. (Also, we have a new board incoming.) Still, a working Cda provides 'civilian oversight', if you will, on the very real problem of tenured admins who abuse their powers in various, long-term ways. I don't see the process as overly complex. It's a reverse Rfa, when all's said and done. If an admin gets out of line, and there is no relief of the issue from the existing structure, then the community has a final option via this proposed Cda. Jusdafax 17:39, 15 December 2009 (UTC)

I disagree with your premise. Can you point out some examples of the "very real problem of tenured admins who abuse their powers in various, long-term ways"? Tan | 39 18:18, 15 December 2009 (UTC)

I understand that you disagree, and I respect your right to do so. As for examples, even of past cases and not current ones, I decline to do so because I do not want to start what some will term name-calling. Let's say there are no 'problem admins'. Then this Cda process, if enacted, won't hurt, because with the safeguards in place, it will never be used and can't be abused. If, on the other hand, there are 'problem admins', now, or in the future of Wikipedia, the Cda process provides a public court of last resort, with multiple safeguards and Bureaucrat oversight. In other words, a fully-vetted Cda process can't hurt, and might help. And of those expressing an opinion at Wikipedia:WikiProject Administrator/Admin Recall about 'Option 0' (to do nothing), the vote was 44-13 against, and I think that the 77% in favor of doing something indicates that a healthy percentage feels something should - even must - be done. This transparent, open process, which has been given reasonable publicity to stakeholders, is the result of that. Jusdafax 18:54, 15 December 2009 (UTC)

It was a loaded question; I knew what your (only possible) answer would be. My opinion is to fix the current process (ArbCom), or take them out of the loop altogether. Or, realize that there will always be background static of editors pissed at admins and constantly accusing them of abuse. Tan | 39 19:06, 15 December 2009 (UTC)

I've noticed some editors having questions about what, exactly, is the wording of what is being discussed. Please go to: Wikipedia talk:Community de-adminship/Draft RfC, which is where the primary discussion is, currently. There, the first section, called "Quick links", will link you directly to the draft language. I hope that helps. --Tryptofish (talk) 19:09, 15 December 2009 (UTC)

Good point(er) Trypto. Tan, I should also note that the original proposal, 'Option 4', was actually written by an admin, Uncle G, a fact which always has struck me as quite important. Unfortunately, he appears to have been afk for a number of weeks now. I just left a message on his talk page asking his opinion of the ongoing and overall process here. As to 'fixing' ArbCom, or reducing their powers, that's a can o' worms that I won't go near. Best wishes, Jusdafax 19:31, 15 December 2009 (UTC)

Jusda, taking a look at the old CDA proposal, it's pretty out of step with where we currently are. Why aren't we actually using the wiki tools to develop the text? Collaborative development of text is what a wiki was designed for. I think this is a major source of confusion. Gigs (talk) 20:07, 15 December 2009 (UTC)

If you don't mind my replying, I would suggest taking it slow about revising the draft until the current comment period is over (early January). WP:There is no deadline, and it's too difficult for editors to comment on a proposal that is changing as they comment. --Tryptofish (talk) 20:13, 15 December 2009 (UTC)

I looked into the origins of Uncle G's proposal, and was impressed by thoughts on his talk page from back in October, shortly before he stopped editing. I think they merit discussion, and I'll put them at the bottom in a new topic heading. Jusdafax 20:11, 15 December 2009 (UTC)

Trypto, seems to be a common theme here, but I disagree. We handle a moving target just fine on article talk pages for articles that are changing orders of magnitude faster than this process guidance document will. Why are we "saving up" all these changes instead of just making them as the consensus is established? If this is some strategy so that no one knows quite what the current proposal is, I'd say it's working! Gigs (talk) 20:34, 15 December 2009 (UTC)

Well, then maybe the thing to do would be to change those things that have achieved enough consensus to have been archived in the discussion. That would be reasonable. But I would caution against tweaking anything else yet. (My point is that, where we are currently asking people to support or oppose, it's unfair to change what they've already !voted on.) --Tryptofish (talk) 21:54, 15 December 2009 (UTC)

That's fine with me. We don't need to recklessly change it. We should make it much easier to find though. I suggest that we reduce the total number of pages that this conversation is sprawled across as well, and archive old conversations with pointers to where current conversation is happening. Gigs (talk) 00:26, 16 December 2009 (UTC)

Yes, I agree with all of that. --Tryptofish (talk) 00:54, 16 December 2009 (UTC)

Further comment

I think you should just delete Wikipedia:Community de-adminship/RfC Strategy and remove all references to it. Once the proposal for the RFC is drafted, there's no need to "vote" yet again. RFC means "request for comments", and it should be just that, a request for people to comment on the proposal. If a consensus builds for further changes to the proposal, we can make those changes. We already have consensus for some form of recall process, so there is no need to put that up again. Voting is a very counterproductive endeavor. Gigs (talk) 04:28, 1 December 2009 (UTC)

First of all, this seems to me to be the value of this page - it is there to iron out what exactly it is that needs to be done and how the RfC is to be phrased.

Secondly, I'm in favour of simplifying where possible but I don't understand what you mean. When you say there is "no need to "vote" yet again" what is that you think the RfC should be discussing? I don't think it can just be an announcement that WP:CDA has been agreed and that henceforth it will operate.... Ben MacDui 19:31, 2 December 2009 (UTC)

The RFC will gather feedback on the proposal we come up with. What did you think it would be discussing? It won't be an announcement, it'll be a request for comments. It should explicitly not be a vote, or anything vote-like, though. Votes work when you are determining consensus for little straightforward elements. It would be counterproductive to consensus to hold a vote on the big overall proposal after it is drafted. I don't think any successful process or proposal has ever been subject to a big community vote in that way. They are all developed through an iterative process of developing and building consensus. That's what we need to do here. We'll work out our little consensuses, then widen the scope out to the community, and go through the same iterative process again based on specific suggestions and concerns. Gigs (talk) 21:06, 2 December 2009 (UTC)

I know you've probably seen this before, but it might help to go re-read Wikipedia:Polling_is_not_a_substitute_for_discussion#Policy_and_guidelines. It might say things in a better way than I can. Gigs (talk) 21:13, 2 December 2009 (UTC)

I'm aware of the issue, but is not likely that people are going to respond by saying "oppose" or 'support" anyway? Given the creative nature of the culture if it is not clearly spelled out that the request is essentially for a "yes/no" answer is this not going to result in another 20 variations being proposed along the lines of - " I can support this, but only if it does not apply to ex-ArbCom members whose user names ends in a vowel" followed by mini- !votes, comments and general side-tracks? It would help me understand if you could provide an alternative text of some kind - or are you suggesting we don't provide "oppose/support" sub-sections? Ben MacDui 09:11, 3 December 2009 (UTC)

Yes that is exactly what I'm suggesting.

• Put the revised policy/procedure on the main page,
• Put the RFC tag on the talk page with a general note that comment is requested.
• Put a short history of the process thus far on the talk page so that they can see that this isn't just something someone made up out of the blue.
• Avoid mini straw polling unless it's not clear from plain discussion where consensus lies on an issue.
• Advertise it sufficiently.
• After a while, we just start using the process.
• If anyone screams, remind them that we did get a pretty solid consensus for some kind of de-admin process, and that all processes are open to new suggestions if they can build consensus for it.

Remember, a big vote communicates the wrong message, that this process will be somehow set in stone as a "ratified" process, and that it will be hard to change. The more that people perceive that the process is going to be immutable, the more instruction creep and exceptions they will want. The process isn't immutable. Consensus can change. Our process to design the process needs to make people feel safe trying something they might be a little doubtful of, comfortable in the fact that we can always go fix any problems later as they arise. As well, a big vote forces people to "approve or reject" the entire process, hanging their reputation on something unproven. Gigs (talk) 14:37, 3 December 2009 (UTC)

Interesting suggestion. I'm not saying you are wrong, and I `m not especially attached to the existing wording, but I'd certainly like to see some more thoughts on this from others before we proceed. There's plenty of time at present. My main concern is that in the absence of a firm decision by the community at large to support CDA (as opposed to the general principle) that the 'crats might simply refuse to enact any de-sysop that emerged. Nonetheless, would you move the above to the "project page" - I've created a section for "Proposal 2" - by all means change the name. Ben MacDui 19:42, 3 December 2009 (UTC)

You'll probably need to go canvass a few people from the other page to get some more opinions, I don't think anyone is looking at this page. I don't really mind if you selectively canvass a few that you prefer, I don't think it would be appropriate to spam everyone with this discussion at this point, though you may want to add a link to it on the RFC development page as well. Gigs (talk) 21:08, 3 December 2009 (UTC)

Will do in due course. In the meantime, here is the sort of input that needs to be addressed. [1]. Cheers. Ben MacDui 09:38, 4 December 2009 (UTC)

That diff is an excellent example of why voting is bad. Gigs (talk) 12:59, 4 December 2009 (UTC)

MacDui dropped me a note asking what I think about this. Actually, I've been watching this page and discussion from the start, but simply decided not to get into it yet, until now. (I've got a huge amount of other stuff on my plate at the moment, ugh.) I could go either way on what has been discussed above. On the one hand, it's helpful to get a draft of the next stage underway, so that it will be worked into shape by the time the need comes, just so long as it is understood to be a draft until then, which it is. On the other hand, it can be a problem to be revising it as the main discussion goes along, because the main discussion is, well, still going along. Taken together, that brings me firmly down on the side of not knowing what to suggest! Sorry I can't be more helpful. --Tryptofish (talk) 19:47, 4 December 2009 (UTC)

I also got the note from Ben. I had not read this project page and as someone following this issue semi-closely and commenting/voting when it seemed proper, I think there are a number of points of interest that it is good to raise. Also, Gigs has some reasonable points regarding the numbers actually involved in the process. But I keep coming back to how little support there is for doing nothing about establishiing a reasonable method of dealing with de-admining those who misuse the tools, or in other ways abuse their authority with threats or disruptions.

In other words, there is established consensus that the system is broken, and that it must be fixed. The way we are going about it seems best to me, not perfect, but the best we can come up with: A reverse Rfa with built-in safeguards against gaming the system either way. I think the discussion so far is mostly reasonable and measured, and I like the direction and timetable. One thing I'm disturbed about is the lack of 'crat discussion, with only two (to my knowledge) speaking up at all. I have said ever since I first voted for Uncle G's Option 4 that 'crat participation is crucial in my view, since they would be gaining important powers and making final decisions, and other calls. I think that if January comes and they have remained silent, COI concerns or no, then we are possibly going to flounder in moving forward.

The other danger: we are going to drown in a sea of words. But lets keep talking with the goal of clarity and progress towards a needed goal of a workable reverse Rfa. Short version, keep the page, but let's not get distracted. Jusdafax 20:49, 4 December 2009 (UTC)

Correct me if I am wrong, but the discussion here seems to be about two things: When the discussion on tweaking WP:CDA is finished,

1. The finished proposal should be approved by the community through another RfC, or,
2. The finished proposal should then be implemented.

On these grounds, I would suggest that an RfC is started once the proposal is "finalized". There seems to be consensus that there needs to be a de-adminship process, and the proposal in question did receive conditional majority support. However, the fact remains that the current discussion is being participated in by a small minority of editors. Even the previous discussion which brought CDA to the forefront only had 57 editors voting for/against the status quo. The WP:CDA proposal has even less editors involved. While I would like to see CDA go through, I think bypassing a broader community acceptance could backfire. What we have as evidence to support CDA being adopted if 44 editors voting against the status quo (no de-admin process), and 26 people supporting the first draft of the CDA proposal. I fail to see that as enough consensus to adopt the protocol outright. The current discussion allows no discussion of those who currently do not support the proposal. If CDA were to go to RfC, I think it would be more than support/oppose, as usual, weighing the strengths of the arguments to achieve consensus. I still think this proposal is under the radar for many editors, and I think the Admininstrator Recall RfC and the CDA draft RfC are suffering from WP:TLDR. I think it is important to gauge the true consensus of the community in order to adopt this proposal. Angryapathy (talk) 21:31, 4 December 2009 (UTC)

I agree very much with Angryapathy. My understanding has always been that, after the discussion now, a polished proposal will go before the community. Only then, and not before, will it be determined whether or not to make it policy. --Tryptofish (talk) 21:35, 4 December 2009 (UTC)

Agree - assuming it's hammered into ship-shape condition by consensus discussion, the final proposal should go up for a majority vote. As a further safeguard I suggest that the proposal be subject to 'crat and/or Jimbo review. Jusdafax 00:02, 5 December 2009 (UTC)

I agree with that too, about Crats and Jimbo. --Tryptofish (talk) 00:16, 5 December 2009 (UTC)

Crats and Arbcom should review. I don't think an unelected Jimbo can overturn directly, but I agree that his review would almost certainly inspire an overturn, and this is a good thing. --Alecmconroy (talk) 00:53, 6 December 2009 (UTC)

How did the discussion jump from "we should definitely have the RFC for wider community feedback" to "should go up for a majority vote" per Judasfax? I still strongly advise against anything even "vote-like" when it comes to the final RfC; I believe that will kill this. We can't make everyone happy, and if we have 15 substantial elements, everyone who opposes even one of them will likely oppose if you force them to by giving them the ultimatum of "support or oppose", "up or down". This will not pass by giving ultimatums. It will pass if the skeptics are allowed to be skeptical, and if the process is acknowledged to be subject to further refinement in the future. Approval by crats or Jimbo implies that further changes would need likewise approval, again, it's adding to that ultimatum factor which will lead people to oppose. Please consider this carefully. Gigs (talk) 05:03, 7 December 2009 (UTC)

Again, you have lost me here. Unfortunately I completely agree with you that it is going to be very difficult to achieve success, but I don't see how can it be deemed to "pass" if it is not "vote-like". My interpretation of the earlier poll is that there was strong consensus in favour of a procedure and that CDA was the most favoured process and thus the most likely to succeed. I don't interpret it as a community decision to enact CDA subject to a few tweaks. Re the "approval by crats or Jimbo" I think it is clear that the main idea is to get the principle approved - hopefully not a difficult task if there is indeed a clear consensus to proceed. Ben MacDui 08:47, 7 December 2009 (UTC)

I outlined a course of action above in the bulleted points above. It calls for another community-wide advertised RfC discussion. That discussion should establish a rough consensus. It should do that through straight discussion of any contentious points, not through voting on the overall proposal. Again I feel I should refer you and and other new readers to this. Ignore this guideline at this proposal's peril! Gigs (talk) 13:26, 7 December 2009 (UTC)

Am I right in thinking that the only difference of substance between the two is that there are no sub-section headers for "support/oppose/neutral" in your version? If so, I don't mind removing them in the spirit of "Polling_is_not_a_substitute_for_discussion". Ben MacDui 19:22, 7 December 2009 (UTC)

Basically yes, however we should actively discourage bolded !votes as well with some sort of reminder that it's a discussion, not a vote. We should make it clear that it is the last stop before going live, but we should also make it clear that the process can easily change if there is community consensus to change it after the fact. Putting emphasis on the fact that it's not a fixed process, that it's subject to further refinement and future changes in consensus will lower the bar for acceptance. Gigs (talk) 21:25, 7 December 2009 (UTC)

So, as I understand it, you simply want to do what is going on at Wikipedia talk:Community de-adminship/Draft RfC, but, er... again? That discussion is advertised at {{cent}}, and is quite extensive. There's a limit to discussion, there comes a point where you have to say: "this is what we have, do you support it"? And if the community decides against it, which is indeed possible, it's back to the drawing board. Now if I were the mistrustful kind I could easily say that you want to have a "discussion" rather than a vote so that opposition can be neatly glossed over in favour of the vast number of bytes that debate over the minutiae of the proposal is sure to generate. The deciding 'crat, or Jumbo, or whoever, will see ninety subheading over the use of the definite article in paragraph 3, and a couple of lonely scattered opposition statements which could possibly amount to a majority, but which are more easily ignored. You are engineering the process to ensure the proposal passes, and admit so. You say this will not pass if a vote is held (an "ultimatum" is the euphemism you use), but is that not the point? If the final version agreed upon by the folks at that page is not satisfactory, it should fail. If anything, this should encourage the folks over at the Draft discussion page to keep the vote off until there's very broad consensus on the shape of the final proposal. I also agree with MacDui, how can it be held to have passed after nothing more than a discussion? Any decision reached on the grounds of a discussion will most likely swiftly be overturned in favour of a vote (or nothing at all), because you simply don't have universal support and the opponents of the proposal aren't going to take your pseudo-gerrymandering lying down. —what a crazy random happenstance 02:19, 15 December 2009 (UTC)

I don't want to steamroll or TLDR the objections, I want to convince objectors that this isn't some finalized big deal, it's something that can be changed based on consensus. I want objectors to be able to say "OK, we can try it, even though my serious concerns remain". If we force them to "support or oppose" it through a vote-like process, they will be forced to oppose. We can amend this process based on hypothetical scenarios all day. Until we get something out there we won't know where the real problems lie. Gigs (talk) 14:05, 15 December 2009 (UTC)

But it shouldn't be that fluid, it should be a big finalised deal. You can't hold a vote on a changing proposal, and you likewise can't establish consensus through debate either. Just because I supported at 03:14 doesn't mean I'll support 2.72 minutes later when a new change has been implemented. Once you present something to the community, whether it be for a vote or a debate, the community needs to be assured they know just what the hell they're voting on or debating about. —what a crazy random happenstance 14:25, 15 December 2009 (UTC)

To clarify: My take is that we wind up the draft Cda in the next few weeks (I have recently reminded interested parties of this) and in January have a non-voting comment period (see my statement below) in which we see if the proposed final draft Cda flies with a goodly chunk of the community. If not, we either continue tinkering with what we have, or go back to the drawing board, but if it appears to have substantial support, then and only then should there be a straight up or down !vote some time in Feb. - March, and it should be, as in an Rfa or the proposed Cda itself, at least a considerable sized 70%-type vote to pass. If it is in a grey area, 'crats make the final call on that too. Fairly unprecedented, I admit, but it's what it would take, as I see it. Jusdafax 16:49, 15 December 2009 (UTC)

Big Design Up Front for a Wikipedia process is unprecedented in general. Gigs (talk) 17:00, 15 December 2009 (UTC)

Perhaps so, but I see us as on target. As we get closer to closure, I expect some stiffening resistance, which is perfectly fine. So far this has been a remarkably civil process, with thought and care being taken to address all concerns. I understand your wish to avoid a final !vote, but we invite drama without doing so. And I think your reminder that the Cda process, if enacted, (to paraphrase) can be amended or even removed if it clearly does not work, will give a reasonable final safeguard. Jusdafax 17:54, 15 December 2009 (UTC)

What consensus?

I'm afraid I totally disagree with the idea that some have expressed that there exists a current consensus in favour of this proposal or indeed of any reform. The number of people involved in the original discussions is tiny compared to the number of people affected and who would probably have a view if prompted and presented with a clear proposal. All the original discussion did was give a mandate to develop a new proposal - which is what we're doing now. That new proposal should then be put to the community to discuss and decide whether or not they want to proceed. That was always the plan, and I think that's exactly what we need to do. This discussion is not about implementing something that's already been decided in principle - it's about developing and polishing a clear proposal that can then be discussed. AndrewRT(Talk) 23:16, 7 December 2009 (UTC)

I agree, and, for that reason, am not exactly sure what is being discussed on this talk. --Tryptofish (talk) 23:45, 7 December 2009 (UTC)

I don't think we even have a single proposed policy yet, so we certainly don't have a consensus for it. --Alecmconroy (talk) 01:11, 8 December 2009 (UTC)

This page, which I did recommend against in the first place, and still doubt the value of, is discussing what to do once the draft process is finalized and we are ready to move into a community-wide RfC. It's obvious that the context was lost or unclear, and people are confused about what's going on here. Gigs (talk) 01:19, 8 December 2009 (UTC)

Strategy: Run it by the Elders and get endorsements

If you look, a lot of the arbcom candidates have answers that, in general, some sort of community desysop would be good. I'd say that before anything is put up for full community discussion, we should make sure it has the support of as many arbs and near-arbs as possible. Which is to say-- there's no point in bothering the whole community until the people who best represent the community's views are, more or less, on board.

This doesn't hafta be true, but I currently have no idea what true community consensus will support, but the arb- and near-arb population is probably the best approximation we can get.

IF they don't support a plan, the plan will probably need to be changed before it could get consensus. Alternative, if they do support a plan, it will be all the easier for others to feel comfortable with it also.

I'd suggest as soon as the elections are over we try to get explicit feedback on the draft. To do it now might overly 'politicize' the discussion, of course. --Alecmconroy (talk) 01:11, 8 December 2009 (UTC)

It may be good to do something like this, as long we make it clear that the process isn't "blessed" or "officially approved"... it's definitely open for later amendment if some part of it isn't working out. One of my main concerns above was about improperly giving the community the idea that the process is immutable because we went through some elaborate approval process different from normal consensus building. Gigs (talk) 01:22, 8 December 2009 (UTC)

(ec) I basically agree, and particularly agree about avoiding politicizing. But check the "publicity" section on the CDA draft page, where there's a list of the pages where messages have been left inviting feedback. I myself put such a message at the ArbCom talk page already. Anything overlooked, by all means, let's un-overlook it! --Tryptofish (talk) 01:25, 8 December 2009 (UTC)

Ditto what Gigs said! Yes, let's do this, but at the same time not pretending this is authorised in any way. AndrewRT(Talk) 23:29, 11 December 2009 (UTC)

Thoughts on ArbCom, Bureaucrats, Rfc, !Voting, and a polished Cda proposal in 2010

Intro - As I note elsewhere, it's my belief that, if put in place as a process, an actual Cda (Community de-adminship) [ http://en.wikipedia.org/wiki/Wikipedia_talk:Community_de-adminship/Draft_RfC ] would only be enacted as a last resort by a community unsatisfied or frustrated by actions taken, or not taken, after every step in the currently available process to deal with deeply questioned administrator behavior, including (in most cases) ArbCom , had been exhausted. It is more or less a reverse Rfa.

A Cda is a kind of 'safety valve' allowing a grass-roots action to take errant admins before the same forum that gave them the title and buttons to begin with. It is the essense of accountability, as I see it. This reasoning is why I call for Bureaucrats to have the latitude to oversee and make final decisions as needed in a Cda, and not ArbCom members, who in many if not most cases will have already been involved in the issues covered by an Cda. As many here know, a Steward will have to be then notified to complete the de-adminship.

Moving forward - It's my own understanding that, as Gigs notes above, Wikipedia is not a democracy. It is (or should be) a clueocracy. So my proposal for a majority !vote should not be taken as a call for 50% +1, but as a consensus !vote per an Rfa, with this variation: a percentage as low as 60% or even a little less (depending on comments, arguments and bureaucrat overview) should be in fact considered as a possible consensus/supermajority. I propose that a vote take place after an Rfc (Request for comment) of two to three weeks, with wide notification for the Rfc and the possible eventual !vote. I see the latter taking place before spring 2010, unless it is quite clear that, despite the efforts made to draft a superior proposal for Cda, that it should go back to the drawing board. To recap this:

A proposed rough timeline - In early January (current flexible target is Jan. 5, 2010), should it be reasonably widely agreed that the draft Cda proposal is complete and polished, the Rfc period begins, with wide notification and hopeful participation by a goodly number of Wikipedians. An Rfc should hopefully make it clear 1) If there is consensus that the Cda is needed at all and 2) If it is, the pros and cons of this Cda proposal. If needed, an Rfc can be extended, but a three week maximum should be considered. At a date in February to be determined, a decision should be made to !vote, or go back to the drafting process. This requires a !vote to have a !vote, if there is no clear consensus either way. I also feel Jimbo's input would be of great importance and interest, and agree that ArbCom comment from the newly elected members obviously would be helpful as well.

If an !vote has been decided on, then again wide community notification is obviously required. A two or three week !vote should be considered, with bureaucrat final oversight in a case of a grey-zone range !vote, as they do in Rfa's. If consensus is clear to adopt the Cda, or if the bureaucrat(s) determine that consensus has been reached, the Community de-adminship becomes effective at that time. As Gigs rightly notes, it should be made clear that if some part(s) are clearly out of whack, they can be amended.

Conclusion - My view: a functional community de-admin process is desired by a significant portion of the Wikipedia editorship, and that if a final draft is commented on, and enacted, it will make our online community a stronger, happier place to work in. Let's continue to examine the ways to do this. My thanks to all who are reading/commenting/and drafting. Jusdafax 01:28, 14 December 2009 (UTC)

A few thoughts about that (not entirely thought through by me). (1) I expect that, in early January, after we finish getting the input we are getting now, we will need some time to polish up the draft proposal in response to that input. It won't (shouldn't!) be simply a matter of counting !votes. We will need to go through a process of editing, in the usual manner of editing, to come up with a presentable document, and that will take some time. (2) I'm not convinced that we need another RfC to determine that we, then, need to have a !vote. I kind of think they should be a single process. --Tryptofish (talk) 19:16, 14 December 2009 (UTC)

To be as brief as possible: If early January comes and the Cda proposal is clearly not complete, we should keep polishing within reason knowing that no proposal can please everyone. When a sizeable majority of us working on it judge it really and truly complete, then I see a final discussion before the community of a couple weeks, kind of a 'dummy check', to see if the proposed Cda is ready for a final !vote. If it is, hold it! If not, either fold it or go back to drafting it further. Jusdafax 17:07, 15 December 2009 (UTC)

Uncle G, the CDA proposal's originator, on getting it adopted

To quote directly from the Uncle G talkpage:

As to adoption, I quote to you the wise words of Radiant!, inventor of Wikipedia:Proposed deletion: "It's been discussed to death several times for at least half a year. There are at least three older proposals that in essence are the same as this one, only somewhat more complex. We can discuss for another half year, or we can go for a test run for a chance." The same is true here. There are existing proposals in this case, and they are either less fully formed (with vague handwaving on the details such as how actual requests are structured) or full of bicycle shed elements (such as laundry lists of why people should be de-sysopped). Hence the reason that I presented WP:CDA at WP:RFAR as a mechanism to actually use, with a concrete implementation and without such bicycle sheds to argue over. Uncle G (talk) 06:17, 9 October 2009 (UTC)

I find this sobering, and invite comment. Jusdafax 20:22, 15 December 2009 (UTC)

"We can amend this process based on hypothetical scenarios all day. Until we get something out there we won't know where the real problems lie." Gigs (talk) 21:55, 15 December 2009 (UTC)

Suggestion on new navigation and consolidation

We've got something like 8 different places where this has been discussed. Here is my suggestion to simplify discussion which has become sprawled:

• Wikipedia_talk:Community_de-adminship - Use for meta discussion on the proposal, like what we have done on this page.
  • Clean up and move-archive Wikipedia_talk:Community_de-adminship Done
• Wikipedia talk:Community de-adminship/RfC Strategy - I suggest moving this page to Wikipedia_talk:Community_de-adminship, leaving redirect. Further high level meta discussion would occur at WT:CDA.
• Wikipedia talk:Community de-adminship/RfC Strategy - I suggest deleting this page, or jusdafax can move it into his userspace to use for reference, and blank the redirect. Or just mark it as archival and leave it.
• Edit the nav box {{WPAdmin Navigation}}
  • Remove mention of WP:CDA RfC Strategy
  • Remove Wikipedia:WikiProject_Administrator/Admin_Recall and talk from the nav box
  • Add link to Wikipedia:Guide to Community de-adminship Wikipedia talk:Guide to Community de-adminship
  • Add link to WP:CDA and WT:CDA
• Add link Wikipedia:WikiProject_Administrator/Admin_Recall to feature prominently at the top of relevant discussions
• Archive contents of Wikipedia talk:Guide to Community de-adminship. Add the nav box to it. Not sure what kind of discussion should go on this page.
• Integrate any suggestions that were indicated by closed straw polls on the RFC talk page into Wikipedia:Guide to Community de-adminship proper.

Gigs (talk) 00:53, 16 December 2009 (UTC)

I have no interest in dealing with this page in my space, thanks. If consensus here is to wipe the page, wipe it. I'm currently mulling this whole thing over, actually. Jusdafax 01:24, 16 December 2009 (UTC)

Well, let me know what you want to do. This proposed course of action is just a suggestion, but I really think we need to consolidate things down a lot. Gigs (talk) 01:31, 16 December 2009 (UTC)

Agree that we need to have one place to carry on from. I think this page has served its purpose and is getting too big. I'd say archive it as a subpage, myself. Jusdafax 02:49, 16 December 2009 (UTC)

First of all thanks for these suggestions. It's a complex discussion and ways to simplify it are very welcome.

• Wikipedia_talk:Community_de-adminship - Use for meta discussion on the proposal, like what we have done on this page.

Fine by me

• Wikipedia talk:Community de-adminship/RfC Strategy - I suggest moving this page to Wikipedia_talk:Community_de-adminship, leaving redirect. Further high level meta discussion would occur at WT:CDA.

I agree with the general idea but think it would make more sense to:

archive this page at Wikipedia talk:Community de-adminship/Archive 2

recreate a short summary or the contents of this page at WT:CDA

change this page to a redirect to WT:CDA

• Wikipedia talk:Community de-adminship/RfC Strategy - I suggest deleting this page...or just mark it as archival and leave it.

It is not archival, but a suggestion as to the next step. In the absence of any other concrete proposal it is where we will go next. Archiving it is therefore premature. To put it another way, without this, what's to discuss?

• Edit the nav box {{WPAdmin Navigation}}
  • Remove mention of WP:CDA RfC Strategy

No, as follows from the above

• • Remove Wikipedia:WikiProject_Administrator/Admin_Recall and talk from the nav box

Yes - I wonder if a "history of this proposal" navbox might be useful tho' (or maybe a history section of a navbox).

• • Add link to Wikipedia:Guide to Community de-adminship Wikipedia talk:Guide to Community de-adminship

Yup

• • Add link to WP:CDA and WT:CDA

Yup

• Add link Wikipedia:WikiProject_Administrator/Admin_Recall to feature prominently at the top of relevant discussions

Yes (or navbox suggestion per the above).

• Archive contents of Wikipedia talk:Guide to Community de-adminship. Add the nav box to it. Not sure what kind of discussion should go on this page.

Suggest a redirect to WT:CDA for the duration of this process

• Integrate any suggestions that were indicated by closed straw polls on the RFC talk page into Wikipedia:Guide to Community de-adminship proper.

Yes - but not until after Jan 4th. Ben MacDui 20:19, 16 December 2009 (UTC)

So it looks like the two points we disagree on are the disposition of the project page that goes with this talk page, and whether to integrate changes into the guide yet or not. Lets just talk about the first one for now, I know we've disagreed on that since the beginning. I propose that we move proposal 1 to the actual RFC page, with a comment at the top that has a disclaimer that the RFC is a draft and not yet live, and a link to WT:CDA where we can discuss it and develop it further. We can then work on that in the normal wiki way. The rest of the page is mostly a to-do list, that can surely be integrated somewhere like the top of WT:CDA in a little box or something. Gigs (talk) 01:56, 17 December 2009 (UTC)

I think that will work although it will need a prominent set of directions at the top of the "actual RFC page" to make it clear that the associated discussion page is about refining WP:CDA so that the proposed RfC can be formulated and that discussing the wording of the RFC is at... Ben MacDui 20:41, 17 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.

Continued wording concerns

Collapsed: Issues have either been addressed, or are being discussed in other more active sections of this talk page

Key Red - Needs simple clarification, likely without much discussion to remedy. I couldn't support unless clarified. Orange - Ambiguous and in need of clarification, possibly some discussion needed to remedy. Unlikely to support unless clarified. Purple - Seems to be completely redundant, or it could be tied into other existing bits of the guidance to avoid confusion. An easy fix, though not serious enough for me to resist the draft if not fixed. Green - Could use some thought on whether the current wording is clear enough. Not enough of a concern for me to resist the policy. I've re-read the entire wording as of 8.00 UTC, and here's what I think: Nominator's sub-section:  Done "their account must be "more than three months old" - does this mean at least three months old (i.e. 90 days) or (91+ days)? I know to those who drafted this it's clear, but not to me. the stale signatures bit - Whilst it's been revised since yesterday, I'm still confused about it. My understanding was that if they don't get 10 sigs by 10 qualified editors within 7 days then it's dead in the water. Thus why this extra language about re-signing? Shouldn't they simply to do the nomination all over again should they find the one or two editors they needed, whether it's a few days or few weeks later? If not, then it should be clarified, as again, this is not currently straight forward except maybe to those who drafted the provision.  Done the related processes section - I slightly see a reason to list RFA (even though I think it's redundant here as it's linked to and mentioned twice, i.e. once in 'what this process is' and also 'appeal'). However what does bot right approvals have to do with anything? I'd personally remove the section. the 'before nominations section': 1st para: It says in the last sentence of the 1st paragrapgh that 'you should attempt persuasion', however it's said in this section under the heading "Dispute resolution or other discussions" that substantial DR must have taken place. Thus the statements do not match up. I'd remove the persuasion bit and make clear that other DR processes must have taken place. It's completely confusing and slightly contradicting as is. Last para: The last two sentences about speedy closes: who does it? How does this bit on speedy closes tie in with this section dedicated to speedy closure? the "Nominators Not subject to ArbCom or other restrictions" provision - I think it could be revised. While, we shouldn't step on Arb's toes (thus leave that bit as is), for community restrictions we should allow people to go ahead, since it's the community placed and oversees these restrictions. If a statement is made in the nomination or poll by an uninvolved admin or crat that the editor is under such restrictions, then it's up to the community at large to weigh the evidence. We shouldn't make this a closed process. I don't see a problem. If 10 editors who are not under restrictions can't be found, why would we want it to ahead as the following "Tip for editors" says. Ben MacDui 15:12, 30 January 2010 (UTC) the provisions on Blocked editors In reference to them as nominators: I'm glad the current wording is clearer than yesterday, as it sounded as if blocked editors should somehow evade their blocks. We may wish to clarify that they may be unblocked at uninvolved admin discretion to take part in discussion. I'm unsure if limiting their participation to the talk page of CDA only is fair or needed.  Done Allowed to participation in discussion! (under the 'discussion sub-section') -- This is why clarifications are needed. In the sub-section, a provision is made for blocked editors to discuss in the CDA if the admin blocked them or it's related, etc. However it's not clear how this will happen. We don't want blocked editors reading this and then evading their block to discuss, as they'll get in more trouble. Clarity is key, i.e. blocked editors who believed they're affected by the CDA should request an unblock in the usual way making clear they wish to participate in the CDA. That way an admin can unblock with the condition they only discuss in the CDA. Other thoughts Editors of good standing Resolved  – Seems unlikely to be re-added at this stage. Currently it's been left out of the draft I read, but should there be a push to re-add it, my comments on why it's completely redundant and would only serve to make the process reclusive and ambiguous are noted here. As of now, its inclusion would be a reason for me to reject the policy. Admins who go on Wiki-break? Unresolved  – Wording being discussed below. Not discussed, but I can foresee it happening -- what about admins who decide to go on wiki-break after they realise it's heading towards a CDA? Essentially it doesn't run foul of the current 'validity' section found in the guidance, but would there be a way to make it clearer, i.e. since it's a community process admins who have decided to take a wiki-break and not offer a statement in their defence do so at their own risk? I'd just hate to see the inevitable passing of a CDA, only to have the admin and his mates claim it was an unfair process as he went on break right before the CDA and wasn't able to make a statement in his own defence. NJA (t/c) 10:51, 29 January 2010 (UTC) Reactions There's a lot to react to, here. I'll try to address every point, in the same order as above. That's me, I originally wrote this talk section, and others started inserting comments within, which may have created the confusion. --Tryptofish (talk) 21:14, 30 January 2010 (UTC) (Please sign each point, so we can all contribute to this section!) Account more than 3 months: You are absolutely correct. Let's change "more than" to either "at least" or "a minimum of". 'At least' is (to me) the least ambiguous of how long they needed to be registered. NJA (t/c) 18:57, 29 January 2010 (UTC)  Done. --Tryptofish (talk) 20:09, 29 January 2010 (UTC) Stale signatures. This strikes me as something where we could choose between either of two approaches. One would be, as NJA says, to say that, if there are fewer than 10 signatures after 7 days, then the nomination process is aborted, and editors have to start over from scratch if they eventually find the needed 10. However, that is not the only possibility. The other, which is what I think we have been contemplating all along, is that, simply, the nomination cannot be certified to go forward for a community !vote on day 7 if, for example, there are only 9 signatures. Let's say, for example, that on the first of those 7 days of a failed nomination, 2 editors started the process by signing. Then, over the next 6 days, 7 more editors signed, for a total of 9 signatures on day 7, and it does not get certified. Now, let's say the next day (the 8th), a 10th editor arrives and signs. In this case, editors 1 and 2 must refresh their signatures, while editors 3 through 10 already have valid signatures, and the nomination is now valid to be certified. On the other hand, if it takes a month for a 10th editor to show up, then, indeed, all 10 editors have to start over. Is there a problem with that, or with similar scenarios? I don't see it. I don't see why we would have to make that change. Why even bother with all these scenarios? If they don't meet the requirements by day 7 then it's over and do it again. If this isn't agreed here that's fine, though I'll mention it a the request for comment so we can see what to do with it. NJA (t/c) 18:57, 29 January 2010 (UTC) Bots approval. Not a big deal to me, probably Uncle G was thinking about making people understand his reasoning and we just always left it there, but I'd be perfectly happy to either delete the bots approval line or just delete the section.  Done (deleted the whole section). --Tryptofish (talk) 20:09, 29 January 2010 (UTC) Persuasion before nomination. You are absolutely correct, that was an unrecognized contradiction. I think the easiest way to fix it is to delete "You should" at the beginning of that sentence, and just start it with "Attempt..". Does that work? Well attempt doesn't mean must, thus if they must use dispute resolution then say so there too. To me, dispute resolution is persuasion in itself. No? NJA (t/c) 18:57, 29 January 2010 (UTC) Done (changed "You should" to "You must"). --Tryptofish (talk) 20:09, 29 January 2010 (UTC) I still would ask for more clarity if at all possible, e.g. "as noted above in the "Dispute resolution or other discussions" heading, you must have done DR" (or whatever wording that makes the same point). I know it's a bit repetitive, but it would reduce any ambiguity that may exist for readers unfamiliar with the structure of the guidance. NJA (t/c) 13:03, 30 January 2010 (UTC) Speedy close. Again, absolutely correct. Change "speedily closed" to "speedily closed by an uninvolved Administrator or Bureaucrat." Done. --Tryptofish (talk) 20:09, 29 January 2010 (UTC) Clearer, but I still wonder about this separate sub-section. Couldn't the paragraph state: "repeated frivolous nominations may be considered disruptive. See this sub-section of the policy guidance for more details". (or something along them lines)? NJA (t/c) 13:03, 30 January 2010 (UTC) It already says this higher up. Why bother repeating? Ben MacDui 11:29, 31 January 2010 (UTC) Yes, but that's assuming people who read the page actually read all of it. No reason not to summarise the position clearly. Obviously repetition should be avoided, but not where it's wanted for the sake of clarity. When DR is required say it, and we should avoid using other terms that may not make sense, ie 'persuasion'. If we want DR to be attempted then say it clearly and try not to muddle it up. NJA (t/c) 12:00, 1 February 2010 (UTC) Two points in green color about nominators. I'm not sure what to say. My sense is that the community feels pretty strongly that they want that editors who are "sanctioned" in whatever way should not be in a position to initiate the process against an administrator as "payback". The feedback has been pretty loud and clear about that. Instead, such editors should have to be able to convince 10 "eligible" editors to take up their case, and if they can't, then no CDA. But those editors should be able to !vote and comment, so others can see and evaluate their concerns, and the closing Bureaucrat can decide whether or not to count their !vote. I do not know what to change, and I would agree with MacDui, above, that we should use the earlier wording, unless someone can explain more clearly why we should not. I was most concerned about community imposed sanctions. If a notification or declaration is made that they're under such restrictions, it should be up to the community to weigh the relevance it bears on the nomination, not a admin or 'crat. Same thing goes for limiting their discussion to the talk page, relevance should be determined by the community as this is a community process and a community imposed restriction, and the decision shouldn't be made by a distinct sub-section of the editing community. This might be something to note in the RFC. NJA (t/c) 13:03, 30 January 2010 (UTC) How do blocked editors comment without evading their block? Once again, you are absolutely right, and that went right past us. We need to fix that. Change "(unless blocked by the administrator being reviewed and when the CDA is materially related to that block)" to "(unless blocked by the administrator being reviewed and when the CDA is materially related to that block, in which case an uninvolved administrator, on request, shall unblock the editor for the sole purpose of participation in the CDA)", or maybe a better wording if someone can think of one. That wording you came up with is pretty spot on. NJA (t/c) 18:57, 29 January 2010 (UTC)  Done. --Tryptofish (talk) 20:09, 29 January 2010 (UTC) "Good standing". Yes, I think we agree that we had better not go back to the earlier flawed wording. Wikibreaks. I see the point. There would be nothing wrong with adding wording to clarify that. What would that wording be, and where? Could be a quick note in the validity sub-section, ie an admin taking a conveniently timed wiki break will not perclude this community based process from taking place. Or something a lot less sarcastic! As you might be able to tell, it's time for me to sign off (getting irritable), but great dialogue. Thanks. NJA (t/c) 18:57, 29 January 2010 (UTC) Done, maybe, please check what I did [2]. --Tryptofish (talk) 20:09, 29 January 2010 (UTC) Well actually I think without the addition it was clearer that validity of the nomination wasn't contingent on recognition of receipt by the admin. Maybe the wording could be more direct, in that this is a community process, which only takes place after failed attempts at proper DR, and therefore failed recognition of receipt by the admin (for whatever reason) will not effect the validity of the process. See what I'm getting at, or am I muddling it all up? NJA (t/c) 13:03, 30 January 2010 (UTC) I self-reverted it, then. At this point, I'd need clearer guidance on what, if anything, to do. --Tryptofish (talk) 21:18, 30 January 2010 (UTC) Again, thanks. --Tryptofish (talk) 18:41, 29 January 2010 (UTC)