In Round Two of the recent Requests for Comment (RfC) on the Requests for Adminship (RfA) process, there was an 8 to 4 vote (and two of the opposers later changed their minds) in favor of the proposal for "Not unless" candidates, and a 7 to 2 vote for Unbundling - limited block/unblock. We (the closers) are hoping that the broader community will respect the process and the rationales of these voters as much as we do. This vote will run for one week.

- Dank ( push to talk) 22:53, 27 March 2013 (UTC) reply
Ed  ^{[talk] [majestic titan]} 21:37, 28 March 2013 (UTC) reply

For voters who haven't read the close to Round Two: four proposals got such broad support that they're not up for a vote here, and you're encouraged to read them. The two proposals here were the ones that got mild support, based on those voters' interpretations. Thanks for your participation. - Dank ( push to talk) 11:57, 28 March 2013 (UTC) reply

Note: a third proposal, "Probation", has been added. - Dank ( push to talk) 21:19, 30 March 2013 (UTC) reply

Quoting WereSpielChequers on the first proposal:

the closing [bureaucrat] would have the option of closing with a statement such as ... "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. ... in areas where judgement is concerned the crat would consult with the relevant opposers before promoting such a candidate.

Right now, in those relatively rare cases where a candidate can't gain consensus support from RfA voters because of weakness in a specific skill (we're not talking about general trustworthiness, experience or clue here), the bureaucrats have little choice but to fail the RfA. Many years ago, we had hundreds passing RfA each year, and if they got turned down, they often ran again a few months later. These days, candidates generally don't run again if they fail an RfA for any reason, even when the voters are very encouraging. Adminship is no longer "hot", and people usually move on to other areas that they find more satisfying. The "Not Unless" proposal is intended to allow those candidates to pass an RfA who would almost certainly pass a later RfA after they remedied some specific deficiency, in cases where the judgment call on that one deficiency is so straightforward that the RfA voters are happy to hand that call over to the bureaucrats.

Support "Not unless"

Support This seems like a good approach. These types of !vote opposes seem to be fairly common, and I've seen several RfA where someone has failed on a previous one with a bunch of such !votes, improved, come back and won. So I can easily imagine that many others that might take the comments to heart and improve might be burned from actually trying again. I do hope though that crats would look for 'not unless' statements in the !votes and not apply this unless they are found and that there are enough of them that if changed would move the candidate into the passing range. I do worry though that this might actually lower the initial support numbers. In a few cases where I have voted support in RfAs, if I knew not unless was available standard !vote, I might have voted that instead. PaleAqua ( talk) 00:52, 28 March 2013 (UTC) -- Actually I think it should be required that enough oppose equivalent !votes which explicitly identify themselves as not unless should be present for the RfA to pass before the not unless close option is used. PaleAqua ( talk) 01:22, 28 March 2013 (UTC) Moving to oppose as it looks a better alternative is being considered. PaleAqua ( talk) 03:25, 30 March 2013 (UTC) reply

1. As author of Wikipedia:Requests_for_adminship/2013_RfC/2#.22Not_unless.22_candidates. With the explanation I gave this proposal then it attracted 8 supports and 4 opposes. Clearly this debate is going rather differently, perhaps the best quarter at RFA for a couple of years has reduced our appetite for RFA reform. Opposition includes those who believe that candidates who come close could be persuaded to run again once they've addressed the reason for their rejection, sadly I fear that some people who would now make excellent admins will never agree to run a second time; Others oppose because this sounds more bureaucratic, there I can merely disagree, in my view it would be less bureaucratic to do this than to force someone into a second RFA. Lastly there is Opposition becasue Bureaucrats should not have sole decision on this. I largely agree, hence in my draft of the proposal there was the all important caveat about consulting with opponents. To put this round the other way, if a bunch of people oppose because an otherwise excellent candidate has never written reliably sourced content, and that candidate then writes a bunch of FAs and has some of their erstwhile opponents trying to persuade them to run a new RFA, would it not be better all round if a crat could simply update the earlier RFA from "Not unless X" to "Promoted as X has now been achieved?". Ϣere SpielChequers 21:12, 3 April 2013 (UTC) reply
2. Support: This is a fine idea, another tool in the RfA voter's arsenal, just needs more detail on its implementation. I would vote for it at an RfC if it required voters to explicitly put "not unless" as their oppose vote so their meaning would be unambiguous. I don't think the closing Bureaucrat should have to check back in with "not unless" voters—they are already trusted to be able to handle these kinds of decisions. If it creates another good admin who wouldn't have gone through a second RfA otherwise, then it's worth implementing. — Bility ( talk) 00:50, 5 April 2013 (UTC) reply

Oppose "Not unless"

