This is Round Two of the 2013 request for comments on RfA. Please offer suggested solutions to any of the following four problems (as determined in round one), and discuss and vote on other suggested solutions as well. This round will end in 30 days, or possibly sooner. The closers will share their thoughts on what's coming in Round Three in the middle of this round. - Dank ( push to talk) 02:41, 6 February 2013 (UTC) reply

Many things that cause problems at RfA are external to RfA.

Tiering of the overgeneralized admin role would help immensely

Moderator

It's been made clear many times that for technical reasons, we shouldn't split the user-group sysop (aka admin). But instead should make other user groups including such split tools. So far, the main opposition seems to be those who just don't want anything split from admin, or those who fear the community won't as thoroughly vet a candidate for this package as they would for the admin package. But setting those issues aside for a moment (they can be discussed in separate sections), based upon years of discussions, the following package seems to be what has the most support.

Proposal

A new user-right package (aka user group) designed primarily to allow someone granted it the option to help with content-related admin tasks (for which there is often a backlog) – For example, to allow for implementing the close of content-related discussions like: RM; DRV; AfD / CfD / FfD / TfD / MfD / etc.; various talk page and noticeboard RfCs; and so on. In addition, assessing CSD, and PROD, and edit-protected requests, and other such content-related tasks which would be related to the tools granted in this user-rights package. In broad terms, this means that those with this user-right package should have the ability to: delete/undelete pages (and related abilities); move most pages (and related abilities); deal with files; and edit protected pages.

What this user group should NEVER include: Any tools which directly deal with the assessing of editor behaviour. In particular: protect or block-related tools. Semi-related to this, no tools which grant user-rights to editors. Also not included are a couple very rarely used deletion tools. If the moderator needs such things done, they can simply ask an admin.

The tools in this package were specifically selected due to their interdependency in application and usage.

Per Special:ListGroupRights, there are currently 52 (plus two more to add and remove certain user-rights) in the administrator user group.

Besides the deletion tools, there are only 5 tools in this package which aren't already given to autoconfirmed.

