Summary of discussion at Wikipedia:WikiProject Administrator/Admin Recall[edit]

The results of the poll were:

No Name Support Oppose Neutral Majority Percentage
0 The status quo 13 44 (-31) 23%
1 Wikipedia:Requests for de-adminship 8 21 1 (-13) 28%
2 User:Tony1/AdminReview 10 20 (-10) 33%
3 Wikipedia talk:WikiProject Administrator/Admin RFC draft 15 18 1 (-3) 45%
4 Wikipedia:Community de-adminship 26 13 1 13 67%
5 Wikipedia:Declaration of no confidence 5 16 2 (-11) 24%
6 Make CAT:AOTR mandatory 1 27 (-26) 4%
7 User:Sandstein/Reconfirmation RFA 6 22 (-16) 21%
8 Straightforward reconfirmation 9 18 2 (-9) 33%
9 Admin reconfirmation 5 7 2 (-2) 42%
10 User:Tim Smith/Administrator-initiated recall 4 14 (-10) 22%
11 AdminRFC+RFA 5 6 2 (-1) 45%
12 Reconfirmation initiated by the Arbitration Committee 5 10 3 (-5) 33%
13 Signatures prompt RFA + extra safeguards 6 6 2 0 50%
14 Regular recall schedule 1 2 4 (-1) 33%


Summary of main discussion at Wikipedia talk:Community de-adminship/Draft RfC[edit]

This is summary of the results of main questions posed.

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

1. Ten editors to open[edit]

Result at date/time of this edit:

Support 0
Oppose 17
Neutral 4

Details archived per above. Ben MacDui 20:04, 2 December 2009 (UTC)[reply]

2. Definition of "editor in good standing"[edit]

See also: section below.

Existing wording: Editors in good standing:

Proposal 2.1 Replace/Add current definition with... "Except where such sanctions were enacted (or were caused to be enacted) by the admin being subject to this process, and the editor is otherwise in good standing".

Result at date/time of this edit:

Support 2
Oppose 8
Neutral 1

Details archived per above. Ben MacDui 19:44, 7 December 2009 (UTC)[reply]

Proposal 2.2 Change second bullet point from 500 edits to 150 edits.

Result at date/time of this edit:

Support 4
Oppose 12
Neutral 1

Details archived per above. Ben MacDui 19:44, 7 December 2009 (UTC)[reply]

Proposal 2.3 For clarity, proposed wording - "Nomination by the Community at large may be initiated by any registered user, though requires the signed support of no fewer than 9 editors in good standing"

Result at date/time of this edit:

Support 1
Oppose 0
Neutral 1

Details archived per above. Ben MacDui 20:08, 7 December 2009 (UTC)[reply]

3. Publicity required[edit]

Existing wording:

and

Poll finding

Proposal 3.1 Change 3 days to 7 days.

Result at date/time of this edit:

Support 20
Oppose 9
Neutral 4

Details archived per above. Ben MacDui 20:31, 4 January 2010 (UTC)[reply]

Proposal 3.2 Modify the second bullet point about publicity.

Result at date/time of this edit:

Support 1
Oppose 4
Neutral 0

Details archived per above. Ben MacDui 20:27, 7 December 2009 (UTC)[reply]


4. A minimum 50 supporters for desysop[edit]

Existing wording

Result at time/date of this edit

Support 0
Oppose 10
Neutral 1

Details archived per above. Ben MacDui 20:10, 2 December 2009 (UTC)[reply]


5. Need more concrete percentages for de-sysoping[edit]

Note: Given how central this issue is to the proposal, this section will not be archived until the period for commenting has ended.

Existing wording

Poll finding Some editors were not clear if this meant that an existing Administrator needed to:

Possible options There are presently four options: 5.1 would require 70% to desysop. 5.2 would require 70% to retain administrator status. 5.3 would require majority sentiment to desysop. 5.4 would require consensus to desysop.