1. RfA should be simply a question of whether there is a consensus to support. Referring the authority of RfA to a subsequent discretionary judgement of a bureaucrat is not warranted. If consensus is lacking only because the candidate has yet to prove something, let him run again. -- SmokeyJoe ( talk) 01:11, 28 March 2013 (UTC) reply
2. Oppose, this seems almost impossible for a crat to close, and if he did it would likely be more trouble than it's worth. Tazerdadog ( talk) 02:26, 28 March 2013 (UTC) reply
3. I don't think we should lower the RfA standards in this way. If someone is not yet ready to be an admin, he simply is not yet ready to be an admin. I also believe this proposal could put too much power in the hands of one crat. AutomaticStrikeout ( T • C • AAPT) 02:50, 28 March 2013 (UTC) reply
4. If the community feels a user isn't ready to be an admin because of lacks in skill X, any judgment of whether the user has subsequently mastered X enough to be promoted should similarly come from the community. A fluffernutter is a sandwich! ( talk) 02:52, 28 March 2013 (UTC) reply
5. This is like having a partial-consensus or, putting it bluntly, a half-assed one. If an RFA candidate improves, let him run again for RFA. If he has no interest in doing so, then maybe he wasn't right for the job in the first place. Feed back ^☎ 09:06, 28 March 2013 (UTC) reply
6. I can see this adding a whole other layer of complexity to the RfA process. If someone is given a 'not until' the standards of whether to promote or not then lies with a single person. Considering all crats will have somewhat different views on most things it would almost depend on which crat took the 'not until' as opposed to the community at large. Cabe 6403 ^{( Talk• Sign)} 09:50, 28 March 2013 (UTC) reply
7. Too complex, 'Crats won't like it and really demonstrates the weakness in this entire 3 month process that something for which rejection is inevitable should be presented as the best offering based on next to no significant community involvement and carrying less support than another proposal not being considered in this phase. Leaky Caldron 10:27, 28 March 2013 (UTC) reply
8. Oppose. Too complex, and I can't see it resolving the kinds of issues that can make RFAs problematic. There is seldom a specific clearcut issue that hangs in the balance between "pass" and "fail" -- and if there is, I believe the 'crats could figure out a way to resolve it without a new formal procedure. -- Orlady ( talk) 17:14, 28 March 2013 (UTC) reply
9. Oppose I've given this a bit of thought over the last few days. I get what it is intended to do but in the end I just can't support it. Crats are really here to do one thing: exactly what the community says. If the candidate falls below the threshold, they fail, if the new username is against policy they don't get it changed, if WP:BAG doesn't want the bot turned on, they don't turn it on. As was made abundantly clear to me when I ran at RFB bold decision making is exactly what the community does not expect or desire from crats. So, whether this was intended or not, this would fundamentally change the role of the crat, forcing them into an area that is the exact opposite of what they are normally expected to do, and I would imagine don't want anything to do with. It's possible this could be re-engineered in the future to something that would not have this unfortunate side effect. Beeblebrox ( talk) 21:22, 28 March 2013 (UTC) reply
10. "Improvement" is difficult to define, hard to measure, and easy to game. This essentially pushes review of negative actions by a new, on-the-fence sysop to the 'crat and her/his ability to judge "improvement," not something we want to start doing. Bureaucrats should be Bureaucrats, not making unilateral decisions. ~ Amory ( u • t • c) 22:31, 28 March 2013 (UTC) reply
11. No, I don't want to give any additional discretionary power to bureaucrats. Everyking ( talk) 23:31, 28 March 2013 (UTC) reply
12. Oppose If someone is deficient in a skill, then it will be highlighted at the RfA. If they really want to pass an RfA, then they will spend tome time in obtaining that skill for their next RfA - if they can't be bothered to do that, we probably wouldn't want them as an admin anyway.  Ronhjones   ^(Talk) 01:47, 29 March 2013 (UTC) reply
13. Oppose I see the intention, but it's a bit fudgy and inelegant. If there is a perceived problem with candidates not coming back for a second attempt even though they only failed on one small issue that could be addressed, then it might be better to work on the reasons they don't come back, rather than attempt to paint over the crack. Has a study been done on the perceived change in the number of candidates who come back a second time? Has the number really gone down? And, if so, have the candidates who haven't come back, been asked why they haven't come back? Perhaps what they need is a bit of encouragement in line with some of the proposals I note were passed in Round Two. SilkTork ^{✔Tea time} 08:28, 29 March 2013 (UTC) reply
14. Oppose.. If the community doesn't think a candidate is satisfactory in a particular area, I don't think the bureaucrats should be deciding when/if that candidate has become satisfactory. A bureaucrat is to judge consensus, not skillset. Useight's Public Sock ( talk) 16:56, 29 March 2013 (UTC) reply
15. Conditional Oppose If the probation of new admins in edge cases is being considered again as discussed on the talk page, then I don't see the need for this as it seems to me that the probation option would serve mostly the same purpose of dealing with the current almost cases without requiring crats to guess when we would change our minds. PaleAqua ( talk) 03:25, 30 March 2013 (UTC) reply
16. Strong Oppose As I understand this proposal, we would be allowing the closing bureaucrat a "special power" to simply ignore the actual outcome of a failing RFA if the overwhelming responses stated that the candidate might be ready at a later time to...what....not put the burden of time on them to continue to improve themselves? Not ready...but someone will just override the consensus in favor of a new "policy" of "No wait", "We grant it now"? I cannot support that. The way this is written it actually seems like the closer is going to keep the RFA open until such time that the candidate has demonstrated such improvement in the closer eyes...or the are to close as a tentative success but not grant adminship :until such time"? How long? Is there an immediate test the candidate must pass for the closer? There seem to be too many questions and the proposal seems somewhat unclear.-- Amadscientist ( talk) 07:29, 31 March 2013 (UTC) reply
17. Oppose per others; too much work and this isn't really the point of RfA. Rcsprinter (constabulary) @ 21:56, 1 April 2013 (UTC) reply
18. Oppose "Improvement', "relevant opposers" are both too subjective and leaves too much discretion to a 'crat. Recipe for a lot of messes. -- regentspark ( comment) 22:53, 4 April 2013 (UTC) reply

Neutral for "Not unless", and Discussion

1. I supported this originally, but today I'm feeling kind of neutral about it. I just don't see very many RfA's ever closing with a "not unless" verdict, so I don't see much use in it. Although, I can't think of any potential problems it would cause. ‑Scottywong | soliloquize _ 01:27, 28 March 2013 (UTC) reply
2. No opinion. Bearian ( talk) 15:43, 28 March 2013 (UTC) reply