So out of the 54 user-rights included in sysop, this package only includes 16, and adds editprotected (which isn't in the administrator user group due to admin having protect).

List of user-rights included in the Moderator user-right group

Edit protected pages

• autoconfirmed – Edit semi-protected pages
• editprotected – Edit protected pages (without cascading protection).

Handle deletion

• delete – Delete pages
• undelete – Undelete a page

• deleterevision – Delete and undelete specific revisions of pages

• deletedhistory – View deleted history entries, without their associated text
• deletedtext – View deleted text and changes between deleted revisions
• browsearchive – Search deleted pages

Handle moves

• move – Move pages
• movefile – Move files
• movestable – Move pages under pending changes
• move-subpages – Move pages with their subpages
• move-rootuserpages – Move root user pages
• suppressredirect – Not create redirects from source pages when moving pages

Handle files

• upload – Upload files
• reupload – Overwrite existing files
• reupload-shared – Override files on the shared media repository locally

Oppose Moderator

1. Largely per DGG in the Discussion section below. There have been several successful unbundlings, but they involved a particular tool where there was a need to give that one tool to people who could be trusted with that tool but the community was not yet prepared to give them that whole set of tools and particularly the core ones of deletion and blocking. Ϣere SpielChequers 14:52, 13 February 2013 (UTC) reply

   So you trust the community to hand out adminship, but you don't trust the community to hand this out? - jc37 16:47, 13 February 2013 (UTC) reply

   I don't want this subset handed out to people who wouldn't be trusted for full adminship. I have no problem supporting candidates who are very clear that there are certain parts of the mop that they will never use - I recently supported someone at RFA who only wanted to view deleted edits. Ϣere SpielChequers 12:44, 14 February 2013 (UTC) reply

   I agree. But (as I note below and elsewhere) there are those who would like to help out with such things, but do not wish the "entire" admin package. So why should we "force" them to carry it? Because we demand they take all or nothing? If we trust them with discernment of when to use certain tools, why can't we trust them to only ask for the tools they wish? Yes some tools are interdependent, which is why I built this as a package. But one not need to be able to block other users to be able to close a deletion discussion (just for one example). So what is your concern with trusting the community to trust the individual to make this choice? - jc37 17:08, 28 February 2013 (UTC) reply

2. Per DGG below and WSC above. I'm not sure how these rights are to be given out. Is it by request as with rollbacker, with one admin deciding, or by a new form of RfA type discussion? Peridon ( talk) 16:59, 17 February 2013 (UTC) reply

   I would strongly oppose this package given out like rollback. It should be a RfA-like discussion. - jc37 17:08, 28 February 2013 (UTC) reply

3. Critical trust based functions not logged handed out on less than a full RfA basis - no thanks. Leaky Caldron 15:29, 19 February 2013 (UTC) reply

   Not logged? Where do you get that idea? And it should be granted through a rfa-like discussion. - jc37 17:08, 28 February 2013 (UTC) reply

Discussion of Moderator

• This has the same objections as the original proposal. The deletion/undeletion rights are among the most sensitive of all the admin writes, and can have equally far reaching consequences as protection or blocking. I cannot imagine anyone fit for this right who would not also be fit for the full admin package. DGG ( talk ) 17:56, 7 February 2013 (UTC) reply

  So despite people repeatedly stating that they don't want all the tools of the admin package (for various reasons, including wikignomes, quakers and those with aspergers, among others), you don't care about their wants, and will force people to take all the tools or they can't have any? - jc37 16:47, 13 February 2013 (UTC) reply

  That's an interesting spin. Why would a wikignome want or need those rights? Isn't that what admins are here for? I've never had a problem getting help from an admin when I needed it – for any reason. I do a lot of gnome-edits. Why on earth would I need or want to be able to delete/undelete pages? –  PAINE ELLSWORTH  ^CLIMAX! 15:42, 27 February 2013 (UTC) reply

  Assessing CSDs, for one example. And I've heard from many Wikignomes saying they would like this kind of package to help out with, while not wanting block-related tools. - jc37 17:08, 28 February 2013 (UTC) reply

  No, I never had a problem with those, just put a quick db template on the page and an admin comes along to take care of business. I need that so rarely, it just doesn't justify my having the tool. Now maybe we could touch on what's really going on? There are a lot of admins that "specialize" in the use of this tool or that tool. They might work all the time on CSDs and never go near the block tools. Why should they if they don't want to? All your gnomes need to do is become admins and they have what they want. So it's really a question of "Why don't they do that?" Why don't they run the gauntlet? What exactly are they not sharing with you? Are they afraid to face the community? What? –  PAINE ELLSWORTH  ^CLIMAX! 14:28, 1 March 2013 (UTC) reply

Unbundling

I know it is a perennial proposal, but I think it needs to be here.

As a script editor and maintainer, I would find it incredibly useful to be able to maintain gadgets and user scripts. To do so I would need the "editinterface" right, to edit gadget scripts in MediaWiki space, and the "edituserjs" right, to be able to help other users and maintain others' user scripts by editing their personal JS code. At the moment, I do not wish to be able to delete pages or block users; if I were to want those tools as well, I know that "sysop" is the user group I would need to be in, and that RFA is the process for me. However, as it stands, I feel the community would trust me with the limited rights related to script editing, even if I am not ready yet for RFA.

Take a new page patroller (a highly experienced one, of course). They may not need to protect pages or edit system messages, but they may wish to be able to block vandals and single-purpose accounts. They may not wish to be trusted to close controversial RFCs, but they may find it convenient to speedily delete bad pages coming into the New Pages Feed. At the moment they are not able to help the encyclopedia as much as they otherwise might.

Creating more granular user groups is a potential solution, that allows users trusted and experienced in a specific area of WP work to make themselves more useful, without needing to show the broad range of experience required at RFA. This is not a new idea; in fact, rollbacker, accountcreator, and filemover groups have all been "unbundled" from the sysop toolset.

Please, if you're more eloquent than I am, expand on this proposal, and discuss it below. — This, that and the other (talk) 11:30, 7 February 2013 (UTC) reply

Discussion of Unbundling

Much needed. I put one such proposal (and the rationale for it) at the top of this page. It was stated as something that would have the details tuned later, but folks are responding on the particular details. North8000 ( talk) 12:02, 8 February 2013 (UTC) reply

• I don't know anything about editinterface & edituserjs but there would certainly seem to be a case for unbundling these technical tools. I think the problem with unbundling most of the main tools (eg delete, protect, block) is that they can be used both in simple uncontroversial ways and in ways requiring considerable judgement. Espresso Addict ( talk) 21:31, 8 February 2013 (UTC) reply
• There have indeed been several successful unbundlings and there could usefully be more. The golden rules for a successful unbundling are:

1. Don't make it easier to delete other people's work. You'd delight the deletionists, but worry enough others to sink this sort of proposal.
2. Because deleted edits include copyvio the legal dept are very chary about insufficient scrutiny of the people who can do this.
3. Don't make it easier for people to block the regulars. Whether it is concerns about "civility police" or over enthusiastic admins blocking longstanding contributors, enough of the regulars are wary as to who can block them that it would be difficult to get consensus to lower this bar.
4. Don't make it over complicated. All the successful unbundlings have been simple ones like Rollback, Accountcreator and Filemover, whilst most of the proposals have been complex ones for large subsets of the admin rights, admin lite, apprentice admins junior admins etc. Ϣere SpielChequers 17:52, 16 February 2013 (UTC) reply

Probationary period for (at least some) new admins

I believe that a lot of the opposition and negativity in RfAs is due to a perception that if a candidate is given the tools, it will then be difficult or impossible to remove them if they later turn out to be unsuitable. I propose that newly appointed admins (perhaps limited to those that are borderline at RfA or where support falls below a certain level) serve a probationary period (say 3 or 6 months), during which they are under 'review', effectively open to recall for a specified period, and receive mentoring in admin tools. Any misuse of the tools within this period beyond accidental misuse, demonstration of lack of competence, or valid block, would lead to desysopping, or temporary banning from using certain tools, and this would need to be fairly strictly enforced (with no 'but they do a lot of good work' get out clause or IAR exemption for example). At the end of the probationary period they would either become 'permamnent' admins or have the probationary period extended, perhaps with a similar process to RfA but based on the closing bureaucrat judging the validity or otherwise of opposition rather than vote counting - a candidate passes probation unless there is a convincing reason put forward against it. Basically, I feel that people would be more inclined to give candidates a chance if they are more confident that the tools will be removed if they if they prove to be unsuitable. There is also the problem of people citing a lack of experience in administrative areas as a reason to oppose. This would allow candidates to gain that experience before becoming 'permanent' admins, and it may allow candidates with a lower percentage of support to progress to a probationary period - 65% support for example. It may also encourage more people to go through RfA, with more confidence of a successful outcome, particularly if the mentorship aspect of probation would give them confidence that they will get the help they need to 'get it right'.

If such a process were put in place we would need to ensure that frivolous complaints about new admins can be dismissed quickly and without creating drama - candidates would need to be confident that they going to get fair treatment during their probation.

Support Probation

1. As proposer. -- Michig ( talk) 19:05, 8 February 2013 (UTC) reply
2. Best suggestion so far. Leaky Caldron 19:14, 8 February 2013 (UTC) reply
3. I like this, because it makes RfA less draconian, less black-and-white. RfA participants that are neutral or uncertain can approve, knowing that if anything goes amiss during the probationary period, that a revocation is possible. Of course, the revocation during the probationary period must be relatively easy (contrasted with after-probationary-period revocations). -- Noleander ( talk) 19:30, 8 February 2013 (UTC) reply
4. Good idea. This would help more people get through RfA, while also setting up a process to desysop or discipline bad admins early on, thereby solving two problems in one stroke. It might also get people to relax their standards, knowing that a successful candidate will still be on a tight leash. Everyking ( talk) 20:41, 8 February 2013 (UTC) reply
5. Good idea. I wouldn't support reducing the %age threshold to pass, but it would certainly make me less likely to oppose. I'd suggest all new admins, not just on support %age (as some of the problematic admins in the past have had high support %ages). The 3-month review would need to be simple and low stress, while allowing an opportunity for good-faith editors to come forward and express concerns. Espresso Addict ( talk) 21:24, 8 February 2013 (UTC) reply
6. Yes yes yes. Brilliant idea. The reconfirmation process could either be a discussion (no voting), or a simple support/oppose vote with a separate section for discussion. I wouldn't like to put people through a "second RFA", so I think this process would have to be run slightly differently! — This, that and the other (talk) 00:18, 9 February 2013 (UTC) reply
7. A reasonable step in ensuring competent admins are entrusted with the tools. dci | TALK 06:23, 10 February 2013 (UTC) reply
8. Support. A provision for a probationary period could eliminate a lot of the angst that gets expressed in RfAs. -- Orlady ( talk) 07:33, 10 February 2013 (UTC) reply
9. Would make it easier to support candidates who may be lacking experience in some areas.-- Staberinde ( talk) 10:55, 10 February 2013 (UTC) reply
10. I like this idea a lot. I agree with others that it would reduce a lot of the unpleasant atmosphere around RfA. I think it would actually be helpful to some admins. I'd also like to take issue with some of the oppose rationales. Although I agree that many of the cases involving desysoppings have involved long-time admins, that really is a red herring. This proposal doesn't have to solve every problem; it solves some of them. The fact that we don't have formal, empirical evidence that the difficulty of desysopping contributes to the high standards at RfA does not mean that it doesn't happen. I'm convinced that it does, if for no other reason than that it influences my own comments in RfAs. -- Tryptofish ( talk) 00:27, 12 February 2013 (UTC) reply
11. Support, or at least support on a trial basis. While it's true that new admins don't tend to be frequently deadminned, I've certainly seen candidates opposed out of fear that they might "go of the rails" and do something crazy, often not so much for evidence that they would, but lack of evidence that they won't. It might be a lot easier for some editors to support a candidate for a trail period, and it is possible (although by no means, clear) that this would actually reduce RFA tensions. -- j⚛e decker ^talk 05:24, 12 February 2013 (UTC) reply
12. We use a similar "safe-hands" approach when promoting people in the workplace all the time. It works both ways, i.e. the candidate also gets to decide if they like the "job" once they've had a chance to actually carry it out for a while. It's a sensible suggestion that RfA candidates get to use the tools for a 'trial' period. That way, all concerned parties can see if adminship is the right thing for the applicant, and it could encourage more editors to apply for what would likely be a slightly less-stressful RfA experience. — sparklism ^hey! 08:42, 12 February 2013 (UTC) reply
13. I support as per nom, this is a good idea and may help encourage both new admins, as well as give the community a bit more comfort with giving out more tools to people who otherwise might have been considered boarderline. Tiggerjay ( talk) 19:56, 13 February 2013 (UTC) reply
14. Support, as a casual observer of RfA's I can't claim to be the expert on the tools but this seems like a sensible proposal. It might make RfA less of a daunting proposition for editors. I think many responsible editors would volunteer to be on 'trial' anyway as a show of good faith. Cabe 6403 ^{( Talk• Sign)} 10:41, 15 February 2013 (UTC) reply
15. Support. It might reassure some super cautious voters at RFA that we are not handing the mop to a renegade who will misuse it. However I cannot think of many "new admins run amok" who would get de-adminned by this process. Edison ( talk) 18:42, 19 February 2013 (UTC) reply
16. Support. New admins should usually stay away from controvertial areas, as one needs to have significant experience to handle those correctly, removing one of the major objections frequently given for a community desysoping process. And any enemies a new admin will have made will probably need to wait longer than that before resurfacing under new IDs, removing an other objection. עוד מישהו Od Mishehu 21:55, 26 February 2013 (UTC) reply

Oppose Probation

1. Most desysops are of longstanding admins who've lost touch with or drifted from standards. So I see this as a lot of extra work and hassle for little benefit. Ϣere SpielChequers 00:09, 10 February 2013 (UTC) reply
2. What he said. New admins are not the problem, indeed they tend to be much more cautious with he tools, I know I was terrified when I placed my first block. The problem is at the other end, and this proposal has more holes than Swiss cheese anyway. Beeblebrox ( talk) 00:22, 10 February 2013 (UTC) reply

   • But we're discussing 'new admins' here and the RfA process, not longstanding admins. New admins don't get desysopped because unless the community are very convinced of a candidate's suitability they don't get the tools in the first place, or don't put themselves forward because the whole thing seems too daunting. -- Michig ( talk) 07:40, 10 February 2013 (UTC) reply

3. This would probably just increase the drama, as the probationary candidates come forward for a second round of close scrutiny. What's needed instead is a more simple recall mechanism. Carrite ( talk) 02:53, 10 February 2013 (UTC) reply

   • So propose one. -- Michig ( talk) 07:40, 10 February 2013 (UTC) reply

4. I don't like the idea of proposals that add extra layers to what is already a complicated process. And do we really have an "admins run amok" situation that requires the creation of additional processes for whetting new admins or recalling existing ones? -- regentspark ( comment) 14:20, 10 February 2013 (UTC) reply

   As a supporter, I think it's more about encouraging the more-stringent of RfA participants to find it easier to trust candidates who are borderline in their experience, by providing an opportunity to review the editor's administrative contributions after election and, if necessary, to relieve them of the privileges without too much drama. The problem, if there is one, of "amok admins" would have to be addressed by a separate process. Espresso Addict ( talk) 17:45, 10 February 2013 (UTC) reply

   I see what you mean. You're hoping that more candidates will pass the first round because there will be the possibility of deadmining them down the road. I believe this has come up before as a proposal and that, at that time, I felt that it wouldn't work because it will discourage new admins from making difficult decisions till after the review period (human nature being what it is) and that the whole system will revert to the status quo with an extra layer added on. -- regentspark ( comment) 22:54, 11 February 2013 (UTC) reply

5. There is no evidence that the rise in standards at RfA is caused by concern about the difficulty of desysoping. On the contrary, the rate of desysoping by arbcom has increased markedly over the last few years, even as RfA standards have continued to rise. So adding a probationary period would just make it harder to be an admin, thus discouraging people from doing it, thus leading to fewer admins, when the goal should be more. Chick Bowen 23:50, 10 February 2013 (UTC) reply

   I think that a couple of your points are off the mark here:

   1. "the rate of desysoping by arbcom has increased markedly over the last few years" - and since the amount of process going into a dewsysoping is high (it must go all the way to ArbCom), this would seem to me to make RFA harder, not easier.
   2. "adding a probationary period would just make it harder to be an admin" - it may make it less attractive at first, but as the probated admins become full-fledged admins (and most will), the success rate of RFA will go up and users are more likely t try the RFA.

   עוד מישהו Od Mishehu 20:00, 27 February 2013 (UTC) reply

6. Solution in search of a problem. Ruslik_ Zero 13:03, 14 February 2013 (UTC) reply
7. I think a lot of candidates don't provide a roadmap for their own improvement or explicitly volunteer to steer away from area(s) where !voters have complained about their lack of experience. Assuming they bring other assets to an admin position, I've seen enough non-perfect candidates approved if they would just manage other's expectations better.— Bagumba ( talk) 18:41, 14 February 2013 (UTC) reply
8. This proposal solves nothing because it is easily gameable. The only thing that this will cause is that admins will be super-cautious for the first 3-6 months, careful not to do anything remotely controversial. Then, after the probationary period, they will resume being themselves. ‑Scottywong | squeal _ 06:08, 19 February 2013 (UTC) reply

   I think that many admins probably go through a stage of "oh, wow, I can do all this" (I certainly did). This proposal makes sure that they do this at a time when they should be staying out of the controversial areas. עוד מישהו Od Mishehu 20:00, 27 February 2013 (UTC) reply

9. Per Ruslik and Scottywong. Stifle ( talk) 12:52, 27 February 2013 (UTC) reply

Neutral on Probation

1. Neutral. This proposal seems to be two for the price of one: unbundling and probation. I support this form of unbundling. It would allow more qualified editors to undertake those particular tasks and may well encourage suitable editors to apply. I oppose the probationary period. This is unnecessary for the majority of new admins and would only increase the workload. Axl ¤ [Talk] 13:32, 12 February 2013 (UTC) reply
2. I support unbundling generally (it's well, well past time we unbundle most of the tools), I'm unsure of a manually managed probation period. A probation period doesn't materially improve trust in the admin corps because most of the community distrust is aimed at admins who would be grandfathered in. It also is another chain of activities we have to show to the community that we can manage. And it's probably just as difficult a technical problem as unbundling generally. If we have to support a probation period to unbundle, fine. But otherwise I'd rather just unbundle the tools. Protonk ( talk) 23:37, 15 February 2013 (UTC) reply

Discussion of Probation

• How were you envisaging the mentor system working? I'd suggest it being independent of the nominators, to exclude potential bias and to prevent additional burden on nominators. Espresso Addict ( talk) 21:24, 8 February 2013 (UTC) reply

• Ideally, but we would have to see who comes forward to offer mentoring. -- Michig ( talk) 06:47, 9 February 2013 (UTC) reply

• Any misuse of the tools within this period beyond accidental misuse, demonstration of lack of competence, or valid block, would lead to desysopping—So this leaves deliberate misuse of administrative tools from someone fully aware of what they're doing? That's a serious issue whether a candidate passed 3 months ago or 3 years ago Jebus989 ^✰ 21:59, 8 February 2013 (UTC) reply

• I would envisage that any deliberate misuse during a probationary period would lead to desysopping. Deliberate misuse by an established admin is certainly something that should be dealt with, but I thought it best to keep that separate from probation in this proposal. -- Michig ( talk) 06:47, 9 February 2013 (UTC) reply

This could easily be gamed. What is to prevent a "bad admin" who managed to make themselves look good to pass RFA, from just keeping it up until this vaguely defined probation is over? They could just lay low and only block obvious vandals until their were free to go rogue. That and the obvious fact that it generally is not new admins that cause dramafests. Beeblebrox ( talk) 00:26, 10 February 2013 (UTC) reply

Just to play devils advocate here but what about the flip side, a ~3-6 month commitment just to have access to the tools and then go nuts is surely more of a deterant than being able to do what they wish immediately after passing. I would have thought a probationary period such as this would reduce the likeliness of gaming the system. Cabe 6403 ^{( Talk• Sign)} 10:37, 15 February 2013 (UTC) reply

Recall, the 20,000' view

There should be an admin recall mechanism of some sort, details to be determined in a later round of this RfC.

Support Recall

1. As proposer. Roughly speaking, I believe that fear of admins going rogue (or other sorts of incremental misbehavior) underlies some problems at RfA. -- j⚛e decker ^talk 05:42, 12 February 2013 (UTC) reply
2. Absolutely. It would create potentially serious problems if we made adminship easier to attain without making it easier to remove, so some form of community recall is a necessary part of what we're trying to achieve here.— S Marshall T/ C 08:57, 12 February 2013 (UTC) reply
3. As much as I'm tempted to say "been there, done that", and I know it's just a matter of time before someone else says it for me, yes, I have always supported this, and I still do. -- Tryptofish ( talk) 21:39, 12 February 2013 (UTC) reply
4. Of course. This is badly needed. Everyking ( talk) 22:29, 12 February 2013 (UTC) reply
5. I suspect any overhaul of RfA intended to make admin privileges easier to obtain needs to investigate mechanisms for their removal, where necessary. Just because no previous proposal has achieved community support does not mean it is impossible. Espresso Addict ( talk) 00:24, 13 February 2013 (UTC) reply
6. Per Tryptofish, with whom I did a bit of work a few years back on WP:CDA, which failed due to the number of admins who opposed. And may I add that we need this process more than ever, in my view, and that it should be as simple as possible. The original Uncle G proposal was the best, also in my view. Jus da fax 00:48, 13 February 2013 (UTC) reply

   Why do we "need this process more than ever"? Stifle ( talk) 12:59, 27 February 2013 (UTC) reply

7. Indeed. Any action that requires arbcom for undoing will always be a "big deal". I don't think RfA can be made significantly more "productive" unless it becomes easier to fix any failures in process.-- Staberinde ( talk) 07:32, 13 February 2013 (UTC) reply
8. Support.... admins should be open for recall, and the process should be easily, and objectively handled. Tiggerjay ( talk) 08:06, 13 February 2013 (UTC) reply
9. Obviously needed. — This, that and the other (talk) 10:12, 13 February 2013 (UTC) reply
10. Definitely needed. dci | TALK 01:58, 15 February 2013 (UTC) reply
11. I would support many more admin candidates on the theory that if they are a bad admin, they can easily be removed. David 1217 ^{What I've done} 04:32, 15 February 2013 (UTC) reply
12. I agree, and the current system wherein a small number of admins set out needlessly specific criteria (6 editors in good standing, plus 2 admins, all within a week) isn't workable Jebus989 ^✰ 10:54, 15 February 2013 (UTC) reply
13. One of the nagging thoughts in the back of my head I have to calm before supporting any candidate at RfA is "What if we're making a huge mistake here?" It can't be undone. Common-sense admin recall needs to be available. Tazerdadog ( talk) 01:37, 16 February 2013 (UTC) reply
14. Support. We need an easier and more open way to do this. Axl ¤ [Talk] 09:53, 18 February 2013 (UTC) reply
15. Agree Secret ^account 03:35, 19 February 2013 (UTC) reply
16. Hopefully this will give a bit of truth to WP:NOBIGDEAL. Right now RfAs are about deciding whether an anonymous person can be trusted with the world's 5th largest website, for life. If adminship is easy to take away, people will hopefully be less paranoid about giving it. -- Ypnypn ( talk) 03:56, 26 February 2013 (UTC) reply

Oppose Recall

1. Oppose until anyone can convince me that "fear of admins going rogue" is actually an issue. I'll admit on some levels there is a conception that admins have to be really trustworthy otherwise they'll go bad, but that fear is much more irrational and subconscious than you're portraying it, and this proposal won't solve the problems we're trying to address right now. A "backup plan" just won't make people support candidates more often. — Rutebega ( talk) 22:49, 12 February 2013 (UTC) Oh, and ArbCom is still a thing, as was repeatedly brought up in the RRA proposal last month. — Rutebega ( talk) 22:51, 12 February 2013 (UTC) reply

   It is true that admins don't tend to "go rogue" on us, thank goodness. I think the problem here is one of minor indiscretions that tend to mount up over time. I have seen admins who begin to bite newbies and who behave in a less civil manner after their RFA; this is hardly "going rogue", but it is a problem that can be solved by recall (or, even better, by reconfirmation after a given time period). — This, that and the other (talk) 11:09, 15 February 2013 (UTC) reply

2. Oppose we do have an issue with admins going rogue, that's why we have Arbcom, arguably we also need to get rid of inactive admins, and the crats do that. Now I don't dispute that Arbcom is a flawed and error prone institution, but it does exist and it certainly does desysop lots of admins. If people want to propose reforms of Arbcom or even replacements to it then I'd welcome the debate. But why would we need a third way to get rid of admins, and what sorts of admins would this get rid of that Arbcom and the crats won't? We need to remember that our problem is a declining number of admins and a general unwillingness to run amongst experienced non-admins. A third way to get rid of admins without some of the safeguards of the existing two is really not going to help us recruit admins or retain those we still have. If the proposal was clarified so that we knew what sort of admins you were trying to get rid of then it would be a little less damaging, but I suspect you'd have difficulty agreeing that or getting consensus for purging any particular subset of admins that Arbcom and the Crats won't currently desysop. Ϣere SpielChequers 14:39, 13 February 2013 (UTC) reply
3. Oppose. it is not a serious proposal due to lack of details. Past proposal have always failed because of details. Ruslik_ Zero 13:06, 14 February 2013 (UTC) reply
4. Oppose. Too complicated and too many admins will go through recall each week. And it's missing details. How long will it take before a recall takes place? What's the criteria and threshold? How to determine consensus. I don't see any of those being addressed. OhanaUnited ^{Talk page} 03:42, 15 February 2013 (UTC) reply

   Reply Generally, the word "recall" gets used, and is intended to be used here, for processes in reconfirmation only happens after something happens, perhaps some number of editors certify a concern, or what have you. When you talk about "recall each week", I believe you're talking about a separate type of proposal such as the one below, which is usually referred to as "Mass RfA Elections", periodic reconfirmation RfAs, or termed adminships, or something like that. That's not what we're talking about here. In any case, I believe most readers here understand that I'm talking about, yes, a very general proposal that will be narrowed down in later stages of this discussion, but generally speaking a process in which there's some triggering cause for looking into a potential problem with an admin, and then some later process for deciding whether the cause is sufficient to remove adminship. -- j⚛e decker ^talk 04:42, 15 February 2013 (UTC) reply

5. Oppose. I believe that being open to recall is an important feature of adminship, but the practical implication of a streamlined process is that it will inevitably be weaponized at some point in time, and the last thing we want to do here is further tax good admins—especially those who are willing to make bold or controversial decisions.   —  C M B J   08:22, 16 February 2013 (UTC) reply
6. There already is an admin recall procedure. ‑Scottywong | squeal _ 06:09, 19 February 2013 (UTC) reply

   Scottywong, I think the problem is that people don't feel confident in the ability of an optional, honor-based system to remove bad admins. David 1217 ^{What I've done} 02:56, 20 February 2013 (UTC) reply

7. Oppose, per User:Chick Bowen/Why I am opposed to community deadminship. Chick Bowen 01:15, 23 February 2013 (UTC) reply
8. No, no, and no again. If it's optional, then it becomes mandatory for new admins because you get a load of people mass-opposing RFAs if the admin doesn't want to be open to recall. In general, I am unable to conclude that the recall process would not result in an excess of frivolous or vexatious recall requests. Those of us around long enough to remember WP:CSN will know that a "lite" method to ban users without excessive process turned into a lynching venue with users getting banned in under a day and without having the opportunity to respond adequately. A recall process would do exactly the same and further discourage admins from dealing with controversial subjects. The ArbCom method of desysopping people works quite well, thank you. Stifle ( talk) 12:57, 27 February 2013 (UTC) reply

   Huh, optional recall already exists Category:Wikipedia administrators open to recall, not particularly dominating issue in recent RfAs tough. Not sure how discouraging it is for those admins.-- Staberinde ( talk) 16:47, 28 February 2013 (UTC) reply

Discussion of Recall

• Based on my hard-won experience, I'll make a strong suggestion about the next stage of discussion, now. Whatever the recall method, the final decision should reside with ArbCom. ArbCom is getting better and better at handling these issues. And as much as I believe that, in principle, the decision should rest with the community, I'm uncurably convinced that any other approach will fail to get consensus. -- Tryptofish ( talk) 21:43, 12 February 2013 (UTC) reply

Maybe? I have seen some success so far in this and other processes that a top-down incremental refinement approach may be more likely to generate a workable consensus, whether it be Arbcom-adjudicated or not. Perhaps that and a couple years could make a difference? Hard to say. I realize that history is against me.

I'm embarrassingly unread on what Arbcom has done in this, or frankly, nearly any other area, so if you'd like to point me at some examples of how that is or isn't working, I really have no preconceptions about whether Arbcom has a role here. My view so far has been that there's a strong argument to be made for finding a particular process, and some of the specifics about how it's done, at least so far as I've seen, are less important to me. I've been sort of assuming that there'd be some sort of trigger to "start" the process, what I'd assumed I'd do for a next step if there was one was to throw out some ideas and nail down what the "initiating event" for such a process might look like. -- j⚛e decker ^talk 22:56, 12 February 2013 (UTC) reply

Perhaps I'm being over-cautious here, but I'd rather not name anybody who has been desysopped, censured, or warned by ArbCom. If you go to the Arb page, you can find a link to archives of past cases, and you can look at the results of cases over the last year or so. The way I'm thinking of it, is a sort of alternative to a request for arbitration, with a community discussion superficially resembling an RfC/U, that the Arbs could then deal with, often by motion. I think it could work reasonably smoothly, and it would avoid two of the perennial objections: the "mob with pitchforks"^TM would not make the final decision, and the final decision could, if appropriate, also take a look at the complainants. -- Tryptofish ( talk) 19:43, 13 February 2013 (UTC) reply

That doesn't sound over-cautious to me. Thanks, will spend some time looking around. Most appreciated. -- j⚛e decker ^talk 00:26, 14 February 2013 (UTC) reply

I think you have a strong point here, after reviewing what related cases I could find. We're getting past the specifics of this round (I made the proposal above intentionally broad), but if you'd like to make the case for the Arbcom-adjudicated end in the next round, that'd be spiff. I also feel as if the "trigger" isn't well-defined, any thoughts you have there appreciated (whether here, or we can take it to another talk page or whatever.) Thanks! -- j⚛e decker ^talk 01:36, 14 February 2013 (UTC) reply

• In response to Rutebega's oppose: I can at least provide one example. My own RFA, which was not particularly bad as these things go, had a cluster of opposes stating the fear that I'd be some sort of civility police blocking editors left and right for anything tangentially uncivil. This was based in part on a profoundly poor response on my part to a question (in other words, the opposes were arguably fair) but part of the dynamic there was the difficulty of corralling me if that became necessary. And I have seen some examples of this sort of dynamic since since, and often in the form of emotionally charged opposes and interactions between candidate and questioners, but perhaps it's not that common. *shrug* -- j⚛e decker ^talk 23:12, 12 February 2013 (UTC) reply
  • I read the relevant parts of your RfA, and those first three opposes show that editors were concerned about your interpretation of civility/NPA. On the surface level, you didn't interpret the policy as well as you should have, but I think the root of the issue was that those users feared you would abuse your admin status in some way. However, I think that fear was the irrational subconscious type that can't really be controlled or assuaged, and that's why I don't think this proposal would prevent people from opposing (at least in many cases). Adminship can be removed via ArbCom, and people still worry about rogue admins. If we introduced a community-based recall system, people would still worry then, too, because what about the damage you could do before that, and what if other admins defend you, or what if you have the support of Jimbo, or the Cabal? People sometimes don't listen to reason. If only that weren't the case. — Rutebega ( talk) 01:33, 13 February 2013 (UTC) reply
• Could someone knowledgeable summarise the history of attempts at instituting an admin recall system, for the benefit of those who've not been following them? Espresso Addict ( talk) 00:33, 13 February 2013 (UTC) reply

  I would greatly appreciate that as well. -- j⚛e decker ^talk 01:01, 13 February 2013 (UTC) reply

• Here's a rough history that excludes various informal discussions. Jus da fax 02:27, 13 February 2013 (UTC) reply

Thanks! -- j⚛e decker ^talk 03:41, 13 February 2013 (UTC) reply

If you haven't seen it, WP:RRA is a relatively recent proposal by jc37. — Rutebega ( talk) 03:48, 13 February 2013 (UTC) reply

• I always used to think we needed this, but Arbcom doesn't seem to have any trouble desysopping admins, do they? 2620:0:1000:3304:853F:37E3:1D7B:2DB2 ( talk) 15:53, 13 February 2013 (UTC) reply

  I'm in some ways less concerned about whether we need another process for desysopping than I am about whether the community believes we need another process for desysopping, and what problems may stem from that perception.  :) -- j⚛e decker ^talk 04:46, 15 February 2013 (UTC) reply

Wikipedia-en orderly mass Rfa elections for four year terms, and complete admin re-boot

Admin apprenticeships

The idea is that a limited number of short term ( on the order of months ) administrative apprenticeships be made available under a mentor. This would allow admin hopefuls to have a little experience under their belt when facing an RfA. Instead of wondering what a candidate might do or worry about experience, the !voters will how they would act as an administrator. The apprentice would have a set of admin rights, but their actions would be closely watched and guided by a mentor. Once the term of an apprentice graduates or completes their term they are automatically set back to a normal editor, and would still need to successfully complete an RfA to become an admin. During their apprenticeship they will also be required to provide a link to their mentor on their talk or user page. The mentor should have the ability at any time to end the mentorship for any reason, including issues not related to the apprentice not having enough time to mentor. The process to become an apprentice should be streamlined with the mentors themselves being a big part in deciding who they apprentice and being responsible for doing so. Note, that becoming an apprentice should not be a requirement to have a RfA, just a way to give a clearer picture. Even well qualified hopefuls that don't get apprenticeships themselves should be able to learn by watching the other apprenticeships and hopefully become better candidates themselves.

This idea is in someway similar to the "Probationary period for (at least some) new admins" above. But unlike probation this would happen before the full RfA and would be more tightly watched. Probation is more about making sure a candidate is good after the fact, this is designed to give hopefuls an opportunely before hand to prove themselves and to become ready to deal with what actually being a admin will be like.

Like some of the splitting, tier, and moderator solutions, this in effect creates another tier. But one with a strict limit on duration and without all the extra tiers and concerns about interactions between the different tiers. In this system, the mentor would be reasonable for dealing with their apprentice. And they would be responsible to the community as a whole to insure that they are keeping a good hand on any apprentice.

Support apprenticeships

1. As proposer. PaleAqua ( talk) 05:02, 13 February 2013 (UTC) reply
2. This in my opinion is a very good idea. While some admin actions are not logged, many are. Also, if an editor can prove he is not a menace with the tools, then I cannot really find a reason to oppose him becoming a permanent admin. Some details obviously need to be hammered out, but this can be done in the next stage in the unlikely event this gets there. Tazerdadog ( talk) 22:40, 20 February 2013 (UTC) reply

Oppose apprenticeships

1. Sorry, I have to oppose this one. Some of the admin rights (especially the ability to look at deleted articles) are both very sensitive and (as far as I'm aware) not visible in logs. Espresso Addict ( talk) 05:28, 13 February 2013 (UTC) reply
2. Added process complexity doesn't provide real, obvious benefits and not all Admin. tasks are logged so all sorts could be going on without our knowledge. Mentoring regimes already exist for those aspiring candidates who wish to latch onto a willing, experienced Admin. Leaky Caldron 14:43, 13 February 2013 (UTC) reply
3. Not happy. Who would these apprentices be, and who would select them to have a go at the wheel? And how? I could see another level of trial (Requests for Admin Apprenticeship) coming in with the same degree of POV, revenge, personal dislike based on a userbox, what someone said on IRC in 2007, and so on, that we have at RfA now. Peridon ( talk) 16:30, 17 February 2013 (UTC) reply
4. Too easily gameable. Any apprentice will be on their best behavior, and voters will not get an accurate view of what they'd be like as an admin. ‑Scottywong | verbalize _ 06:11, 19 February 2013 (UTC) reply
5. This involves a lot of work and extra responsibility on our existing admins who are getting scarcer, and for no great benefit. If RFA candidates lack experience as editors then they can do more editing. If they lack experience at admin related tasks they can take part in RFCs and AFDs, report vandals at AIV, rescue articles that merit rescuing and tag articles for deletion. If we were reluctant to appoint admins who didn't have experience as admins then this proposal would have some merit, but most successful candidates, and pretty much all the near unanimous candidates, have no adminship experience, either as admins on sister projects or from a previous stint as an admin themselves. If there were to be some great sea change at RFA, with lots of "oppose - do a stint as admin on Commons or Simple first" rationales then we might need to do this. But I'm really not seeing that happening. Ϣere SpielChequers 09:19, 20 February 2013 (UTC) reply

Discussion of apprenticeships

Unbundling - some U1 and G7s

Unbundling can work both to reduce the admin workload and to empower other editors. Successful unbundlings in the past include Rollback and Account creator, the common factors being that there was consensus to trust people with a simple part of the admin toolset even if you wouldn't trust them with the lot. Currently only admins can delete even the most uncontentious U1 and G7 requests, but with a few simple caveats most U1 and G7 deletions could be done by the editor requesting them. Allowing people to do their own uncontentious deletions would bring us more into line with other openly edited internet sites.

Last time I calculated this the gain was the equivalent of an averagely active admin a year - i.e. this would reduce the annual admin workload by the equivalent of the number of admin actions that the average admin has ever done. So not a huge impact on the RFA problem, but with only 28 admins appointed last year we do need to start thinking how we operate with fewer admins. It would also be empowering to editors. It would of course require MediaWiki changes, but as this fits with the stated objectives of the WMF I would hope that this would be forthcoming. If not we could have an admin bot do this, but that would lose the advantage of people feeling that they were empowered to delete things themselves.

All logged in editors would be able to delete pages if:

1. They were in their userspace and had not been moved there from somewhere else, or edited by someone else (ignoring bot edits and edits flagged as minor)(This does not allow you to delete anything in user talk or any other namespace).
2. Any page that the editor created and which is less than three months old, unless it has been moved or has been edited by another editor (ignoring bot edits and edits flagged as minor).

This would still leave some user requested deletions to be done by admins, but only the ones where judgement was required or something needed checking. It is an Asymmetrical unbundling in that if you delete something and change your mind you will need an admin to sort you out. But plenty of sites operate that way or more likely don't allow people to change their mind if they regret deleting something. The three months rule would avoid the scenario where someone leaves and wants to delete their contributions, which could include key templates, files and so forth - longstanding articles are likely to have multiple editors, files and templates less so. Ϣere SpielChequers 14:01, 14 February 2013 (UTC) reply

Additional caveat added in response to Peridon's concern. Ϣere SpielChequers 16:46, 17 February 2013 (UTC) reply

Support Unbundling - some U1 and G7s

1. As proposer Ϣere SpielChequers 14:01, 14 February 2013 (UTC) reply
2. Every little bit, I suppose.... Not sure how much work this is to implement, but no concerns that I can think of in theory. -- j⚛e decker ^talk 22:53, 14 February 2013 (UTC) reply
3. Yes, please. Seriously, there are so many things here that I can do by myself that end up taking a full day to do because I have to rely on others to do it. I haven't voiced this opinion before on my RFA's, but part of the reason I keep trying is because I seriously hate asking others to do something so incredibly simple that a new user could figure it out. On the Outreach Wiki, almost every trusted user is an administrator, and this allows for people to clean up after themselves whenever they make a mistake, so I see no reason that we shouldn't try something like that here. Kevin Rutherford ( talk) 01:27, 15 February 2013 (UTC) reply
4. Partial support. If this is technically feasible, then I support users deleting their own user pages. I'm not sure how the CC license works for pages in article space -- is it possible for an author essentially to withdraw his/her work? On other CC license projects I've been involved in, withdrawal of material has generally not been permitted. Espresso Addict ( talk) 01:41, 15 February 2013 (UTC) reply
5. Partial support. I support unbundling generally, though I think delete/view-deleted/undelete are tightly coupled. Everyone needs the ability to (for 90% of cases) revert their own mistake. I don't think we should be targeting unbundling to hit unobjectionable use cases unless those cases are also a pain point in terms of backlogs right now. However, any move toward unbundling is a positive step. Protonk ( talk) 23:42, 15 February 2013 (UTC) reply
6. Support. I'd prefer it if pages that have previously been undeleted were excluded (if the act of undeletion was counted as an edit by another user this would be automatic I guess) to prevent warring, but my support is not dependent on this. Thryduulf ( talk) 15:11, 18 February 2013 (UTC) reply
7. Support this proposal on its own merits, but I don't think anyone believes that this is a solution to the problems that plague RfA. ‑Scottywong | gossip _ 06:13, 19 February 2013 (UTC) reply
8. Support but it may be unnecessary: If it's technically feasible to determine what pages qualify for this "limited deletion," then it's also technically feasible to have a bot do it instead of a human admin. A bot would have the advantage that a user who thinks he made an "oops" could ask the bot to undo the most recent deletion providing the undo request is done in a timely manner. davidwr/( talk)/( contribs)/( e-mail) 03:54, 21 February 2013 (UTC) reply
9. Sounds reasonable.-- Staberinde ( talk) 17:34, 22 February 2013 (UTC) reply
10. Sensible proposal in principle but I'm not sure how workable it would be in practice. Among other things I expect that few users would be aware of that possibility (what would the interface look like?). Pichpich ( talk) 23:46, 25 February 2013 (UTC) reply
11. Support. At the very least,editors should be able to fix their own mistakes of this type. Rwenonah ( talk) 20:55, 26 February 2013 (UTC) reply
12. Strong support, although it would require a fix in the software. A bot could also be designed to handle these (keeping track of Category:Candidates for speedy deletion by user) until such a feature is implemented. עוד מישהו Od Mishehu 21:45, 26 February 2013 (UTC) reply
13. Support if feasible. Stifle ( talk) 13:01, 27 February 2013 (UTC) reply

Oppose Unbundling - some U1 and G7s

Discuss Unbundling - some U1 and G7s

• Is this technically feasible? Espresso Addict ( talk) 22:39, 14 February 2013 (UTC) reply

  Yes I believe so. If we can't get MediaWiki changes we could achieve some of the functionality by an admin bot - though in that case people would still have to tag articles as today. Ϣere SpielChequers 00:01, 15 February 2013 (UTC) reply

An admin bot might be easier to implement. Espresso Addict ( talk) 00:26, 15 February 2013 (UTC) reply

From what tiny bits of bot coding I've done, I believe that this is straightforward, if not exactly trivial, to do as a bot. -- j⚛e decker ^talk 01:50, 15 February 2013 (UTC) reply

Thanks Joe. I'd prefer to do this by unbundling as I'd like to actually empower all editors to do this, and as its a common requirement a change to Media wiki would give us benefits on all projects. But if we can't do that an admin bot would give us the benefit of freeing up the time of an admin, though of course an admin bot requires a bot writer who is also an admin and will only run whilst they are still here. Ϣere SpielChequers 01:13, 17 February 2013 (UTC) reply

Absolutely. -- j⚛e decker ^talk 15:22, 17 February 2013 (UTC) reply

• Espresso points out that this raises the issue of withdrawing cc licensed information, this is a fair point, once you've saved an edit you have released that info under an open license and you can't demand for it to be withdrawn. But equally we have no obligation to host it and we are free to delete it. So on this site we have long allowed people under certain circumstances to change their minds and have their contributions deleted per G7 and U1. In my proposal I'm not trying to broaden either U1 or G7, but to define a subset of them that would be uncontentiously deleted at present, happy to refine that if we can identify other uncontentious groups of U1s & G7s, or indeed restrict this further if this would be overkill. Ϣere SpielChequers 01:13, 17 February 2013 (UTC) reply

I don't work on speedies at all, so might well be wrong, but it seems to me allowing people to self-delete in article space is a significant extension to G7, which doesn't, as far as I can tell, oblige an admin to delete the article. The deleting admin is responsible for deciding whether or not Wikipedia hosts the content. Under your suggestion, the article creator will be responsible, essentially withdrawing his/her consent for the article's content. It's a small distinction, but I think a significant one. Espresso Addict ( talk) 01:44, 17 February 2013 (UTC) reply

It is well established that if you are the sole author and the article is recent then you can have the article deleted. You can do this by tagging it G7, or {{ db-author}} or most frequently by just blanking it. Usually when this happens it is within hours or days of the article being created, and the only time when we'd cavil about this would be if an article had existed for a long time and was widely linked to/read. The chance of an important mainspace article only having one editor who isn't a bot and hasn't marked their edit as minor is very small, but we could decline G7s and I think we would if it was a longstanding editor going off in a huff. However the vast majority of the G7s are done very soon after they are created. Arguably any article that matters will have at least two editors doing a non-minor edit at some point in its history, but if you'd be more comfortable feel free to change this proposal from 3 months to thirty days. Ϣere SpielChequers 15:05, 17 February 2013 (UTC) reply

• So long as user talk pages are excluded, I'm happy enough with user space self deletion - but does it include things more than one editor have worked on? I've a case in point - I had an incomplete draft sitting there because I couldn't find good refs. Someone else finished it off. Two queries: how does the present policy deal with that situation (not that I've met a deletion request in a similar circumstance), and how will the new version apply to that? I could see 90% of the work being done by an outsider (by agreement as my case was) and then following a falling out, the user whose space it is decides to delete. (Why can't I think up loopholes in the tax system?) Now for G7 - does tagging for CSD etc or maintenance count as editing for these purposes? Or adding categories or copy editing? Peridon ( talk) 16:22, 17 February 2013 (UTC) reply
  • Hi Peridon, good point, I've tweaked it. Now under this proposal if your collaborator is a bot or marks their edits to the page as minor then they will be ignored in deciding whether to auto delete the page. But if your collaborator is not a bot and does any edit which they don't flag as minor then an admin would need to make the decision. There are various edits that I would ignore when looking at a U1 or G7 request, but I've tried to keep this proposal for just the simplest and least contentious user requests. Ϣere SpielChequers 16:36, 17 February 2013 (UTC) reply

How about the tagging issue for the G7s? Do they count as minor? I see a lot of G7s that are blanking following a CSD tag. They're almost always new editors, and most of them won't know about this. Personally, I don't find G7 and U1 a bother. They only involve a quick scan down the history, then in over 90% of them deleting. Some I decline - too many editors or the old IP problem. Was that IP the author or not? Sometimes you can tell, but others an account starts and two IPs carry on until the author decides it's not working. When there's an alternative choice of criterion, well and good. But what will the software do in those cases? I guess, not allow the deletion. Will it be able to explain, or will it tag it for admin attention? Peridon ( talk) 20:20, 17 February 2013 (UTC) reply

Tagging for deletion is not supposed to be a minor edit, but if we wind up using a bot rather than unbundling delete then it would be illogical to not delete an article because the editor had blanked it and someone else tagged it G7. As for all the ones where you have to make a call about various other edits, they would still be admin calls unless the other editors were bots or had hit the minor flag. Ϣere SpielChequers 22:09, 17 February 2013 (UTC) reply

• If there are links to the page, then there will be red links somewhere. If there are template transclusions, then the result could be even worse. Should pages be excluded from this unbundling if there are entries in Special:WhatLinksHere? If you delete a page, should you also be able to view the revisions or undelete them? This could maybe be an issue if a different user previously has redacted information from the page. -- Stefan2 ( talk) 17:37, 17 February 2013 (UTC) reply
  • I wouldn't exclude pages simply because it would create redlinks, after all many of those links would have been redlinks before it was created. But only allowing very recent pages to be deleted per G7 without an admin would leave the tricky ones for an admin to consider and should avoid situations where a template becomes important and then the author wants it deleted. As for viewing stuff that you've deleted, I'd suggest not. Sites like Facebook don't let you undelete stuff that you've deleted, we'd still have the option for you to find an admin if you made a mistake or left and came back and wanted stuff restored. Ϣere SpielChequers 22:09, 17 February 2013 (UTC) reply
• Hey all, so I was asked to come over here and assess the technical viability of implementing such a feature in MediaWiki itself (as opposed to the admin bot solution), and I can say for sure that the entire plan is definitely possible, although parts of it would be more difficult than others. Implementing an ability to delete pages only you have edited within a certain amount of time is practically trivial. The only truly difficult part would be ignoring bot edits, since such information isn't stored along with the edit itself. — Parent5446 ☯ ^{( msg email)} 14:25, 22 February 2013 (UTC) reply

Unbundling - limited block/unblock

Rationale

The biggest change to RFA in the last few years was the unbundling of Rollback in early 2008 ( April 08-March 09 we had 144 new admins, barely a third as many as in the previous 12 months. It has continued to decline since, but rather more gently.). After that point it ceased to be possible to get adminship simply for being a good vandalfighter, and subsequently candidates have almost always had to demonstrate some contribution to building the pedia, not just a record of defending it. Subsequently we've had a steady change amongst our Hugglers. In 2008 the most active Hugglers were mostly admins; By 2010 neither our second nor our third most active vandalfighters were admins.

But we still need admins to block vandals, blocking vandals accounts for roughly a tenth of all admin actions, and whilst most admin actions can wait for hours, days sometimes weeks, once a vandal has got to the point where they merit a block it is timewasting and demotivating for the vandalfighters that they can't stop someone on a vandalism spree until an Admin steps in. In consequence, WP:AIV has to have admins active 24 hours a day 7 days a week. So if we continue on our current path of fewer and fewer new admins, AIV is likely to be the first place where this reaches the point where the pedia can't properly function.

We can prevent this by unbundling a limited amount of the block/unblock function. The contentious blocks and unblocks, those of whole ranges of IPs and those of accounts with more than a handful of edits would still need to be done by admins. But unbundling block/unblock of individual IPs and accounts with fewer than 100 edits would enable experienced Rollbackers and others with a record of successful AIV reports to be given a tool that they demonstrably know how to use, need to have and in many case can't get without doing something very different.

Proposal

Create a limited block/unblock userright that only worked on individual IPs and accounts with fewer than 100 edits, the right to be awarded by admins based on accurate AIV reporting, and revocable in a similar way to Rollback.

Caveats

We could also allow these editors to block promotional or otherwise unsuitable names, but those would be the only blocks that such editors were allowed to make. Editwarring, sockpuppetry, incivility, and so forth would continue to require admin judgements (editwarring would be an admin only decision because otherwise you could get a newbie editwarring with a vested contributor and only a full admin could block both). Ϣere SpielChequers 12:56, 20 February 2013 (UTC) reply

Support Unbundling - limited block/unblock

1. As proposer Ϣere SpielChequers 12:56, 20 February 2013 (UTC) reply
2. Support in any case, but I would like to see this as a stopgap. I would like a maximum duration imposed by this userright on the order of 3-6 hours, with admin confirmation needed to enforce a longer block. The idea here seems to be to stop the vandalism first, and then let the admins hammer it out at their leisure. Tazerdadog ( talk) 22:45, 20 February 2013 (UTC) reply
3. Support. It probably wouldn't make a difference in many cases, but I might apply the 100 edit restriction to IPs, too, there are a couple of productive, large-edit count IP editors. I'd support either way. -- j⚛e decker ^talk 04:10, 21 February 2013 (UTC) reply
4. You read my mind! I just read your comment under my "unbundling" proposal above and thought of the exact same thing. This would require some MediaWiki coding and I think it is fair to say the WMF tech team would not indulge our request, but the great thing about open-source is that anyone can contribute their code It doesn't have to be official WMF code to make it into MediaWiki.

   As for maximum duration, yes, I think a max duration of 31 hours on IPs and perhaps a month on fresh accounts (not sure about this) would be good. But we can nut this out in round 3. — This, that and the other (talk) 09:07, 21 February 2013 (UTC) reply

5. Support. I agree that it's important to set basic rules like only IPs or only recently created accouts or only for a maximum 3 hours and others of this kind. However, I don't think we should overly worry about people going rogue and blocking a gazillion accounts in two minutes, I think we should worry about people being stupid and testing the limits. So instead of complicated changes in MediaWiki, we could have a bot that simply periodically checks the logs of people with this userright: you screw up once, you lose the userright. It would even be possible to check more subtle things such as whether the user was warned. Pichpich ( talk) 23:57, 25 February 2013 (UTC) reply
6. Support. I think that adminshipis gradually being made into more of a big deal. By unbundling some of the tasks, we can help users find their way into adminship better - as well as making more admin-hours available on Wikipedia, since some of the admin tasks willbe handled by "semi-admins". עוד מישהו Od Mishehu 21:48, 26 February 2013 (UTC) reply
7. Certainly has the potential to help things. This might potentially have the side effect of making it harder for people with good AIV reporting records to pass normal RfA though. Hut 8.5 23:12, 1 March 2013 (UTC) reply

Oppose Unbundling - limited block/unblock

1. Strong oppose. Would inevitably lead to some unfair blocks, massive drama, demands for blood (both blocker's and admin's who gave him the rights) etc. etc.-- Staberinde ( talk) 17:40, 22 February 2013 (UTC) reply
2. Block log is such a sensitive item for any editor. I am afraid that this tool could not be used carefully enough. Malinaccier ( talk) 05:33, 2 March 2013 (UTC) reply

Discuss Unbundling - limited block/unblock

Maximum duration

There have been a couple of suggestions about limiting the maximum duration of blocks. I'd prefer to leave this proposal as is, both because it would be simpler and because it avoids a lot of unnecessary rework by admins. My thinking is that there are a bunch of hugglers out there who have hundreds, in some cases over a thousand AIV reports. These are editors who we can trust to decide whether a new account is a vandalism only account and merits an indefinite block. If we only allow them to block that account briefly and then require a full admin to confirm that we get little benefit over our current situation, and we complicate a lot of block logs. Not a lot of vandals get reformed into editors and I wouldn't put huge efforts into trying to reform them, but I can see it would be confusing for them if a short term block by one editor was converted into a permanent block hours or days later despite them doing no further edits in between. Ϣere SpielChequers 18:44, 21 February 2013 (UTC) reply

I lean to your view here. Limited blocks and reblocking will lead to more work, rather than more distributed work. -- j⚛e decker ^talk 01:23, 22 February 2013 (UTC) reply

IP editors with over 100 edits

Yes we do have some wonderful IP editors who have over 100 edits on their IP address, and I'm sure we have some with thousands of edits across a succession of IP addresses. But we also have a whole load of school IP addresses that keep earning themselves blocks for vandalism, and some of them have many hundreds of edits, good, bad and indifferent. Whilst I'm a very occasional IP editor myself and a strong defender of the rights of IPs to edit, this is one area where I think it reasonable to differentiate between those who create an account and those who don't. If you want to build a reputation on wiki and earn the trust of your fellow editors then create an account. If you edit without creating an account then we cannot know if the other edits done from your IP address were done by you or someone else, but if we have a succession of vandalisms coming from your IP address then it is reasonable and normal for us to briefly block that IP address. Sometimes that will happen just as the vandal stands up and goes off to do something else and by coincidence another person tries to edit from that IP only to discover it to be blocked. Until we start recruiting psychic editors who can tailor the length of their IP blocks to the time the vandal will still be trying to vandalise, we need to live with a situation where some IP addresses occasionally are used for vandalism sprees on Wikipedia, and in some circumstances such IPs need to be blocked. Ϣere SpielChequers 18:44, 21 February 2013 (UTC) reply

Ahhh, the school blocks. I take your point. -- j⚛e decker ^talk 01:24, 22 February 2013 (UTC) reply

Question about the unblocking ability

Would the unblock function only be limited to self unblocks or would it include any account that the permission could have blocked? Crazynas ^t 01:17, 22 February 2013 (UTC) reply

By self unblock I assume you mean that they could of course reverse any mistakes they make by unblocking anyone they had blocked. As the only people with this right would be people with quite a large record of successful AIV reports their own accounts would usually have over 100 edits, so they couldn't block or unblock themselves. Otherwise under my proposal as currently worded they would be able to unblock any individual IP address and also any registered account that had under 100 edits. My rationale for this was that these are not where the contentious unblocks are, so I see no problem in allowing these people to decide some unblock requests from such accounts. Of course if the block reason was creating multiple attack pages and the unblock request was disputing that then they'd have to leave that to a full admin who could look at the deleted articles in question. Ϣere SpielChequers 09:47, 22 February 2013 (UTC) reply

Thank you for your reply, you got to exactly what I was saying, sorry for the lack of clarity. You say above that blocking of sockpuppets is not one of the allowed criteria under this permission as is incivility. My concern is that if you give the ability to someone without the community consensus to use it in any way they see fit (subject to broader WP policy) there will be drama. I can imagine some experienced SPI editors with this right who would use it to block accounts that everyone agrees are sockpuppets and, under the current proposal losing their access because their action is outside the consensus of what can be done with this tool. Regards. Crazynas ^t 00:43, 26 February 2013 (UTC) reply

Some standards at RfA are uneven and unknowable.

Agree a criteria for adminship

In most real world exams or interviews the examiners or interviewers would try to agree a set of objective criteria for evaluating candidates, and much of the interview or exam would focus on whether or not they meet that standard. A substantial proportion of the discussion in many RFAs is not about whether a candidate meets an agreed particular standard but about what standard the RFA candidates should be expected to meet.

Agreeing a set of RFA criteria would reduce the capriciousness of the current system, hopefully persuade many more well qualified candidates to run and possibly even persuade some poorly qualified candidates to postpone. It might also challenge the process of standards inflation.

Once we agree to set a criteria we have the equally difficult task of agreeing that criteria. One possibility would be:

1. A clean block log, 3,000 manual edits and at least 12 different months in which they've been active.
2. At least 12 different months in which they've been active and 3,000 manual edits since the latest block.
3. Demonstrated ability to add reliably sourced content to articles.
4. If active in deletion, a record of deletion tagging and AFD votes within policy
5. If this isn't their first RFA, at least three months activity since their last RFA.

There would of course be some things outside that criteria, and occasions where a nominator was making a case for the community to set aside the criteria. But having a set of criteria for things where we do have consensus should focus the debate onto the candidate's contributions and thereby improve both the tone at RFA and its ability to make the right choices.

Support for Agree a Criteria

1. As proposer Ϣere SpielChequers 10:26, 6 February 2013 (UTC) reply
2. Yes please. Not this particular set of prerequisites - I was thinking something lower, like "1,000 edits (including edits to each of article, article talk, WP/WP talk, and user talk namespaces) and 6 months of activity". I think it also has to be objective (the bit about deletion history can be discussed in the RFA itself). Three months between RFAs does seem like a good move, though. It's for the user's own good to wait it out. — This, that and the other (talk) 11:00, 7 February 2013 (UTC) reply

   If you go much lower then you might get my support, but in my experience you won't get consensus support. Edit count isn't a very good metric, but I'm pretty sure only one of the last 100 admins had fewer than 3,000 edits at the time of their RFA. As for tenure, it has been years since anyone passed RFA within 12 months of starting editing. Ϣere SpielChequers 17:38, 8 February 2013 (UTC) reply

   I think you might be right: these criteria need teeth to be of any use. It is possible that the criteria could end up excluding the occasional candidate who might actually pass RFA, but I don't think that will do any harm: they can just come back to RFA later once they meet the criteria! — This, that and the other (talk) 00:23, 9 February 2013 (UTC) reply

3. Yes, if these criteria are flexible. They should be general guidelines, not precise numbers. If someone's only been around for 11 months, but fulfills everything else, they should still be qualified, for example. But we need some standard criteria. -- Ypnypn ( talk) 15:54, 7 February 2013 (UTC) reply
4. I don't think the above criteria are suitable, but the idea is sound and it works well in other areas of the project. At AfD, for instance, editors judge articles against fixed inclusion criteria, and arguments which don't relate to those criteria are routinely discounted. Applying the idea to RfA would lead to a reduction in dodgy rationales as bureaucrats would feel more confident in discounting them. Hut 8.5 20:53, 7 February 2013 (UTC) reply
5. Setting the details aside, I support the general principle enough that I'd like to see it explored further. As long as there is plenty of room for discussion, on the merits, of exceptions/IAR for particular candidates (anyone should be able to support or oppose a candidate for whatever good-faith reasons they wish, although not all comments deserve equal weight in the close), I think something along these lines would cut down on failed RfAs, and reassure good candidates that they should not fear the process. -- Tryptofish ( talk) 23:40, 7 February 2013 (UTC) reply
6. The details could be tweaked; and of course there should be a process to handle exceptions, but generally this is a good idea. -- Noleander ( talk) 01:20, 8 February 2013 (UTC) reply
7. Obviously TheOriginalSoni ( talk) 03:37, 8 February 2013 (UTC) reply
8. Of course I wouldn't support a tick the box and you get the admin flag system, but getting a community consensus on what are the minimum standards for RFA are is a good thing in my opinion. It could also be used to demonstrate that one particular voter in an RFA is against community consensus. James086 ^Talk 17:56, 8 February 2013 (UTC) reply
9. If used as flexible guidelines or minimum standards, yes. dci | TALK 21:01, 8 February 2013 (UTC) reply
10. I support, without particular bias or preference on the specific criteria mentioned. But on the concept as a whole, there should be a more objective, defined criteria that should be the baseline for evaluation, much like how we have criteria for BLP notability, or CORP or MUSIC. It is not that these guidelines are the end-all-say-all, but they fit 90% of the time, with room for exceptions. Tiggerjay ( talk) 08:07, 13 February 2013 (UTC) reply
11. I'm really not a supporter of the current "criteria," but it is clear that the current criteria is out of date (I could make 1,000 edits in a day, but does that mean I am more experienced than the next guy?), so if anything we should be more clear on what's out there. Kevin Rutherford ( talk) 01:30, 15 February 2013 (UTC) reply
12. I prefer the idea of a set minimum criteria. If theoretically the criteria is minimum 3000 article edits, and someone is at 2500, no harm would actually come from having that person perform more edits in order to reach the threshold. RfA isn't exactly about the edit count, it is the behavior during those edits. And as most people on WP can attest, your attitudes towards various policies and guidelines change as you edit and interact more often. Also, since various voters have different criteria in their heads, it would be good to standardize them all so potential admins don't waste their time at RfA because they didn't know the unwritten rules. Angryapathy ( talk) 19:51, 21 February 2013 (UTC) reply
13. Not necessarily these exact criteria, but something along these lines should be discussed seriously. The de facto requirements for time and edit count have risen dramatically over the years. When I passed RFA I had about four months and 3000 edits on this account, a record like that would be met with WP:NOTNOW galore, and that is not a good thing. Letting voters arbitrarily pick their own criteria of "time needed", and "edits needed" and then making oppose votes based on them make the RFA process less predictable and is discouraging candidates that in reality have more than enough experience to understand what Wikipedia is about and what role an admin has. And since each oppose cancels out about three support votes, it is the most demanding criteria which end up controlling and setting a new standard. The criteria don't need to be absolutely rigid, but they shouldn't be left entirely up to the whims of individual voters as they are today. Sjakkalle (Check!) 20:23, 27 February 2013 (UTC) reply

Oppose for Agree a Criteria

1. This will just add a number meaningless and arbitrary bureaucratic impediments on the path to adminship. I am actually aware of at least a few current administrators who do not have a "clean block log". Ruslik_ Zero 18:58, 6 February 2013 (UTC) reply

   Are you opposed to the idea of prerequisites in general, or just to these specific suggestions? General prerequisites, quite apart from being "meaningless", provide a clearer picture of what it means to be an admin. They would, at the very least, get rid of some of the NOTNOW RFAs. — This, that and the other (talk) 11:00, 7 February 2013 (UTC) reply

   This doesn't require a clean block log, just 12 months and 3,000 edits since their last block. I'm certainly aware of admins who've passed RFA with older blocks that the community is prepared to ignore, or who've been accidentally blocked and treated as having a clean block log. But I can't remember the last time someone went through despite a valid recent block. Ϣere SpielChequers 17:45, 8 February 2013 (UTC) reply

2. No. There should not be hard prerequisites. You mention job interviews. I have seen organizations that use inflexible hiring criteria pass over smart, useful applicants in favor of some clueless brownnoser who just made sure the ticked all the right boxes. It's not a good way to do business. Beeblebrox ( talk) 19:33, 6 February 2013 (UTC) reply
3. I'm not convinced that this is a solution to a real problem. It would only make it slightly easier to speedy close misguided RfA's. They are already closed fairly quickly in most cases, so I don't think this is a problem. ‑Scottywong | chatter _ 19:01, 7 February 2013 (UTC) reply
4. The problem with coming up with criteria is that the discussions going through will ignore the criteria. Res Mar 22:51, 7 February 2013 (UTC) reply
5. I don't think there is any community consensus on standards, and imposing one that isn't widely supported is likely to reduce further trust in the admin pool. Espresso Addict ( talk) 17:53, 8 February 2013 (UTC) reply
6. A prospective candidate needs a demonstrable amount of experience, which in some respects can be quantified, but they also need to be both competent and trustworthy, and no amount of 'measurement' can demonstrate these. There are very experienced editors who have made a lot of good contributions that I wouldn't trust with the admin tools. As I indicated in the first round, I think the only thing that may be useful in this area is agreeing a minimum level of experience, lack of blocks, etc., that would qualify an editor to stand for adminship in the first place - for anyone below a certain level of experience (time and edits) there simply isn't enough data on which to judge their suitability. -- Michig ( talk) 18:17, 8 February 2013 (UTC) reply
7. There are already de facto standards, just with a bit of variance between !voters, and I don't think that's a bad thing Jebus989 ^✰ 20:07, 8 February 2013 (UTC) reply
8. Solves a non-existent problem. Premature RfA are readily dealt with by existing custom and practice and formalising a specific (and IMO inappropriately low) threshold simply creates an unnecessary level of scrutiny when a simple WP:NOTNOW will suffice. Does nothing to resolve the perceived problems with the RfA process. It also creates a problem - in the mind of some of our less mature candidates it will set a notional target to aim at. Sometimes a quick slapdown by the community at a premature RfA is precisely what a future decent candidate needs, not a target to aim at. Leaky Caldron 11:31, 9 February 2013 (UTC) reply
9. What Leaky says. -- regentspark ( comment) 14:27, 10 February 2013 (UTC) reply
10. Per Leaky. I agree with every word. Jus da fax 22:43, 11 February 2013 (UTC) reply
11. Per Leaky. Sorry. Protonk ( talk) 23:43, 15 February 2013 (UTC) reply
12. Per Scottywong and Leaky. Stifle ( talk) 13:02, 27 February 2013 (UTC) reply
13. RFA is largely about trust; there can't possibly be a fixed set of criteria for determining who can be trusted. This depends on which tasks the specific candidate would be likely to do; on details of the candidates past; and on various subjective criteria. עוד מישהו Od Mishehu 18:43, 2 March 2013 (UTC) reply

Discussion of Agree a Criteria

I don't oppose the idea of setting up some criteria, but I strongly oppose any proposal which includes edit counting. Edit counting is subjective, and can easily be gamed, especially in this era of automated editing. (And as we've seen in some situations at AN/I, it can be difficult to discern automated edits from manual edits.)

I also don't like this focus on the block log. Want to prevent an editing adversary from running for adminship? Get an admin to block them. For example (sorry for the WP:BEANS): stalk their edits, engage in numerous edit wars with them, and get both of you blocked, etc. And yes, for those who haven't seen it, such nonsense goes on.

Criteria I'd like to see is quality over quantity. Has the editor participated in consensual discussion? Did they do more than just drop a drive-by vote, but actually engage in discussion? etc. The ability to substantively, positively, constructively interact with others should be of paramount importance. See also: User:Jc37/RfA/Criteria - jc37 21:02, 6 February 2013 (UTC) reply

I don't think I could agree more. Not to lob flattery around, but RfA would be significantly better if more editors' criteria looked like jc37's. It sure would be nice if people stopped arguing about if 4000 edits are enough or whether 6000 should be required, but the whole point of RfA is that it's about how well you understand policy, how well you can read consensus, and how well you can interact with other editors (among other things). RfA would, in fact, be extremely simple if it was just about edit count, or Wiki age, or many of the other things that lead people to vote "He's a good editor but...." Unfortunately, basing adminship on numbers won't lead to good admins, and excluding candidates based on statistics will only rule out potentially good admins. — Rutebega ( talk) 02:30, 7 February 2013 (UTC) reply

It makes a lot more sense to create something like this as an essay than a policy. Tell people that "You won't pass an RfA with less than ~3000 manual edits" rather than strictly forbid it. I think such an approach could address what people advocating this want addressed without being overly bureaucratic or contentious (especially because we could simply tally up the edit count of successful/unsuccessful RfAs and say "No one with less than 4500 edits has passed an RfA" rather than "You should have 4500 edits" which is slightly more contentious. Wily D 08:40, 7 February 2013 (UTC) reply

There should be some minimum prerequisites. After an editor has met the pre-defined criteria, a general process of selection should follow it; whereby promotion should be on case to case basis. Harsh (talk) 13:50, 14 February 2013 (UTC) reply

Commissioners

There's a real-world model that works well for this. We would have real problems if the public directly elected police officers and/or judges. What works in real-world societies is when the electorate votes for commissioners whose role it is to appoint and supervise the police. I propose that we implement this workable real-world solution by creating an elected body of commissioners, and it is these commissioners who are responsible for appointing, supervising, and supporting our admin corps.

The commissioners would be elected by Wikipedians using a process similar to RFA. They would have the userrights of a bureaucrat including the technical ability to desysop, and a specific mandate to recruit, support, coach, and if necessary, discipline, those who use sysop tools.

• (Later) I've noticed that the opposition to this proposal comes, largely, from those who're already admins and object what they call the "bureaucracy" of a body empowered to monitor and supervise their use of their powers. Surely this is the heart of the problem. RFA participants are reluctant to promote because a bad sysop is practically un-removable, and surely the answer to that is put in place an elected body that can desysop without the endless process of Arbcom. Such a body is essential to making adminship "no big deal". But our existing admin corps is reluctant to be supervised. How to resolve this?— S Marshall T/ C 08:51, 12 February 2013 (UTC) reply

Support Commissioners

1. As proposer — S Marshall T/ C 11:17, 6 February 2013 (UTC) reply
2. Providing we the community got to decide the criteria that the candidates were to be measured against then I could live with this. It isn't an ideal solution but if this works with Rollback and AutoPatroller it should be possible to make it work. Ϣere SpielChequers 17:36, 6 February 2013 (UTC) reply
3. This could work provided that (1) the commissioners were well-selected (similar to ArbCom ... maybe even Arbcom); and (2) all editors could provide input to the commissioners during the process. I don't like the idea of yet another committee, but it could cut-down on the drama at RfA; and could be efficient if it were just the ArbCom. -- Noleander ( talk) 01:24, 8 February 2013 (UTC) reply
4. We already have such commissioners - the bureaucrats. RfA is just a form of consultation and there is no formal power in it. If the bureaucrats wish to ignore !votes for or against a particular candidate or to consult amongst themselves then they are free to do so. Insofar as they follow the overall mood of the consultation, then this is our general method of making decisions by consensus. If the bureaucrats felt that there was some pressing problem requiring the draft of a large intake of admins then they would be free to act accordingly and who could gainsay them?
5. Why not? Kevin Rutherford ( talk) 01:31, 15 February 2013 (UTC) reply

Oppose Commissioners

1. Completely and utterly opposed to any additional bureaucratic layer that removes at a stroke the ability of any individual editor to directly express a view on the suitability for Admin. of any candidate. A cabal of "commissioners" is the last thing we need. Admin. should be about "selection" not "election". Leaky Caldron 12:29, 6 February 2013 (UTC) reply
2. Your premise is faulty. In much of the United States, if not the rest of the world, the public does directly elect police officers (sheriffs) and/or judges. Even if it weren't, as per Leaky, I'm against making becoming an admin have any additional complexity (an additional layer of people just to select admins?). I'm an old timer, and both remember and support when it was WP:NOBIGDEAL. -- GRuban ( talk) 15:17, 6 February 2013 (UTC) reply
3. We don't need another layer of bureaucracy, especially one that appears to be for life. Might consider supporting if there were term limits on such a body, but even that would be a very weak support. Intothat darkness 18:35, 6 February 2013 (UTC) reply
4. This project is not a "in real-world society". Ruslik_ Zero 19:00, 6 February 2013 (UTC) reply
5. Wow, i came here hoping to find some ideas I could get behind and so far I hate everything I've seen, including this. RFA should not be put in the hands of a select group of uber-admins. Beeblebrox ( talk) 19:35, 6 February 2013 (UTC) reply
6. Just to make my thought clear: No to star chambers, smoke-filled rooms, or representative government. Wikipedia is a committee of the whole, and I do not want to see that abridged or otherwise modified. - jc37 21:08, 6 February 2013 (UTC) reply
7. Jc37 says it best above. No additional clerks, commissioners, committees required Jebus989 ^✰ 08:56, 7 February 2013 (UTC) reply
8. This kind of cabalism would be a disaster. Any reforms need to move towards making it easier for people who've been writing an encyclopaedia, have a good track record, but just have not making friends to become admins, not let those who know people scoot in without public scrutiny. Wily D 10:40, 7 February 2013 (UTC) reply
9. Commissioners already exist at WP:ARBCOM. ‑Scottywong | confess _ 19:03, 7 February 2013 (UTC) reply
10. This would add another level of complexity to the process and add unnecessary bureaucracy. It would also tend to divorce admins from the community and deny them a mandate from the community; without a clear community mandate, admin decisions could appear to have less legitimacy, and that could diminish the role. It's much better to just say "adminship is no big deal" and have the community grant it more liberally. Everyking ( talk) 19:10, 7 February 2013 (UTC) reply
11. Divorcing admin appointees from the necessity of gaining community trust seems like a recipe for disaster. Espresso Addict ( talk) 17:39, 8 February 2013 (UTC) reply
12. I don't see this being useful. -- Michig ( talk) 18:19, 8 February 2013 (UTC) reply
13. Poor idea per reasons stated above.-- Staberinde ( talk) 10:56, 10 February 2013 (UTC) reply
14. Definitely not. Our community consensus based method of selecting admins and bureaucrats is perhaps our most powerful management tool. The community wide scrutiny that candidates get not only widens the pool of candidates (for example, I haven't come across any of the current RfA candidates before) but it also forces the candidate to think about what it means to be an admin. Don't fix this one. -- regentspark ( comment) 14:32, 10 February 2013 (UTC) reply
15. This does not seem to be the best method to accomplish the goals presented. I believe that an easier, objective recall process would satisfy many of the community's concerns. Tiggerjay ( talk) 08:09, 13 February 2013 (UTC) reply
16. Wikipedia is not a bureaucracy. Stifle ( talk) 13:02, 27 February 2013 (UTC) reply

Better questions needed: Uneven Standards start at the beginning of RfA

The existing RfA process can be influenced from the start by an influx of early popularity based supports or prejudice based opposes. This start can influence the running of the RfA as well as the outcome. This proposal offers a more even start to the RfA and will enable the subsequent discussion to look more like a selection based on suitability rather than election based on popularity.

Proposal. (1). Replace or supplement the existing 3 standard questions with 8 - 10 (or fewer) questions representing the most usual candidate FAQ topics. (2). Before any !votes (other than nominators) can be cast the candidate must answer these standard questions. The idea is that in order to select a successful Admin. for life there should be a solid basis of material available to all !voters. Answering an enhanced set of standard questions should prevent some of the spontaneous supports and opposes which are frequently groundless. No other changes to the existing questioning process is proposed here. If this suggestion is accepted the standard questions can be determined in the next stage - no point debating here if there is no consensus for the proposal. Leaky Caldron 16:30, 10 February 2013 (UTC) reply

Support Better Questions

1. As proposer (get one on the board at least!) Leaky Caldron 09:55, 12 February 2013 (UTC) reply

Oppose Better Questions

1. Apart from the existing three the only really useful questions at RFA are the bespoke ones that are based on assessing the candidate's contributions. Other boilerplate questions are usually a distraction, and if any policy based question became standard it would soon lose what little value it now has. If we want to improve RFA we should be trying to steer !voters away from the question section and into spending more time actually assessing the candidate. This proposal would make RFA more of an open book exam and even less effective at assessing candidates for adminship. Ϣere SpielChequers 01:24, 11 February 2013 (UTC) reply
2. During my last run, I spent a good day constantly checking the page because I wasn't sure what else would pop up in the form of questions. Granted, I should be supporting this because it would have prevented a completely misguided and false question on my page, but I feel like making people take a mini-exam before they run would significantly lower our already dismal participation levels. Besides, if it removed the organic aspect of the run, then what would be the point? Kevin Rutherford ( talk) 01:35, 15 February 2013 (UTC) reply

   You have misunderstood the proposal. It is not intended that questions are answered before they run. It is suggested that a candidate should answer a better set of fixed questions before a swath of support or oppose votes are made before the candidate has had the chance to show what knowledge they have. As it clearly states, no other aspect of RfA would change, including what I suppose you mean by organic, i.e. additional/supplementary questions. Leaky Caldron 10:43, 15 February 2013 (UTC) reply

   Yeah, but weren't the 3 questions now optional at one point? And at least when I ran (which was like 4 years ago or something) the "optional" questions were rarely that unless they were self-evidently duplicates or asinine. Protonk ( talk) 23:46, 15 February 2013 (UTC) reply

Discussion of Better Questions

• I'm very much in favour of participants examining candidates more carefully. However, I can't help feeling that a wall of text in answer to 8–10 standard questions is likely to be simply ignored by those participants who don't already closely examine the candidate's work. Personally, I find answers to questions much less elucidating than just poking around the candidate's contributions & user/talk pages. Also, I doubt anything would put some questioners off asking their pet questions, thus adding to the mountain of questions, which I think must be off-putting to potential candidates. Espresso Addict ( talk) 22:49, 10 February 2013 (UTC) reply
  • In other words (correct me if you disagree), RfA contributors should ideally pay the most attention to how the candidate behaves on wikipedia in general, and focus less on questions in an RfA where the candidate knows everything they say will be under scrutiny, and could hypothetically equivocate and circumlocute accordingly. With that view in mind, standard questions aren't that useful, as the questions are really only necessary when asking a direct question. Hypotheticals and the "Can you interpret this policy (or better yet, behavioral guideline) correctly according to my subjective standards?" game are inferior to just scanning contributions, so the best questions are those such as "In your own words, explain what you believe to be an Administrator's role on Wikipedia," which give the community insight on the candidate they probably couldn't get from the contributions or a tool. Tl;dr, we should only ask that the candidate answer universally important questions upon his or her nomination, and I don't think there are many of those. — Rutebega ( talk) 03:14, 11 February 2013 (UTC) reply
    • I think a few questions are useful, if only to make sure that the candidate is capable of explaining him/herself in English. But responses to policy questions under the glare of RfA tend to be so PC it's hard to get a handle on where the candidate's real views lie and how they'd behave "in the wild". If I were of a mind to ask questions of candidates, I'd probably go with questions to which there's no answer that will please everyone, such as "Where would you place yourself on the inclusionist–deletionist spectrum?" Espresso Addict ( talk) 05:05, 11 February 2013 (UTC) reply
      • If you spot something dubious in someone's edits then a bespoke question can be very useful. Sometimes you get a good explanation or a dignified retraction, othertimes an RFA can turn on the results of such a question. I'd prefer to judge where people's actions are on the inclusionist/deletionist spectrum according to their recent edits. If you ask the question you get either their own opinion of where they are or worse their opinion of where the policy should be moved. Admins have no special say in the development of policy, so I have no problem supporting a candidate who would like to see the policy changed quite dramatically - provided they edit and would continue use the tools in accordance with consensus and policy. The other problem with asking questions where you know that there is no answer that will please everyone is that even a good candidate can be weakened by this, and some people will assume that you wouldn't be asking the candidate this particular question unless you knew that this particular candidate had a flaw in this area. Ϣere SpielChequers 08:47, 22 February 2013 (UTC) reply
• Personally, I miss Keepscases' at times seemingly surreal questions. I found them valuable in having a chance to see the candidate deal with something rather unexpected. A lot of the questions that come up now seem to be connected to someone or other's PoV on some issue rather than seeing how someone would deal with the actual work, and come up like fixed questions at almost every RfA. I'd rather see practical answers than ones designed to please the questioner, or things learned by rote. (I was running a map reading course once, and the young people on the course could all tell me the definition of a contour line, but not whether you were walking up or down hill if proceeding ALONG one. Pass a geography exam, yes. Be able to make use of the information, no.) Peridon ( talk) 10:26, 19 February 2013 (UTC) reply
  • I like having one or two surreal questions in an RFA, but I don't like Opposes objecting to people with various atheist Userboxes. If people don't like a Userbox take it to MFD, don't oppose people for displaying it. Alternatively, if someone has a userbox displaying a particular POV, have a look at their edits in that area, an oppose based on diffs showing recent POV editing would be pretty effective. But I'd hope that someone who checked and didn't find POV editing would then be inclined to support. Ϣere SpielChequers 08:47, 22 February 2013 (UTC) reply
• I'll tell you what. I'd support this if it came with a ban on additional user questions, as a good percentage of user questions are pointless chaff or traps. Stifle ( talk) 13:03, 27 February 2013 (UTC) reply

Some standards at RfA are too high.

"Not unless" candidates

Currently RFA has only two possible outcomes, pass or fail. A third and in my view very positive one would be "not unless". In this scenario the RFA would run much as it does today, but the closing crat would have the option of closing with a statement such as "Due to the mixup of the nominator picking up and responding from the candidate's PC, this RFA can only be closed as a success if a checkuser confirms that the candidate and their nominator are in fact different people." Or "Due to the concerns expressed at the candidate's AIV tagging this RFA can only be closed as a success if the candidate demonstrates an improvement in this area". This would give a crat the opportunity to promote such candidates if they had subsequently met the relevant condition(s), and the discretion not to do so if in the mean time they had also done something egregious. The candidate would still have the opportunity to submit a completely fresh RFA, and hopefully in areas where judgement is concerned the crat would consult with the relevant opposers before promoting such a candidate.

One of the advantages of this sort of close being possible is that it should concentrate attention in the oppose section on the things a candidate would need to do to be suitable for adminship, rather than how little they are trusted or known. It might also make those who oppose for spurious reasons such as a high percentage of automated edits think twice when they worked out the implications of such opposes and saw themselves writing "Oppose 80% automated edits is too high. Candidate needs to give up Huggle and Hotcat and do 60,000 more manual edits in addition to the 20,000 they've already done to bring their Automated edits down to an acceptable 50%".

I'm one of those who failed my first RFA, I remember as the opposes came in, and again when I reread it before my second RFA it was much easier to accept the "not yet" type of opposes than some of the others. I think it could transform the RFA process if we were to focus the opposition section on the things the candidate would need to do to become an admin.

Support for Not Unless

1. As Proposer Ϣere SpielChequers 10:41, 6 February 2013 (UTC) reply
2. Agreed, but I think "crat would consult with the relevant opposers" needs to be a rule not a "hopefully." -- YPN YPN ✡ 01:00, 10 February 2013 (UTC) reply

   OK I've changed the proposal to strike hopefully. Ϣere SpielChequers 01:38, 11 February 2013 (UTC) reply

3. Opposers at RfA should probably be a little more accountable for the reason for their opposition. If we look at RfA like it's a dispute where we want to build consensus (and where the ideal end result is a successful RfA and a shiny new admin), the opposers should still want the editor to be up to admin standards, and would therefore be in a good position to give advice and work towards the common goal of another admin. Of course, some people are just not suited to adminship, so the option of User:Example will never be suitable to be an admin because [insert reason here] should still be on the table, but it shouldn't be the default. Opposers should be forced to take the more positive angle of "what could this editor do to improve and get a Support from me next time?" (even if the answer is nothing), as opposed to just saying whatever they don't like about someone. — Rutebega ( talk) 03:31, 11 February 2013 (UTC) reply
4. Has the potential for improving the framing of the discussion, indeed. Added: In forming a reply to Tiggerjay, below, I found my support for this strengthening, as I started thinking about it in the context of accountability. The candidate is offering to help and go through a difficult process, the community as a whole should at least bear some responsibility and accountability for meaning what they say, and generally sticking by what they say, in their criticisms of a candidate. -- j⚛e decker ^talk 16:40, 13 February 2013 (UTC) reply
5. Agree with proposal and Rutebega's comment. And Joe's, now I look at it; the responsibility should work both ways. RFA's serious business for everyone involved. — This, that and the other (talk) 05:29, 15 February 2013 (UTC) reply
6. I like it, but I don't expect many RfA's would close this way, even if it were available. ‑Scottywong | express _ 06:18, 19 February 2013 (UTC) reply
7. I could go for this, although it could give the crats migraines... Stifle ( talk) 13:05, 27 February 2013 (UTC) reply
8. I think that a failed RFA should be closed with a statement which would help the candidate know what (s)he should do to pass the next try. Probably few of the failed RFAs are truly hopeless users. עוד מישהו Od Mishehu 20:06, 27 February 2013 (UTC) reply

Oppose for Not Unless

1. Doesn't this already happen? Typically, !voters in a second RfA look at the opposes in the first RfA and see what the candidate has done to fill the gaps. There may be multiple reasons why an RfA fails, do we want to give crats the authority to decide which ones are worth focusing on and which ones can be ignored?-- regentspark ( comment) 14:37, 10 February 2013 (UTC) reply

   Yes where there are constructive opposes the candidate's reaction to them usually makes a big difference in a second RFA. But this proposal is about empowering the crats to sometimes dispense with the second RFA and appoint someone as admin because they've met a key objection in the first RFA. For example if the first RFA failed because of lack of content contributions then if the candidate writes a GA the crats could appoint them as admin because they'd met the condition in their first RFA. Ϣere SpielChequers 01:32, 11 February 2013 (UTC) reply

2. This seems unnecessary. There is always the possibility to RfA again after addressing concerns. Tiggerjay ( talk) 08:11, 13 February 2013 (UTC) reply

   ...which is a lot more work for participants, and a lot more stress for the candidate. But what's more important here, I feel, is the change in tone. A really good, generally trusted candidate who needed, say, a bit of mentoring on CSD criteria might now be not promoted, then have no sense of how things would play out six months later--anything sooner than that would likely be seen as "jumping for the bit." Not happy making. With this proposal, the candidate might be able to get a "hey, go get some mentoring on CSDs from a couple experts and come back", and clear that hurdle in a month or three. And in doing so, they'd enjoy an underlying feeling that they really have (as they usually always have in practiced) received a fair bit of trust already from the community in the meantime. Another way of saying this might be: from the candidate's point of view, this makes the community more accountable for the criticisms they provide at RfA. -- j⚛e decker ^talk 16:49, 13 February 2013 (UTC) reply

3. I've considered this proposal for while and I'm coming down on oppose. I like the idea of giving the bureaucrats power to advise as a failing option. However, I'd be uncomfortable with the idea of an editor being promoted a few months after his/her RfA by the bureaucrats. (A lot of my opposes are fundamentally that the candidate has done little content creation or significant content-building work, and that isn't usually going to go away with a few stubs created or even a GA worked on.) Espresso Addict ( talk) 01:12, 14 February 2013 (UTC) reply
4. Main strong point of current RfA is having numerous editors examining candidate's history and contributions. This proposal would mean that in those "not unless" cases it would be sole job of bureucrat to make sure that candidate hasn't made any major mistakes during period since last RfA.-- Staberinde ( talk) 11:20, 1 March 2013 (UTC) reply

Discussion of Not Unless

This isn't a bad idea, though I might phrase it differently. I think this is similar to an arbcom result of advise. "Unsuccessful - The community advises the requester of X." This sort of guidance might be nice. That said, I believe the bureacrats have repeatedly said that they really prefer binary choices. So advise would need to be clearly espoused by the commenters in an RfA to gain that result I think. - jc37 21:13, 6 February 2013 (UTC) reply

I agree with the above regarding phrasing. But this idea maintains the premise that adminship is something to strive for and it actively sets out a box to tick. The idea of any meaningful discussion occurring with the >30 opposers needed to sink an RfA these days is also unlikely Jebus989 ^✰ 08:52, 7 February 2013 (UTC) reply

This on its own isn't going to revolutionise RFA because most fails will still simply be that. But there have been RFAs where this would be relevant. As for the thirty opposes argument, there are rarely thirty oppose rationales, most opposes will echo a previous oppose. The example I gave of the nominator picking up the candidate's PC and accidentally making an edit as them is a real example and delayed that person becoming an admin by nearly a year. An advise would be different and would still require a further RFA which can't happen for several months. Ϣere SpielChequers 12:36, 7 February 2013 (UTC) reply

• I think there might be a back-firing effect here, in some cases. Often when I oppose, particularly if it seems likely the candidate will fail, I try to be kind and only point out a few of the problems I see. If this were instituted, I'd be more likely to give more details, lest my oppose be wrongly construed as a "not unless" statement. To clarify my oppose above, I would support advise being interpreted along the lines of: in the closing bureaucrat's opinion, another RfA run in 3 months when the following concern has been worked on would be appropriate. I'd hope it might prevent knee-jerk opposes based purely on limited time since the last RfA. Espresso Addict ( talk) 01:12, 14 February 2013 (UTC) reply

Lower the bar

The numerical level of support required to pass an RfA should simply be lowered. 70+% support is simply too demanding; it excludes many good candidates. Even a slight reduction could help significantly. Everyking ( talk) 00:57, 7 February 2013 (UTC) reply

Support for Lower the Bar

1. Everyking ( talk) 00:57, 7 February 2013 (UTC) reply
2. We need to change this. Here's one scenario: If there are a lot of questionable opposes, pushing the total below 70%, the bureaucrats are certainly within their rights to close as "successful"; however they will feel under strong community pressure to close as "unsuccessful" even if they think the opposition's case is weak. I think I've seen this happen in the past. — This, that and the other (talk) 11:05, 7 February 2013 (UTC) reply
3. Yes. Kurtis ^(talk) 19:53, 7 February 2013 (UTC) reply

Oppose for Lower the Bar

1. 70% support means that one in three Wikipedians oppose the candidate. Reducing the threshold would mean that almost half the community opposes an adminship, yet he wins it anyway. Supermajorities should remain required. Ypnypn ( talk) 15:43, 7 February 2013 (UTC) reply

   I'm not proposing simple majorities. Supermajorities are just fine, but 70+% is a particularly high supermajority, isn't it? I'm not proposing a specific number here, but if, for example, we required 66% support, that would mean about two-thirds of the community supported a candidate, which seems like a fairly strong endorsement. Everyking ( talk) 16:19, 7 February 2013 (UTC) reply

2. Very few candidates fall into the range between 66 and 70%. This isn't going to help much. Bureaucrats already have a certain amount of discretion when appropriate. DGG ( talk ) 18:00, 7 February 2013 (UTC) reply

   The purpose of this proposal is to address the need for a lower numerical standard, not to establish what particular percentage of support we should require. Everyking ( talk) 19:01, 7 February 2013 (UTC) reply

3. 70% is fine. It is high enough to balance the inbuilt support bias due to the frequently unqualified !vote rationale of friends and IRC followers. Leaky Caldron 20:02, 7 February 2013 (UTC) reply
4. Whatever else we come up with, I don't want this one. If a significant portion of the community – and approx. 30% is a significant portion – does not trust someone with some powerful permissions, then those permissions should not be given. The occasional admin who should not have become an admin ends up being a real problem for the rest of us. -- Tryptofish ( talk) 23:31, 7 February 2013 (UTC) reply
5. Echoing Tryptofish here. I find the threshold for success of 76% currently in use ( Wikipedia:Requests for adminship/Salvidrim/Bureaucrat discussion) to be on the low side, assuming opposes are substantive. Espresso Addict ( talk) 17:21, 8 February 2013 (UTC) reply
6. This isn't a problem. -- Michig ( talk) 18:21, 8 February 2013 (UTC) reply
7. An extremely high amount of community trust is needed in admins. The current requirements need not be lowered. dci | TALK 06:27, 10 February 2013 (UTC) reply
8. Nah. Given the different levels of involvement of !voters and the potential for a "friendship effect", 70-80% is not an unreasonable bar. -- regentspark ( comment) 14:39, 10 February 2013 (UTC) reply
9. Oppose. I'm not sure lowering the support needed to become an admin would be a helpful answer.-- Epeefleche ( talk) 00:58, 12 February 2013 (UTC) reply
10. Nope, the threshold is sufficient where it is at, and lowering it would be concerning. Tiggerjay ( talk) 19:58, 13 February 2013 (UTC) reply
11. ‑Scottywong | communicate _ 06:18, 19 February 2013 (UTC) reply
12. 70% is too low. Stifle ( talk) 13:09, 27 February 2013 (UTC) reply

Discussion of Lower the Bar

• This would help in that it would increase the number of admins appointed. Judging from people like myself who got over 60% in a first run and became an admin later, I like to think it would probably give us an OK group of extra admins. Last time I saw any research on it the level of support in an RFA wasn't a very good indicator of success or failure as an admin, so we should be able to lower the margin for success without greatly altering the quality of the admin cadre. It might even improve if it prompted Opposers to put more effort into actually reviewing a candidate's edits in search of evidence strong enough to sink an RFA. But I'm not going to support at present as I don't think it would help reduce the hazing ritual aspect of RFA, and unless we do that the problem will remain that there are lots of people out there who'd make great admins, but who won't put themselves through RFA in its current form. Ϣere SpielChequers 00:15, 14 February 2013 (UTC) reply
• I'm very, very hesitant to support lowering the bar at RFA. I recognize the fact that RFA's of poorly qualified candidates usually fail and those that should pass usually do. But, I'm not sure the positive would outweigh the negative here. It's very rare that an RFA of a candidate generally qualified fails; if it does, it's usually because of one or a few significant issues about the candidate's judgment or experience (indicating that it's community consensus that those issues are too significant to give the candidate a mop). Bottom line is, if a candidate can't get to at least 70% or thereabouts, I don't think there is consensus to set the bit. And I don't think I'd be comfortable making it much lower. Tyrol5 [Talk] 19:25, 19 February 2013 (UTC) reply

The work of finding suitable and well-prepared candidates isn't getting done.

Concerned editors start searching for quality candidates

Simply put, if you don't think the recruiting is good enough, then do some recruiting of your own. AutomaticStrikeout ( T • C) 04:31, 6 February 2013 (UTC) reply

Support for Start Searching

1. People are perfectly able to nominate candidates right now. The floodgates are open, and I don't see any flood. There is a lot to be said for solving the problem without changing any rules. -- GRuban ( talk) 15:20, 6 February 2013 (UTC) reply
2. Recruiting seems to me to be a far better focus than most of what I've seen above. This is a weak area because many of us have good candidates in mind but don't necessarily have the time or energy to research the candidate and write up a good nomination statement (one that contains examples and includes diffs). We'll probably need to think out of the box on this one but we could do things like WP:Admin nom noticeboard where editors could suggest candidates and get feedback or even some help on researching the candidate. -- regentspark ( comment) 14:44, 10 February 2013 (UTC) reply
3. I don't think it's this simple, but I do think more candidates would be better than fewer. Chick Bowen 23:52, 10 February 2013 (UTC) reply
4. Sounds like a good idea even if I do not feel up to it myself. Graeme Bartlett ( talk) 08:51, 11 February 2013 (UTC) reply
5. Well, yes. Stifle ( talk) 13:10, 27 February 2013 (UTC) reply

Autonom

Auto-prospecting

Similar to Autonom this would use a bot to find likely candidates, but with a few extra checks; Currently active, 12 months block free etc. The Bot wouldn't publish the list but would instead Email batches of likely candidates with an offer from a panel of potential nominators to review any of them who were willing to run. No-one would be emailed twice, and a fresh batch could be run whenever there were enough nominators ready to assess people. That way no-one would be publicly put on the spot and feel pressured to explain why they weren't willing to run.

Support Auto-prospecting

1. As Proposer Ϣere SpielChequers 16:35, 6 February 2013 (UTC) reply
2. A bot cannot do everything that is required. However, it could be used to lay groundwork and give interested nominators a starting point to work from. AutomaticStrikeout ( T • C) 18:16, 6 February 2013 (UTC) reply
3. I support this as an idea but would omit all the unnecessary complications: something like ScottyWong's admin score tool could be used to rank all those who've transcluded the "might like to be an admin someday" userbox, producing a nice table on a page somewhere that could autoupdate every so often. Then a team of admins / respected editors can, if they feel like it, use the table as a starting point to look for new recruits, and leave them a talk page message if they find suitable candidates. As I mentioned before though, no RfC rubber stamp is needed for this to be done Jebus989 ^✰ 18:58, 6 February 2013 (UTC) reply
4. This sounds like a promising way to connect good, experienced editors (who may be reluctant to nominate themselves or ask for nominations) with willing nominators, with the end result being more "fertile" RFAs and theoretically, more admins without any change of standards. — Rutebega ( talk) 02:13, 7 February 2013 (UTC) reply
5. Yes please. This could work by itself, or alongside the "autonom" proposal above.
6. This already exists in some form, see User:Scottywong/Admin hopefuls. It doesn't update automatically (because it takes several hours to run each time), but I can manually run it every once in awhile if there is interest. It only runs on users that are in Category:Wikipedia administrator hopefuls. It was last updated in November 2012, so it is not up to date currently. ‑Scottywong | babble _ 19:12, 7 February 2013 (UTC) reply

   That looks like a good starting point. A variant of the tool could be created which is not limited to the Hopefuls category: it finds the top 10 or 20 scores and forwards those candidates to some volunteer nominators. A list of "already considered" would have to be maintained so editors dont get considered twice. -- Noleander ( talk) 04:11, 8 February 2013 (UTC) reply

   If someone self identifies as an admin wannabe then I see no great harm in listing them and even highlighting those who might be ready. This proposal is really looking for the fully qualified candidates who haven't self identified as interested in adminship, and I don't think it appropriate to list them - better to send them an email. Ϣere SpielChequers 17:31, 8 February 2013 (UTC) reply

   Implicitly you see harm in an opt-out list, similar to WP:EDITS, being used to this end, why's that? Jebus989 ^✰ 19:57, 8 February 2013 (UTC) edit: Also sorry to SW for suggesting exactly this, possibly I came across your list and subconsciously put it forward as my own idea above, apologies reply

   Opt out is fine for SW's list. But I wouldn't rely on an opt out list for this proposal. There have been quite a few threads at WT:RFA where people discuss potential candidates for RFA and indeed RFB. I'm not a big fan of such processes because it involves discussing someone without necessarily telling them. I'm not too bothered when the subjects are admins who might make good crats, people who've failed an RFA a few months ago and might be ready to run again and especially for people who display an admin Wannabe userbox. Such people have all at least partially put their hat in or near the ring. But if we are looking to approach people who may not even have considered adminship then my view is that we should be more diplomatic. Almost all the people who I've nominated or offered to nominate I have contacted by Email or at meetups. If RFA was less of a hazing ceremony then I'd be more comfortable sounding people out publicly on wiki. Ϣere SpielChequers 11:28, 9 February 2013 (UTC) reply

7. I like this idea. No harm in giving it a test run. Why not? Kurtis ^(talk) 19:57, 7 February 2013 (UTC) reply
8. This sounds like a very interesting and promising idea. Let's give it a shot. MJ94 ( talk) 23:44, 7 February 2013 (UTC) reply
9. Seems to have some good upsides, with little or no downsides. -- Noleander ( talk) 01:26, 8 February 2013 (UTC) reply
10. Now this seems at least worth a try. Beeblebrox ( talk) 03:39, 8 February 2013 (UTC) reply
11. Yup, worth a try. — sparklism ^hey! 08:57, 8 February 2013 (UTC) reply
12. Sounds worth developing. I don't think it should only run on admin hopefuls, but I think there should be a clear way of opting out of being considered, eg by adding one's name to a list and/or displaying a "not interested in adminship" user box/category. Espresso Addict ( talk) 17:33, 8 February 2013 (UTC) reply

    I wasn't intending to exclude people with the Admin Wannabe box, though if we don't they could be in both Snottywong's list and this. Of course we need to exclude people with the "not interested in adminship" userbox. Thanks for pointing that out. Ϣere SpielChequers 11:34, 9 February 2013 (UTC) reply

13. This is a really good idea, it would make a list of potential candidates rather than waiting for them to poke their head up. James086 ^Talk 19:35, 8 February 2013 (UTC) reply
14. Certainly worth trying. -- Michig ( talk) 19:54, 8 February 2013 (UTC) reply
15. yup, lets do this. Martijn Hoekstra ( talk) 10:23, 9 February 2013 (UTC) reply
16. Seems like a good idea what could work. ·Add§hore· ^{Talk To Me!} 10:59, 10 February 2013 (UTC) reply
17. An interesting suggestion. Community consensus seems lacking in terms of any major changes to process at RFA. It only seems logical that the community begin working at the other end: searching for/vetting of suitable candidates for adminship. This suggestion would lighten the workload on potential nominators by providing them a pool of statistically qualified candidates out of which they may select the most mature, level-headed, well-balanced editors and offer them an RFA nomination. I would suggest some sort of subscription-based pool of nominators to receive a (monthly? quarterly?) list of potential candidates, in which well-established editors could opt-in to see the candidates statistically vetted by the bot. Really neat idea, WereSpielChequers. Tyrol5 [Talk] 00:01, 11 February 2013 (UTC) reply
18. This sounds like it could work. However we do need to set a criteria set which seemed to be controversial. Nevertheless I like the idea. Graeme Bartlett ( talk) 09:02, 11 February 2013 (UTC) reply
19. Could work. Some details to be worked out. The obvious -- criteria. But also the point Jusdafax raises ... perhaps for those editors, word could be left on their page. Or perhaps that could be done for all editors who qualify. I would jigger the qualification standards so that -- certainly at the outset -- we don't have a flood. We could then consider relaxing the standards as we get some experience, if appropriate. Also, the list could reside somewhere (in addition, perhaps).-- Epeefleche ( talk) 02:04, 12 February 2013 (UTC) reply
20. I think on net something like this worked out for autopatrolled. MIght work here. -- j⚛e decker ^talk 05:27, 12 February 2013 (UTC) reply
21. I believe a bot that is looking for matches to the objective RfA criteria being worked on under a seperate section would be a great way to have people invovled. It would still require a full RfA process, but it would help bring people in. Tiggerjay ( talk) 08:17, 13 February 2013 (UTC) reply
22. I like this idea. — ΛΧΣ ²¹ 03:27, 14 February 2013 (UTC) reply
23. Great idea. It would narrow down potential admins. And then, a more rigorous process should be followed. Harsh (talk) 13:57, 14 February 2013 (UTC) reply
24. Yes we need any way to support more administrators in the project. Secret ^account 03:37, 19 February 2013 (UTC) reply

Oppose Auto-prospecting

1. I understand the rationale behind this idea, but am not of the opinion it would be a good way to review candidates. Automatically-generated lists, no matter what criteria they utilize to find candidates, are no supplement for nominations made by people with the experience of interacting with particular candidates. dci | TALK 06:31, 10 February 2013 (UTC) reply
2. I don't know. Where is the panel of nominators going to come from? Isn't this adding a lot of work? Ideally, a nomination should come from an established editor who knows the candidate well and often this becomes a matter of finding the right person and the right time. Generating lists of prospects seems to me that we'll end up adding more formal overhead to the process (pretty soon everyone will have to go through this nominating panel). I see support for this idea but I don't think it is that different from the "Commissioners" idea above. -- regentspark ( comment) 14:50, 10 February 2013 (UTC) reply

   Well I'm one of the potential nominators. I nominated five of the last 100 successful candidates, though I haven't nominated anyone in over a year. So yes even if I was the only nominator who joined in this could easily generate four or five extra admins a year as this method would probably find several people who are probably ready and crucially are willing to run. That doesn't mean it would replace existing methods anymore than admin coaching did, if someone approached me and after vetting them I was willing to nominate them then it would be a standard RFA. The difference between this and the commissioner's proposal further up is that these would be normal RFAs with the community deciding, so this is a patch that might keep RFA working unreformed for a bit longer while we try to fix it. Whilst under the Commissioner proposal Adminship would become something more akin to Rollback or AutoPatroller - a right that a highly trusted user gave to other users who meet a particular criteria; Replacing a dysfunctional and failing system with something that is tried tested and works well in Wikipedia. I'm happy to support both ideas, but they are radically different potential measures. Ϣere SpielChequers 01:10, 11 February 2013 (UTC) reply

   Thanks for the explanation. My main concern is that the vetting process may end up becoming a requirement in the sense that candidates who haven't been through it might find it harder to get the requisite number of supports. Bureaucracy, sadly, takes on a life of its own and that's why it is better to keep things simple (imo). -- regentspark ( comment) 22:50, 11 February 2013 (UTC) reply

   I see your point, but in some senses I'd compare this with the old Wikipedia:Admin coaching process, for all its faults that did produce a number of extra candidates, but it didn't stop self noms and normal uncoached noms taking place at the same time. Ϣere SpielChequers 14:02, 13 February 2013 (UTC) reply

3. This looks good on the surface but does not ring true to me. For one thing, some of us have chosen to disable the email option to eliminate off wiki communications. That's a interesting group you eliminate from consideration. Also, lists can be manipulated, and we then need a transparency process and enforcement. No I don't think this is the direction to go in. Jus da fax 22:56, 11 February 2013 (UTC) reply

   Yes about thirty percent have opted out of Email, and this would only work for the other 70%. If we ever ran short of good candidates we could of course broaden it to send a talkpage message to those who've opted out of email. As for manipulating the list, this is just a group of experienced users who would be encouraging to think about running - if we started including people who clearly couldn't get through RFA it would be easy to add an extra criteria to the list. Ϣere SpielChequers 14:02, 13 February 2013 (UTC) reply

I'd say for transparency that going to only talk page messages from the start would be better. I could think about supporting that, but the way the invites could be "slanted" to include those with a particular agenda is troubling. Who exactly would be making these invites and how would the inviters be chosen? "Automatic" does not mean much, in this context, as the programming can be subtly manipulated. There is a potential for abuse here. Jus da fax 21:01, 13 February 2013 (UTC) reply

Abuse of what? Are you worried the bot will invite too many people who disagree with you? They still have to pass an RfA. — Rutebega ( talk) 23:35, 13 February 2013 (UTC) reply

Transparency is appropriate for many things, but it just isn't appropriate for asking people if they fancy taking on a role such as adminship; The time to be transparent is when they agree and are ready and start the RFA. As for slanting the list, the criteria would be public and straight forward - otherwise they wouldn't be easy to code. I'm not sure what sort of slanting would be possible as the sorts of things that divide the admin cadre such as deletionism v Inclusionism and civility Police v tolerance of vested contributors are not things that a bot could code for. Ϣere SpielChequers 23:52, 13 February 2013 (UTC) reply

Actually, a bot could go somewhere with user pages -- eg quite a few people include userboxes relating to where they stand on the inclusionist–deletionist spectrum, and someone showing lots of those FA/GA/DYK symbols at the top of their user page or similar is more likely than average to be opposed to the blocking of content contributors on civility grounds. Espresso Addict ( talk) 01:18, 14 February 2013 (UTC) reply

It seems like this idea could really go pretty far in finding good candidates for nomination, as an expansion of SW's tool, which is useful but incomplete. Of course, lots of people don't use many templates, userboxes, or categories on their userpages (myself included, though I try to include what I consider relevant), but if a bot/tool could analyze those things accurately, it would be really cool, to use the technical term. Of course, if things get complicated (SW's tool seems pretty straightforward in terms of scoring algorithms), we could run into weighting debates, since the bot would have to decide which traits most make for good admin candidates. I guess all these details will be hashed out in future discussions though, so we'll cross that bridge when we come to it. — Rutebega ( talk) 01:43, 14 February 2013 (UTC) reply

I take your point about userboxen, and it might be safest to agree that the only userboxen that the bot should take account of would be ones that explicitly opt out of wanting to be considered for adminship. As a nominator I give them little weight, though occasionally I've suggested that a prospective candidate reconsider an old userbox that doesn't reflect their current editing. FA/GA and so forth are different as I think everyone at RFA would accept that they are a desirable thing for a candidate to have. I accept that some such candidates might get questions as to whether they would do out of process unblocks if they perceive that a vested contributor is being hassled by a civility Policeman. But my experience is that many creators of quality content are as keen for a civil more adult tone here as any civility policeman. Ϣere SpielChequers 12:37, 14 February 2013 (UTC) reply

Comment on Auto-Prospecting

1. Set the parameters too low for this and RfA will be flooded with candidates who have neither the experience, aptitude, judgement, maturity and character to be a satisfactory candidate, much less a successful one. This can only work in conjunction with a mentoring/ nomination mechanism to refine the lists down to the best possible selections. Leaky Caldron 11:45, 9 February 2013 (UTC) reply

   That's a fair point, but I'm pretty sure there are more good candidates out there than our active nominators could cope with. So as long as we take from the top of the deck this should work - the limit is going to be good nominators who know what sort of candidates the community is likely to accept. Ϣere SpielChequers 19:50, 9 February 2013 (UTC) reply

   I'm not particularly concerned about any parameters in a system like this being too low. Like WereSpielChequers said above, a pool of knowledgeable nominators would provide the guidance, vetting, and holistic analysis of a potential candidate that a bot could never provide. I've proposed above in the support section and I'll reiterate here a suggestion to create some sort of subscription-based pool of nominators in which interested and knowledgeable editors may receive a list (by email?) of potential candidates for vetting. Or, in the interest of transparency and non-cabalism, post the list on-wiki somewhere in the project space (allowing, of course, editors to opt out). Tyrol5 [Talk] 00:10, 11 February 2013 (UTC) reply

2. This has already been alluded to above by other users: I think this would work better if the bot generated a list that nominators looked at, rather than emailing potential candidates directly. Yaris678 ( talk) 12:30, 2 March 2013 (UTC) reply
3. Maybe the bot could use an algorithm informed by Modeling Wikipedia admin elections using multidimensional behavioral social networks (mentioned in Signpost). I'm not saying that the whole of the model described there has to be implemented, that might be too complicated. But the paper might give some inspiration. There is also obviously WP:WikiTrust. Yaris678 ( talk) 12:30, 2 March 2013 (UTC) reply

Project for nominators

Nominators are an important but poorly supported part of the RfA process. A project (or task force, or forum) should be created to support existing nominators and to encourage editors to start nominating. Possible functions include:

• to act as a forum for discussing nomination-related matters, such as methods of identifying potential candidates, investigating potential candidates, writing nomination statements;
• to compile and maintain lists of potential candidates (this might need a private space, if editors who have not expressed a desire to be nominated were to be included);
• to inform and encourage editors who would like to participate as nominators, and to recruit new nominators.

Participation in the project would be entirely informal and voluntary, and in no way a prerequisite for nominating. This proposal could be integrated with the Auto prospecting proposal, above.

Support Project for Nominators

1. As proposer. Espresso Addict ( talk) 04:30, 9 February 2013 (UTC) reply
2. Strong support. An active place where nominators could discuss potential candidates, encourage participation in the process on the part of qualified editors, and work with interested candidates is needed. dci | TALK 06:25, 10 February 2013 (UTC) reply
3. I like that idea. No clue what actual effect it would provide, but very unlikely to cause any new problems, so probably worth trying.-- Staberinde ( talk) 10:48, 10 February 2013 (UTC) reply
4. Good idea. I'm sure there are many editors who have the perfect candidate in mind but don't haunt RfA and have no idea how to go about the process. Any help they get is a good idea (see also my WP:Admin nom noticeboard suggestion somewhere above). -- regentspark ( comment) 14:53, 10 February 2013 (UTC) reply
5. Can't hurt, could help. -- j⚛e decker ^talk 08:03, 12 February 2013 (UTC) reply
6. A collaborate effort to help improve and discuss candidates and encourage further nominations at the process. It could help, and it certainly isn't doing any damage to the project. TBrandley ^{( what's up)} 03:41, 14 February 2013 (UTC) reply
7. Another good idea. — ΛΧΣ ²¹ 03:45, 14 February 2013 (UTC) reply
8. Do not see how it could harm.-- Ymblanter ( talk) 18:52, 14 February 2013 (UTC) reply
9. This is one thing I was thinking about for a long time and which will be quite good to have. A collaboration between the nominators and candidates is one small step to improve the RfA process. ~ TheGeneralUser (talk) 12:00, 18 February 2013 (UTC) reply
10. Actually, I don't see why an interested party couldn't just do this right now, or at least throw up a proposal at the Wikipedia:WikiProject Council or even try to revive Wikipedia:WikiProject Administrator and repurpose it to do this. Beeblebrox ( talk) 18:54, 18 February 2013 (UTC) reply

    Indeed, we don't need an RfC to start a wikiproject! I'd prefer a new location to make it clear this is a new effort, unrelated to old ones, and focused on facilitating nominations under the existing RfA system rather than any broader interest in the RfA process and its possible reform. Espresso Addict ( talk) 23:45, 18 February 2013 (UTC) reply

11. Per Joe. Rutebega ( talk) 21:43, 18 February 2013 (UTC) reply
12. A lot of the solutions proposed here and elsewhere, while potentially viable ideas, face the inevitable challenge of garnering consensus for their adoption. This, on the other hand, is an idea that could be enacted immediately with a tinge of boldness. Centralizing resources for nominators via a single wikiproject is a good idea and could be integrated with Wikipedia:Request an RfA nomination to facilitate interaction between viable sysop candidates and potential nominators. The project could also provide outreach to editors qualified for the tools but otherwise haven't considered an RFA for whatever reason. Having a nominator approach an editor, I think, is more reassuring to a potential candidate than making the decision to run the RFA gauntlet on his/her own. In essence, an impartial opinion is helpful to most candidates, I would think, since a potential nominator familiar with the RFA process and the expectations of participants there could recognize any red flags in the contributions to a potential candidate and address them with the user before an RFA is even created. Tyrol5 [Talk] 19:13, 19 February 2013 (UTC) reply
13. Support trying it, no idea if it'd work. Stifle ( talk) 13:11, 27 February 2013 (UTC) reply

Comments on Project for Nominators

• Back when I was much more active, we had admin coaching--essentially a project for nominators. At first, admin coaching worked well because it helped both nominators and candidates feel more comfortable about nomination while at the same time providing some legitimate training for potential admins. The problem the community had with it was that it seemed like a way to simply learn to pass RfA. Keeping this response in mind, will the community look down upon nominations coming through a wikiproject organized to get potential candidates through RfA? Malinaccier ( talk) 17:05, 2 March 2013 (UTC) reply