5.1 Add to the current wording:

Result at date/time of this edit:

Support 19
Oppose 17
Neutral 0

Details archived per above. 22:11, 4 January 2010 (UTC)


5.2 Add to the current wording:

Result at date/time of this edit:

Support 1
Oppose 25
Neutral 3

Details archived per above. Ben MacDui 22:11, 4 January 2010 (UTC)[reply]


5.3 Add to the current wording:

Result at date/time of this edit:

Support 6
Oppose 16
Neutral 1 plus two comments

Details archived per above. Ben MacDui 22:11, 4 January 2010 (UTC)[reply]

5.4 Add to the current wording:

Result at date/time of this edit:

Support 16
Oppose 5
Neutral 2

Details archived per above. Ben MacDui 22:11, 4 January 2010 (UTC)[reply]

Plus discussion of "WARNING NOTE" (parts of which only follow)

Numeric/percentage based systems are game-able/can be gamed/have been gamed in the past.

A numeric-based system for de-adminship, in combination with the current percentage-based requests for adminship opens a potential exploit:

A sufficiently well informed and motivated party (be it for the lulz, or for more serious reasons), would be able to perform a hostile takeover of Wikipedia, at least temporarily. As follows:

--Kim Bruning (talk) 14:41, 16 December 2009 (UTC)[reply]

This process seems to be showing an inherent bias in administrators supporting their own. Gaming is likely to work in an admins favor. I favor an implementation of nominators restricted to one nominee per month but a 50% threshold for removal subject to bureaucratic discretion. I don't see that proposal anywhere. By the way the CdA process does have the potential benefit of possibly serving as bait to expose user accounts created for sabotaging purposes that currently silently eat away at the project. Lambanog (talk) 07:03, 31 December 2009 (UTC)[reply]

6. Should not have the Bureaucrats involved at all[edit]

Existing wording:
Poll finding

Result of discussion at date/time of this edit:

Support 0
Oppose 10
Neutral 2

Details archived per above. Ben MacDui 09:18, 3 December 2009 (UTC)[reply]

7. Too easy to game the system[edit]

A general comment and specific wordings may not apply. Poll finding: Some editors believed that Administrators would find the system too easy to beat, even if there was widespread opposition to their continuing in the role, while others felt that it would be too easy to bring frivolous charges against good Administrators.

Result at date/time of this edit:

Support 1
Oppose 2
Neutral/Comments 4

Details archived per above. Ben MacDui

8. Possible outcomes short of full desysoping[edit]

Existing wording
Poll finding

8.1 Replace current wording with... An admin may be desysopped indefinitely, and may only regain the flags by making a new Request for Adminship, or for a period to be determined during the process, of not more than one year. LessHeard vanU (talk) 11:51, 22 November 2009 (UTC)[reply]

Result at date/time of this edit:

Support 2
Oppose 11
Neutral 0

Details archived per above. Ben MacDui 20:56, 4 December 2009 (UTC)[reply]

8.2 Instead, allow for more discussion and not simple bulleted !votes. Result at date/time of this edit:

Support 12
Oppose 0
Neutral 0

Details archived per above. Ben MacDui 20:56, 4 December 2009 (UTC)[reply]

9. Nominators with conflicts of interests[edit]

Current wording: Where nomination is made by editors in good standing, those editors:...

Proposed wording: Where nomination is made by editors in good standing, those editors: ... should not be nominating in a manner which is or appears to be related to a content dispute. Editors which have had recent or well-known content disputes related to the administrator are strongly encouraged to act as if they are ineligible to nominate.

Result at date/time of this edit:

Support 0
Oppose 8
Neutral 1

Details archived per above. Ben MacDui 19:53, 7 December 2009 (UTC)[reply]

10. Allow non-eligible nominations but don't count them as such[edit]

Current wording:

Nomination by the Community at large requires the signatures of no fewer than 10 editors in good standing (defined below), within a period not longer than 3 days. Signatures must be placed in the nomination area of the requests, as a simple signed bullet point.