Unbundling - limited block/unblock is a proposal to allow people to apply for a new userright (probably at WP:Requests for permissions) to issue blocks on accounts of less than 100 edits only for vandalism or unsuitable usernames, and on unregistered users only for vandalism. The supporters believe that, at the current rate of admin promotion, admins will be unable to handle all the anti-vandalism work soon without some help.

Support "Limited block/unblock"

1. Strong Conditional Support So long as this right has a high standard of who it can be granted to. — nerd fighter 23:44, 27 March 2013 (UTC) reply
2. This seems pragmatic. I remember from my long-ago pre-sysop vandal fighting days that getting the cavalry to come and block a vandal could impose significant delays. However, there should be a very low bar to unblocking and the block templates should be of the form "we apologise for the inconvenience, please click here if this was a false alarm" like some of the bot notices. It does seem that there is some demand for this, and the RfA process is undoubtedly no longer "no big deal", it has been a big deal for ages with a lot of politicking. Guy ( Help!) 23:56, 27 March 2013 (UTC) reply
3. Support. Dealing with vandals is about the lowest-level and most mundane task that an admin does. It would be entirely sensible to share this task a bit more widely, and the work itself is hardly ever contentious in my experience. Prioryman ( talk) 00:42, 28 March 2013 (UTC) reply
4. Support as a way for a candidate to show he's up to par. This should have a time limit, and be subject to admin confirmation. Tazerdadog ( talk) 02:29, 28 March 2013 (UTC) reply
5. Support I think this could be made to work, given careful selection of people to receive the right. -- j⚛e decker ^talk 22:45, 28 March 2013 (UTC) reply
6. Support this could certainly work, given suitable conditions: reasons for blocking are limited to obvious vandalism, username problems and possibly spam, some fairly stringent criteria be set for granting the right, and that it be easy to remove the right from someone in cases of abuse. There are plenty of experienced AIV reporters who could be trusted with the block button for vandals (it doesn't require that much judgement) but who cannot pass the current RfA process due to the excessive requirements. As noted at the original proposal most of our highly active vandal fighters used to be admins, that is no longer the case. Hut 8.5 14:07, 29 March 2013 (UTC) reply
7. Support As long as they have been on here for a set period have a good track record. The C of E God Save the Queen! ( talk) 16:50, 29 March 2013 (UTC) reply
8. Partially support only for blocks on IPs. An appropriate criterion for blockable accounts should include its age too, because it is not particularly difficult to rapidly score 100 edits. Incnis Mrsi ( talk) 19:48, 29 March 2013 (UTC) reply
9. As Author. Wikipedia:Requests_for_adminship/2013_RfC/2#Unbundling_-_limited_block.2Funblock Set out more reasons for this and garnered seven supports and only two opposes, this debate is going rather differently. To address some of the current objections: AIV is not yet backlogged, so yes this solving a problem before we are forced to. However the downward trend at RFA has now lasted five years, we as a community are no longer appointing sufficient new admins to maintain the size of our admin cadre - last year saw only 28 successful RFAs and at that rate it would take us nearly three decades to replace our currently active admins. It just isn't realistic to expect the average new admin to be active for thirty years as an admin, so we need to do something, and while I'd prefer that we appoint more admins, this proposal would enable us to keep the site going for the foreseeable future. Others make the point that if they'd trust someone with this right they would trust them to be an admin, but the history at RFA is quite clear, "pure vandalfighters" who contribute no content cannot quite get consensus for adminship even with over 100,000 edits and a faultless record at AIV. Ϣere SpielChequers 22:42, 3 April 2013 (UTC) reply

Oppose "Limited block/unblock"

1. An unfounded belief that at some point in the future an unmanageble backlog might exist does not seem to be a sufficient reason to hand out one of the most controversial admin tools. Given the fact that dealing with many vandals and spammers requires multiple admin tools such as deletion, revdelete, protection, etc, to remove the spam and vandalism and prevent it from resurfacing I do not believe this would be an adequete solution in the unlikely event that this imaginary backlog were to someday become real. Beeblebrox ( talk) 00:56, 28 March 2013 (UTC) reply
2. So this means that they could have the technical rights to undo CU/OS blocks, right? Oppose. -- Rs chen 7754 01:00, 28 March 2013 (UTC) reply
3. Oppose. The ability to block newcomers is more dangerous to the future of the project than poor blocks of regulars who know how to respond. -- SmokeyJoe ( talk) 01:13, 28 March 2013 (UTC) reply
4. Per SmokeyJoe and PaleAqua. I feel bad opposing a proposal that has been so long in the making, but in all honesty it seems like a bad idea. — Soap — 01:20, 28 March 2013 (UTC) reply
5. Oppose per Beeblebrox. I'd require more than a vague feeling that "admins will be unable to handle all the anti-vandalism work soon without some help". How about some statistics that show that we're close to the edge, where admins are barely able to keep up with blocking vandal accounts? Until there is hard evidence that there is actually a problem, there is no reason to propose a solution to a problem that doesn't exist. ‑Scottywong | chatter _ 01:21, 28 March 2013 (UTC) reply
6. Oppose There are instances where I have blocked users based on information available only to admins, such as deleted contributions and deleted revisions. I don't think it would be appropriate to have users make blocks without the ability to see the whole scope of the situation. Mike V • Talk 01:29, 28 March 2013 (UTC) reply
7. The arguments raised by Beeblebrox and Mike V have convinced me that the technical ability to block and unblock accounts is far less restricted when it is paired with the rest of the administrative toolset. However, I disagree with the opinions expressed by SmokeyJoe and Rschen7754 — I think many regular editors involved in AIV, UAA, and SPI are sensible enough to avoid wantonly blocking good-faith contributors, or to undo blocks applied based on CU/OS evidence. Kurtis ^(talk) 02:20, 28 March 2013 (UTC) reply

   I don't know why the many sensible enough regular editors involved in AIV, UAA, and SPI, approved to block young accounts, shouldn't be allowed to see deleted contributions or block old accounts. -- SmokeyJoe ( talk) 03:12, 28 March 2013 (UTC) reply

   Hmm, you have a point there. Perhaps adminship should be easier to attain? Kurtis ^(talk) 03:40, 28 March 2013 (UTC) reply

   Yes. I suggest reviewing the standard required to pass RfA in 2004-2005, and looking at the (low) failure rate of admins who passed in 2004-2005. Subsequently the number of new seriously active contributors exceeded the capacity of the community to feel that everybody knew everybody else, and RfA requirements tightened. -- SmokeyJoe ( talk) 04:09, 28 March 2013 (UTC) reply

   I agree, and I've often thought the very same thing myself. Most people who've passed an RfA did quite well with the added toolset. Kurtis ^(talk) 11:33, 28 March 2013 (UTC) reply

8. Mike V makes a compelling point and SmokeyJoe at least makes an interesting one. While blocking a vandalism-only account may not be likely to cause any damage, I can imagine that it would be possible that other situations potentially covered by this would be best handled by an admin. AutomaticStrikeout ( T • C • AAPT) 02:54, 28 March 2013 (UTC) reply
9. Oh good lord, no. The block button is in no way comparable to rollback in potential for major screwups (hint: rollback = little; block/unblock = lots), especially if we're also bundling the ability to unblock users who may have been blocked for very good reasons non-admins can't see. I see no evidence of some unmanageable backlog of new/unregistered editors who are in such dire need of blocking that we need to deploy extra manpower by lowering the bar for access to the block/unblock buttons. A fluffernutter is a sandwich! ( talk) 02:57, 28 March 2013 (UTC) reply
10. SmokeyJoe took the words right out of my mouth. Bad idea... RxS ( talk) 04:01, 28 March 2013 (UTC) reply
11. Oppose - Essentially this would create an "Admin lite". How on earth would we discriminate between those good enough for "Admin-lite" but mysteriously not able to be trusted with the full janitorial toolset? To boot, adding yet another layer of hierarchy would only worsen the perceived gap between "full" admins and regular editors. Manning ( talk) 05:23, 28 March 2013 (UTC) reply
12. Oppose - This would be detrimental to the project. We need to encourage new editors, not target them by arming everyone with blocking powers. Feed back ^☎ 09:12, 28 March 2013 (UTC) reply
13. Oppose - despite, in theory, this working I would imagine in practice it would cause issues as suddenly the amount of new users getting blocked would rise. In my opinion a block should only be used when all alternative solutions have failed (i.e. discussion) unless its an obvious pure vandalism only account. Speaking as a non-admin, surely there's not that many VOA running riot these days that the admins at AIV can't handle it? Cabe 6403 ^{( Talk• Sign)} 09:56, 28 March 2013 (UTC) reply
14. Oppose - It may be a mundane task, but uninvolved admins should be the only ones to perform it, as they are the ones whom are community-judged to be the best at making decisions. Allowing any Tom, Dick and Harry to perform these actions would only harm the project (another non-admin viewpoint) Lukeno94 (tell Luke off here) 10:31, 28 March 2013 (UTC) reply
15. Oppose - ill conceived. The real practical consequences were not adequately thought through with this one. O#1 sums up the major deficiencies. Leaky Caldron 10:35, 28 March 2013 (UTC) reply
16. Oppose - I am pretty sure that this will lead to numerous very controversial blocks. Damage that can be done with this user right wouldn't be something that can be simply reverted. Furthermore, if this user right is simply granted by admin on request, then that admin is clearly responsible if it turns out that he failed to do proper background check and granted such dangerous user right someone who shouldn't have received it. Standards of "what makes candidate suitable" would be probably also very problematic to work out. Frankly, the blocking tool should be absolutely last thing to unbundle from current admin toolset.-- Staberinde ( talk) 10:39, 28 March 2013 (UTC) reply
17. Oppose - I see trouble. Bearian ( talk) 15:42, 28 March 2013 (UTC) reply
18. Oppose for reasons effectively articulated by others. -- Orlady ( talk) 17:16, 28 March 2013 (UTC) reply
19. Per Beeblebrox and SmokeyJoe. Blocking users with <100 edits is vastly more important to me than blocking other editors. The latter make noise and go noticed, but the former is easily silent and the overwhelming majority of blocks. ~ Amory ( u • t • c) 22:34, 28 March 2013 (UTC) reply
20. Oppose: blocking newbies is probably the most damaging action an administrator can do. Yes, an improper block can be overturned, but will the editor return to editing? -- Carnildo ( talk) 23:12, 28 March 2013 (UTC) reply
21. Oppose I don't see a need. There's rarely a backlog at AIV - so that's no reason to force this one. At a time when we are trying to entourage new editors, this could end up having the reverse effect.  Ronhjones   ^(Talk) 01:56, 29 March 2013 (UTC) reply
22. Oppose. The blocking tool is the most contentious tool. New users are the most vulnerable of our users, and studies have been done which indicate they are treated more harshly and with less respect than more experienced users. Users who wish to block new users should go through the same vetting procedure as full admins - as such, I see no value in unbundling this tool. SilkTork ^{✔Tea time} 08:36, 29 March 2013 (UTC) reply
23. If I trusted someone to block accounts with <100 edits, I would likely support an RfA. ErikHaugen ( talk | contribs) 15:29, 29 March 2013 (UTC) reply
24. Oppose. We already have a big enough problem with too few new editors and too many retiring editors. This proposal could potentially help some problems, but I can also see the potential for too much Newcomer biting. Useight's Public Sock ( talk) 17:00, 29 March 2013 (UTC) reply
25. Oppose per Fluffernutter, Silktork, others. Block is the last thing I'd unbundle. If I trust you with block, I'll support you at RfA. Kilopi ( talk) 11:32, 30 March 2013 (UTC) reply
26. Strong oppose. This is the absolute last userright I'd unbundle. Wizardman 15:08, 30 March 2013 (UTC) reply
27. Oppose: The way I understand this proposal, there's this user whom the community does not want to give the full admin tool package to (perhaps because they're not experienced enough/trusted enough), but they are given the tools to block any editor or overturn any block put in place by an admin (or even a CU)? The block button is probably the one tool that can cause the most damage to the project if misused, and the one that should have the strictest vetting process. It's not something we can just hand out; the amount of potential crap-hitting-the-fan scenarios is immense. Chamal  ^{T• C} 19:46, 30 March 2013 (UTC) reply
28. Strong oppose This just seems like a really bad idea. Seriously...we want to give just the block-unblock right to certain people when they apply? I understand that we want to allow more editors the ability to take some of the burden of admin, but this seems like it would create more...a lot more work for them. I can see the wheel wars now.....-- Amadscientist ( talk) 07:38, 31 March 2013 (UTC) reply
29. Oppose per SmokeyJoe. Spencer ^{T♦ C}
30. Oppose I do not see how an editor could adequately assess the record of an alleged vandal without having access to previously deleted edits, which might have been vandalisms or could just have been errors due to inexperience; particularly if we are talking about blocking editors with <100 edits. And allowing "barefoot doctors" the ability to undo CU blocks worries me.-- Anthony Bradbury ^"talk" 21:47, 1 April 2013 (UTC) reply
31. Oppose per concerns above. I'm against most unbundling of rights, especially this one. Vaca tion 9 21:37, 2 April 2013 (UTC) reply

