Wikipedia:Community de-adminship/Pre RfC Summaries

From Wikipedia, the free encyclopedia

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]

  • Proposal 1.1 Replace "10 editors to open" with "7 editors to open"

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:

  • may not be subject to Arbitration enforcement editing restrictions, Arbitration Committee restrictions, or Community restrictions, including, but not limited to, topic bans, project bans, and paroles.
  • must be active editors on the English Wikipedia, with accounts more than three months old and with no fewer than 500 edits.

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:

  • 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.
  • Nominations are not valid unless all of the following apply:

and

  • Discussion and polling proceeds for at least 7 days after discussion opens. Discussion and polling may be summarily closed ahead of that 7 day deadline at the discretion of Bureaucrats and the Arbitration Committee.

Poll finding

  • There were questions about the number of days of prior publicity required and how the information would be publicized to the community.

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

  • No request shall be closed as a de-sysopping if fewer than 50 editors supported the desysopping.
  • Proposal 4.1 Replace current minimum (50) with 100.

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

  • Bureaucrats are given the same discretion, and determine the community consensus in exactly the same manner, as at Requests for Adminship, with one added restriction. In unclear cases, multiple Bureaucrats may be involved. The added restriction is that no request shall be closed as a de-sysopping if fewer than 50 editors supported the desysopping. (The point of the process is determining the consensus of the Community at large.)

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

  • receive 70% community support to continue in their role, or
  • receive 70% community opposition to be de-sysopped.

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:

  • "Thus, for an Administrator to be de-sysopped, a minimum of 50 editors and 70% of those expressing an opinion must support the desysopping."

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:

  • "Thus, for an Administrator to be de-sysopped, a minimum of 50 editors must express an opinion, and fewer than 70% of those expressing an opinion must oppose the desysopping."

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:

  • "Thus, for an Administrator to be de-sysopped, a minimum of 50 editors and a majority of those expressing an opinion must support the desysopping."

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:

  • "Thus, for an Administrator to be de-sysopped, a bureaucrat will review the discussion to see whether both a minimum of 50 editors and a general consensus supports de-sysopping. Consensus is sometimes difficult to ascertain and is not a numerical measurement, but as a general descriptive rule of thumb, above ~80% support for de-sysopping would be acceptable; while support below ~70% would not be, and the area between is subject to bureaucratic discretion."

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:

  • place a sufficient number of supporters on wikipedia for a long enough period to become established, similar to the methods now used for making stealth-socks (but no actual socking is required)
  • +admin supporters
  • -admin detracting admins
  • one now has sufficient power to subtly alter wikipedia's behaviour as one sees fit.
  • With sufficient admins on attacking side, one could speed up the process, and simply start blocking all detractors outright, wheel-warring as necessary. This would -however- attract a lot of attention to the takeover, and thus might lead to foundation intervention.

--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:
  • Bureaucrats determine the consensus of the community, using both the opinion poll and the discussion on the talk page.
Poll finding
  • Some repondents felt that this put too much onus on Bureaucrats. Note that input from Bureaucrats is being/has been sought.

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
  • There are two outcomes. Either the sysop right is to be removed or it is not.
Poll finding
  • Some respondents suggested a wider range of outcomes might be desirable.

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:...

  • may not be subject to Arbitration enforcement editing restrictions, Arbitration Committee restrictions, or Community restrictions, including, but not limited to, topic bans, project bans, and paroles, without the permission of the Arbitration Committee or another person or group empowered to lift those restrictions.

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[edit]

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[edit]

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[edit]

Would you support a two-phase poll at RfC?

Result: Overwhelming opposition to a two-stage process.

Vote 4[edit]

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]