Proposed wording:

Nomination by the Community at large requires the signatures of no fewer than 10 editors in good standing (defined below), within a period not longer than 3 days. Editors not in good standing or who wish to claim a conflict of interest may nominate, but their nominations will not count toward the minimum. Signatures must be placed in the nomination area of the requests, as a simple signed bullet point. Nominations by editors who have a real or apparent conflict of interest or who are not in good standing must be clearly identified as "ineligible to nominate or conflict of interest" or similar wording.

Result at date/time of this edit:

Support 2
Oppose 6
Neutral 2

Details archived per above. Ben MacDui 20:30, 16 December 2009 (UTC)[reply]

11. Clarify restoration[edit]

Clarify that ARBCOM and others who sanction can restore rights to nominate

Proposed wording: Current wording: Where nomination is made by editors in good standing, those editors:...

Result at date/time of this edit:

Support 1
Oppose 0
Neutral 5

Details archived per above. Ben MacDui 20:03, 7 December 2009 (UTC)[reply]

12. Not to be used during arbitration[edit]

Current wording: None.

Proposed wording: This process may not be initiated while the administrator is the subject of an arbitration case concerning the use of his or her administrative tools, or while such a case is pending acceptance by the arbitration committee. If this process is already underway, it is strongly encouraged that anyone considering filing such an arbitration case refrain from doing so until this process is concluded.

Result at date/time of this edit:

Support 8
Oppose 12
Neutral 1

Details archived per above.

13. Repeat attempts at CDA[edit]

Current wording: none.

Proposed wording: This process may not be restarted against an admin who fails to be de-sysoped by the community for a period of three months. However, Arbcom may recommend a new process within 3 months of a failed de-adminship.

Result at date/time of this edit:

Support 6
Oppose 11
Neutral 2

Details archived per above. Ben MacDui 21:02, 4 January 2010 (UTC)[reply]

14. Allow Bureaucrats to directly desysop[edit]

Proposals to allow 'crats to desysop users through Special:UserRights have been rejected in the past due to lack of a community desysoping process. If we go forward with this I think that including a request from the community to the devs to allow this would make a lot more sense. If the 'crat is making the decision there isn't really any reason not to allow them to implement it. ⇌ Jake Wartenberg 20:52, 27 November 2009 (UTC)[reply]

Result of discussion at date/time of this edit:

Support 1
Oppose 2
Neutral 4

Details archived per above. AndrewRT(Talk) 22:48, 11 December 2009 (UTC)[reply]


15A Violation of rules[edit]