Neutral for "Limited block/unblock", and Discussion

1. Comment I notice this is listed as block/unblock. Is this meant to be block only? The unblock part seems worrying to me unless it only applies to users blocked with the limited block and not those blocked by full admins. Also will there be a limit on duration of blocks, especially those imposed to dynamic IP addresses? Will this become a required stepping stone to full adminship even if not intended to be? I can easily see people !vote in RfA for users that haven't tried for this right first similar to how someone without admin is unlikely to pass an RfB. Anyone that has already been blocking people is going to have more enemies when they run for admin, which might lead to more blockers for the easy vandalism cases but fewer admins for other issues and sleeper vandals ( who will wait for edit 101+ to reveal themselves ). PaleAqua ( talk) 00:43, 28 March 2013 (UTC) reply

   Block and unblock, but only of IPs and very new accounts. Duration of IP blocks is largely limited by policy, but indef blocking of new vandalism only accounts is routine and very rarely contentious. As for this being a stepping stone to full adminship, I see this as giving a tool to those active hugglers whose AIV reporting is flawless but whose lack of content contributions means they cannot pass RFA. Nothing of course stopping one of these editors from actually creating content and going for full adminship, but we have had a number of good vandalfighters who just wanted to do that, and this proposal would give them the tool they need without them being able to block content creators. Ϣere SpielChequers 21:42, 3 April 2013 (UTC) reply

2. Neutral I like the idea of un-bundling admin rights, and block could certainly be unbundled. However, I'm concerned with the tendency of Wikipedians to label problem behavior has vandalism when it really isn't, and I think its in large part because the process for dealing with vandalism is much simpler then trying to deal with other problem behavior. Semi-automated warnx4, semi-automated report, blocked. By assigning only the block tool, and saying its only for clear vandalism, we place the user in a situation where they can only solve the problem if they label it as vandalism, and will lack the tools to do so if they don't. I think it is dangerous to put users in that position, particularly if we don't first do more to try and address the over expansive classification of edits as vandalism. Monty ₈₄₅ 14:52, 4 April 2013 (UTC) reply
3. Neutral I think 'unbundling' is a good idea in principle but am not sure how this will work in practice. The ability to block is a powerful tool and shouldn't be handed around like rollback or reviewer rights. Will the right be software enforced? Regardless of my concerns, I think this is a thought in the right direction.-- regentspark ( comment) 23:19, 4 April 2013 (UTC) reply
4. Undecided: I think block/unblock should be its own separately-granted permission, but feel that this particular proposal is too limited. So I can't decide whether to support with the view that actual implementation could change, or oppose because it doesn't do enough. Also, does the 100 edit check happen automatically or is it the responsibility of the pseudo-admin to check a user's edits? — Bility ( talk) 00:59, 5 April 2013 (UTC) reply

The closers were asked on the talk page to add this proposal from Round Two to Round Three, and we can go along with that. We didn't add it initially because it had more opposition than the two proposals above, and because the supporters are a bit divided on what the proposal is. Some are looking for a probationary period for all admins, and some are looking at this proposal as a way to boost the throughput at RfA by allowing some borderline candidates (with 65% to 75% support, perhaps?) who wouldn't otherwise pass to pass conditionally, subject to some simplified reassessment or recall procedure for a period while they're on "probation". Please read the proposal and the discussion from the talk page of Round Two, and feel free to support, oppose, or agree in part and disagree in part. - Dank ( push to talk) 18:39, 30 March 2013 (UTC) reply

Note: since most of the supporters below support probation for all candidates, I'll assume that unless a supporter says otherwise. - Dank ( push to talk) 18:06, 31 March 2013 (UTC) reply

Support Probation