Violation of rules result in desysop if admin is stubborn and refuses to admit breaking the rule and does it multiple times Proposal: If an administrator violates a rule, they will be desysoped ONLY if they don't have a reasonable excuse that has widespread support and violates a rule in a way that doesn't actually concretely improves Wikipedia (if they do, they can invoke the IAR (ignore all rules). Such clear rule may eliminate the contentious desysop process. There will be some leniency, such as breaking a rule AND refusal to correct the mistake when notified is permitted a maximum of once every calender year.

Result at time of this edit.

Support 0
Oppose 5
Neutral 0

Details archived per the above. Ben MacDui 20:17, 2 December 2009 (UTC)[reply]

15. Spell out expectations about canvassing[edit]

15.1 Add the following sentence: "Parties to the CDA process may legitimately contact other editors to provide input, but must at all times do so in strict accordance with WP:CANVASS."

Result at date/time of this edit:

Support 6
Oppose 4
Neutral 2

Details archived per above. Ben MacDui 20:51, 4 January 2010 (UTC)[reply]

16. Improve language[edit]

Improve the language about when to use or not to use the process

16.1 In light of discussion that keeps coming up here about concerns that the process can be "gamed", I suggest expanding some passages in the current draft proposal, by adding some text that was well-received in this proposal written by Beeblebrox. The existing text is in regular font, and the suggested additions are in green.

Under "What this process is not":
Dispute resolution or other discussions: Dispute resolution should proceed through the normal channels. Disputes with an administrator should be discussed first with that administrator, and then via the normal channels of third opinion, mediation, request for comment, and arbitration. Mild or one-time only incivility should instead be reported to Wikiquette Alerts. If the administrator is listed at Administrators open to recall and you believe the conditions listed there have been met, they should be reported there.
Under "Before nomination":
Consider that nominations that do not address the core issue of whether the community as a whole does or does not trust the account to have the sysop right will likely fail, and possibly backfire spectacularly. Determining that is the purpose of this process. If this is not the issue in your case then you are in the wrong place. In all but the most extreme cases, there should be a demonstrable pattern of repeated unacceptable behaviors, not just a single incident. Processes like this one usually result in intense scrutiny of all involved parties. The bright light you are about to shine on a particular administrator will reflect on you as well.

Result at date/time of this edit:

Support 11
Oppose 0
Neutral 1

Details archived per above. Ben MacDui 21:18, 4 January 2010 (UTC)[reply]

16.1.5 Prior discussion

Tighten wording regarding prior discussion with administrator

I regard the following as a friendly amendment to the above:

"Disputes with an administrator should must be discussed first with that administrator, and then via the normal channels of such as third opinion, mediation, request for comment, and arbitration." --Tryptofish (talk) 18:07, 13 December 2009 (UTC)[reply]

Result at date/time of this edit:

Support 7
Oppose 0
Neutral 2

Details archived per above. Ben MacDui 21:18, 4 January 2010 (UTC)[reply]

16.1.6 Multiple resubmissions

Tighten wording regarding multiple resubmissions

I would like to see wording at the end of the notice along the lines of:

Repeated resubmissions of failed RfDA's may result in measures taken to protect the project from repeated frivolous submissions that may include, but are not limited to, suspension of editing privileges.

Wording, of course, is open to suggestion. -- Avi (talk) 06:55, 15 December 2009 (UTC)[reply]

Result at date/time of this edit:

Support 5
Oppose 0
Neutral 1

Details archived per above. Ben MacDui 21:18, 4 January 2010 (UTC)[reply]

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.

Results of Community de-Adminship 'Proposal Finalization' Poll[edit]

A "Community de-Adminship 'Proposal Finalization' Poll" was conducted between 15th and 24th January 2010., with four question being asked.

Vote 1

Do you prefer a 'baseline' percentage of; 50%, 60%, 66%, 70% or 75%?

Voting result:

Second choices votes are in brackets:
  • 50%: 14 (12)
  • 60%: 16 (14)
  • 66%: 15 (15)
  • 70%: 25 (25)
  • 75%: 10 (9)
  • Blanket oppose: 4
Total editors participating: 84

Most contributors gave a "second choice" !vote. Whilst different in detail, the results had a similar spread to the above, with the second-choice percentage of both the lower and higher "extremes" gravitating towards the mid-to-upper 60s.

Vote 2

Do you prefer a 'desysop threshold' of 80% or 90%, or having none at all?

Voting results:

Second choices votes are in brackets:
  • 80%: 26 (1)
  • 85%: 01 (0)
  • 90%: 24 (1)
  • "None" 20 (10)
Total editors participating: 77 (including oppose votes)

Vote 3

Would you support a two-phase poll at RfC?

Result: Overwhelming opposition to a two-stage process.

Vote 4

If you wish to voice your opinion here by voting "Oppose" to CDA in general, you may do so, but it will not be binding.

Result: A number of people oppose the CDA concept.

A variety of possible interpretations and conclusions resulting from the above expressions of opinion were discussed at WT:CDADR. Ben MacDui 20:03, 27 January 2010 (UTC) Revised Matt Lewis (talk) 01:04, 1 February 2010 (UTC)[reply]