1. Support All candidates passed by 'Crats using current RfA process & criteria. 3-4 months probation. Final approval method: simple confirmation !vote. Complaints during probation to WP:AN. Leaky Caldron 18:47, 30 March 2013 (UTC) reply
2. Support - I could support either version of the proposal, but I prefer the arrangement in which all successful RFA candidates are deemed to be in probation for the first 3 months or so. Much of the opposition to RFAs can be summarized as "we can't be sure how this person will handle the tools", and I believe some such opposition would be avoided if !voters knew that there would be a probation period during which time the new admin's work would be subject to extra scrutiny -- and at the end of which time that new admin could be undramatically desysopped if they didn't work out. Some of the implementation details of this scheme would need to be worked out by the 'crats. I prefer to apply this to all new admins, rather than just to borderline cases, because I believe that the "all new admin" option has greater potential for reducing the negativity/nastiness that can make RFA so unpleasant -- and that deters some potential candidates from standing for adminship. Probation should not, however, apply to candidates for re-sysopping, since we already know how they handle the tools. -- Orlady ( talk) 19:07, 30 March 2013 (UTC) I do not like the idea of a reconfirmation !vote at the end of the probationary period. Comments on the performance of the probationary admin could be posted on a talk page throughout the duration of the probationary period, and a decision on termination of a probationary adminship should be left to the 'crats, based on their review of the comments and the new admin's record. A second !vote would only have the effect of prolonging the agony of the RFA. -- Orlady ( talk) 19:23, 30 March 2013 (UTC) reply
3. Support - This seems like a better approach than the not unless above as it leaves the choice to the community. Some care is probably needed in tallying the confirmation !vote as admin's by nature will make enemies just by doing exactly what they are supposed to be doing. It might be good to not visibly display an admins status as being probationary except in the RfA result itself, as it might encourage people using that status as a threat against them. I.E. "Do this or I will vote against confirmning you." PaleAqua ( talk) 19:10, 30 March 2013 (UTC) reply

   Reading though some of the round two comments and Orlady's above, I'm switching from neutral to support for the all RfA. As for resysops. If someone was forcibly desysoped because of some issue I think they too should be under probation after passing. If someone is voluntarily rerunning to reconfirm community faith than I don't think it is necessary. I also agree with the concerns on the second !vote. PaleAqua ( talk) 19:26, 30 March 2013 (UTC) reply

   My opinions on the questions I listed below to define how I see this proposal.

   • I support the general proposal as I think it is a way to decrease drama, as the core of this proposal is to a reduce the drama of the RfA process to encourage those afraid to try, and allow those that the community has faith in but uncertainty about how they will behave to be supported.
   • Who? I think it should apply to all RfA ( except for voluntary reconfirmations and optional RfA to dispute an unsuccessful probation close ), otherwise it means that there will be a temptation to play games with !votes based on the threshold.
   • Should the pass threshold be lowered? Definitely not. The way I see this working is by giving people that have reason to trust the candidate but unsure of experience more confidence in voting support. If this reduces some of the drama it will also bring more candidates to consider running.
   • Should previous admins get probation? Yes unless they are running voluntarily for reconfirmations. If a former admin has lost the communities trust they will need to prove themselves again.
   • How does probation end? I prefer the shorter duration of 3 months as that should be enough time to judge their performance and any feed back provided. A 'crat should then either pass them, ending the admin or desysop them. Likewise in the case of issues during the probation period they can be desysoped by a 'crat. ( This is mostly the same as the proposal with a shorter time frame than the 3-6 months, I also think it should have a defined end, without extensions. ). I would though add the option to an admin that got desysoped this way the option to immediately open an second RfA for community input ( with the option of being snowball closed oppose if necessary ) just to have a clear process of how to deal with those cases where they dispute the 'crat's decision. In borderline cases, the 'crat should still desysop, but should note that the close is borderline and suggest an tenure RfA in that case. I also think that if an admin under probation does not do any admin type working during that period ( with exceptions for cases like West.andrew.g run which was an RfA just because there wasn't a way to vote separately just for read deleted bits ) that should also be grounds to fail probation and be desysoped.

   Other thoughts: The goal of prohibition should not be passing bad candidates and then weeding them out. It should be allowing those on the cusp on readiness to prove themselves. If someone is going to be playing games by waiting for probation to end to mess around, it is not a new problem. Sleepers currently just have to hide until a successful RfA. This proposal does not seem to limit other ways to deal with misacting admins. PaleAqua ( talk) 05:54, 3 April 2013 (UTC) reply

4. Support - For all candidates, 3-6 month period, at end of the period a bureaucrat can close as successful/unsuccessful or in borderline cases request community input before making final decision.-- Staberinde ( talk) 19:46, 30 March 2013 (UTC) reply
5. Support. This has a lot of potential to help, especially with respect to borderline candidates. Everyking ( talk) 17:30, 31 March 2013 (UTC) reply
6. Support per the other supporters. Nothing more to add really. — This, that and the other (talk) 11:31, 1 April 2013 (UTC) reply
7. Support for borderline candidates. Some of the oppose !votes pointed out that a truly dedicated rouge admin can simply wait out the probationary period before going mad however making them jump through hoops for a few months is likely to discourage them. Regardless, if someone really wants to act nice and get adminship to mess things up they'll do it regardless of probation. Cabe 6403 ^{( Talk• Sign)} 08:29, 2 April 2013 (UTC) reply
8. Support to a large degree. If a candidate passes with a 80-100% accept rate, then this is definitely not required. If a candidate is considered to be a good one, but too inexperienced, and that the majority of opposes/neutrals are based on this fact, then a 3-6 month flexible period of probation is a good idea. This wouldn't stop rogue admins, but nothing would, and if rogues get into ArbCom, as they have, well, that says enough. It would be a very useful tool to use as a training period for those lacking in experience. I would also support it for all resysops, with the exception of those that were desysopped due to inactivity, or someone hacking their account - if the re-application was successful, then they should be fine. Lukeno94 (tell Luke off here) 19:27, 2 April 2013 (UTC) reply

Oppose Probation

1. I don't see any major difference between this and the "Not unless" proposal above. It's just a matter of when the easy-to-game probation period occurs, before or after the bit is granted. ~ Amory ( u • t • c) 21:11, 30 March 2013 (UTC) reply
2. This proposal is far too jumbled and open-ended to really have any value. Supporting some sort of probation, on some sort of people, where the rights can be removed if they do this one thing, but maybe that thing, not this thing, but possibly that other thing, and generally waving our hands in the general direction of "someone ought to watch new admins or something" without actually defining anything, just doesn't give us anything to work off of. I'm neutral on whether the issue of probation is worthy of voting on, I suppose, but I'm strongly opposed to this version, which would have us pass something while defining nothing. A fluffernutter is a sandwich! ( talk) 21:49, 30 March 2013 (UTC) reply
3. Strong oppose- If an admin needs to be placed on probation, then we made a mistake by giving him admin rights in the first place. If we create this policy, then people will feel more inclined to make "mistakes" at RFA. We need to be sure of the people we are electing. I do acknowledge that RFA has a few problems due to its strict nature as of late, but the potential bad outcomes of this proposal far outweigh the good. Feed back ^☎ 22:36, 30 March 2013 (UTC) reply
4. Oppose. This is sounds like recall for new admins. The recall process is not defined. It is easy to be on good behaviour for a few months. I don't know of any case where a fresh admin was immediately and unteachably bad. If there is no reconfirmation vote, then apply the recall process to all admins. Ultimately, I don't think this is a solution to the problem of few candidates. -- SmokeyJoe ( talk) 23:14, 30 March 2013 (UTC) reply
5. Not until the de-sysop process is defined, far too open ended. Otherwise a decent idea. RxS ( talk) 04:33, 31 March 2013 (UTC) reply
6. Oppose This really does nothing to help how difficult or impossible it is to remove and Admin if they later turn out to be unsuitable. Someone really unsuitable will keep their nose clean and then freak out later. It just doesn't seem to answer any real need.-- Amadscientist ( talk) 07:42, 31 March 2013 (UTC) reply
7. Oppose Even the supporters don't seem to know what we're voting for here. It's either (1) All candidates, (2) Some candidates, or (3) for reconfirmation RfAs. Add on that it might be that either (a) the bureaucrats move the admin out of probationary status or (b) the community votes again. This proposal is dead on delivery as to vague to fly any better than a lead duck. -- Hammersoft ( talk) 12:51, 1 April 2013 (UTC) reply
8. Oppose - Any such proposal is too easily gamed. If a candidate squeaks through on a probationary adminship, then all they need to do is be extra careful not to get into anything that is remotely controversial during their probationary period. In other words, what we see during the probationary period won't necessarily resemble what we see after it. ‑Scottywong | yak _ 19:46, 1 April 2013 (UTC) reply
9. Oppose An editor is either trustworthy in the eyes of the community, or s/he is not. If we do not have enough admins then the right thing is to review RfA (yes, I know I am not the first person to say that) not to produce a sub-group of semi-admins.-- Anthony Bradbury ^"talk" 21:53, 1 April 2013 (UTC) reply

   The proposals on this page are the product of a 3 month RfC / review on RfA. Probation has nothing to do with producing a sub-group of semi-admins, whatever they are. It is more likely that they would be the product of either of the other 2 proposals than this one. Probation is merely a way of ensuring satisfactory performance in the job during the initial period, no bad thing for a job for life and one of the reasons why RfA standards are so high. I cannot see standards being lowered until a way is found of reducing risk. Probation would be a small, simple step. Leaky Caldron 09:18, 2 April 2013 (UTC) reply

10. Oppose If crats see fit to do this, at their discretion they can feel free. However, I am strongly against making this policy. As Anthony said above, a user is either trustworthy, or they are not. A probationary period would mean yet another threshold, more work for the crats, and a feeling of eliteness between admins who passed with no opposition, and admins who were "put on probation" when they were promoted. In short, no. Vaca tion 9 21:40, 2 April 2013 (UTC) reply
11. Oppose if this would involve giving people the ability to delete articles before they had a full RFA. There is also the practical issue that turning RFA from a 7 day process into something much longer is liable to exacerbate our RFA problems by adding several months of scrutiny to a seven day overly onerous process. If we are going to improve RFA we should target the changes at areas which need reform, and the last time I looked it was admins with three or more years admin experience who were most likely to have drifted away from the community, not new admins. Ϣere SpielChequers 22:51, 3 April 2013 (UTC) reply

    Probation would only begin after the normal ( full ) RfA has run and the candidate has received community support. ( this is not the limited tool apprenticeships that I proposed in RfC 2 ). For most cases there really wouldn't be much extra to do during the months of probation, if an new admin causes or has problems it will be noticed otherwise it will just be an 'crat checking a tenure box that says yep this admin had no problems, no feedback of valid issues, and seems to have performed well as an admin. It serves a similar purpose as your "not unless" proposal with the difference being were the judgement is made in giving the tools. In the probation case, the tools require an RfA to pass, and it works by allowing !voters that would have borderline opposed to support knowing that if the newly minted admin majorly goofs it can be dealt with easily. Whereas the "not unless" case which requires 'crats to both judge which opposes are really not unless, and to watch the candidate to see if they meet those qualifications. PaleAqua ( talk) 23:18, 3 April 2013 (UTC) reply

12. Oppose unless it was strictly limited to candidates who would not have passed RFA but for the availability of the probationary period. Also, the current standard amongst voters at RFA, as I understand it, is that a candidate should have enough experiance to demonstrate that we can trust them, and that they understand the policies in at least the areas of admin work they are going to undertake. If they do really have our trust, and do really understand the policy in an area, they should be fully qualified to act even in potential controversial situations. That is not to say we want new admins going Rambo in an area they are unfamiliar with, but telling them to specifically avoid controversy during your probation is basically telling them to game the probation period. Monty ₈₄₅ 15:40, 4 April 2013 (UTC) reply
13. Oppose: All admin, regardless of time in service, should be available for recall if the community wants it. All this proposal does is extend the time a candidate is on their best behavior to three months after passing instead of right after passing. It also requires monitoring and/or review and this proposal doesn't say with whom that responsibility lies. — Bility ( talk) 08:24, 5 April 2013 (UTC) reply
14. Oppose We should be aiming to simplify the process, not complicate it. -- regentspark ( comment) 09:53, 5 April 2013 (UTC) reply

Neutral for Probation, and Discussion

1. I was originally going to oppose, but upon thinking about it, there are users who should get the tools but people oppose due to concerns of not being completely ready. Adding this in could let them become admins without going through the drama a second time. Might be one to think on. Wizardman 03:50, 1 April 2013 (UTC) reply

Discussion

It seems a lot of the concerns on probation is exactly what the proposal is. Should the vote be split up something like?

• Is the concept of probation worth pursuing? ( Support / Oppose ) -- If this one is opposed other votes in this sections won't matter
• Who should be considered for probation ( Borderline cases / All )
  • Should borderline cases include those that would not pass under current guidelines ( i.e. lower percentage ) ( Keep the same / Given 'crats more leeway )
• Should previous admins get probation ( Yes / Only if forcibly desysoped / No )
• How does probation end ( Feedback collected during probation with 'crat judging / Simple !vote / Other )

By defining the proposal it seems like it might deal with the concerns. PaleAqua ( talk) 16:17, 1 April 2013 (UTC) reply

Yes. Might deal with them. Might better illuminate them either way. -- SmokeyJoe ( talk) 11:23, 2 April 2013 (UTC) reply

The proposals on this page are the product of a 3 month RfC / review on RfA. Probation has nothing to do with producing a sub-group of semi-admins, whatever they are. It is more likely that they would be the product of either of the other 2 proposals than this one. Probation is merely a way of ensuring satisfactory performance in the job during the initial period, no bad thing for a job for life and one of the reasons why RfA standards are so high. I cannot see standards being lowered until a way is found of reducing risk. Probation would be a small, simple step.

Leaky Caldron's (09:18, 2 April 2013 (UTC)) post reads like wishful thinking that could be faulty on multiple points. The simplest problem is that the proposal is too undefined for it to be reasonable to be voting on it. For me, if probation does not involve a reconfirmation or formal recall mechanism, then it is lip service, of no substance, and a route to let unsuitable candidates through. If it does involve a formal recall mechanism, then why not have it apply to all admins? I am also still confused as to why this proposal apparently aimed at lowering criteria for adminship is being championed by someone who says on his userpage "This user feels that criteria for adminship are generally too low".

Also, probationary adminship is not the product of the last three months. I remember discussing it at Wikipedia:Requests for comment/Wikipedia:Requests for adminship in 2007. The biggest difference is that this time (1) we are voting on something and (2) it is less defined. m:Polls_are_evil. -- SmokeyJoe ( talk) 11:23, 2 April 2013 (UTC) reply

It's not faulty on any point, any more than is your crooked reading of it, the recent "3 month" background of the current proposal or the content of my user page. The proposal says nothing about lowering RfA criteria, if it did I would be the first to oppose it. Leaky Caldron 16:22, 2 April 2013 (UTC) reply

If probation is not supposed to let lower scoring candidates through, then what is it for? Are there past successful candidates that would have benefitted from a probation period? -- SmokeyJoe ( talk) 21:11, 2 April 2013 (UTC) reply

The pass level would not change. The RfA process would not change. My personal judgement, for example, would not be compromised. What might happen is that some marginal opposes/neutrals might switch to support. Is that a lowering of scores? - not in my opinion. All this does is allay the concerns that some candidates get a job for life on the basis of fan-based, or otherwise policy thin knowledge can have a few months in the role to ensure that they are, indeed suitable. This has nothing to do with the bad faith assertions made by some that this is somehow gameable or that rogues would stay under the radar. Utter nonsense. It is a period during which the community's selection can be seen in action, leading to approval in probably 99% of cases. It would lead to more successful candidates if waivering supporters felt the candidate could be removed if necessary. It's a safety blanket - nothing more. Leaky Caldron 21:59, 2 April 2013 (UTC) reply

OK, thanks. That's making more sense to me.

What is the recall procedure for a failing probationary admin? Why shouldn't we just apply that same recall procedure to all admins? -- SmokeyJoe ( talk) 22:46, 2 April 2013 (UTC) reply

Well as quite correctly pointed out, the detail has not been worked out and opinion among supporters is divergent which is likely to prove a deal breaker, despite the indicative support in phase 2. I had favoured a reconfirmation !vote but I'm persuaded that unless valid issues are brought up during the probation period it is simply made permanent automatically at probation end. I don't think it should be applied retrospectively - candidates should know the basis of their RfA when they apply. Recall of existing Admins is way too controversial and would seriously cloud the simple issue here which is that introducing a probation period for new Admins might increase success rates for some of the marginal candidates and offers a way out for the community is a candidate gets through who is unsuitable early (rare). Leaky Caldron 08:11, 3 April 2013 (UTC) reply