Jump to content

Wikipedia:Requests for adminship/2013 RfC/3

Add links
From Wikipedia, the free encyclopedia
< Wikipedia:Requests for adminship | 2013 RfC

This is an old revision of this page, as edited by RxS (talk | contribs) at 04:33, 31 March 2013 (→Oppose Probation: Not until the de-sysop process is defined. Otherwise a decent idea). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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]

"Not unless"

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]

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. Feedback ☎ 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. Cabe6403 (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]

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]

Limited block/unblock

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. — nerdfighter 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 deckertalk 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]

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. --Rschen7754 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. Feedback ☎ 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? Cabe6403 (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]

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]

Probationary period for (at least some) new admins

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]

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 for borderline cases / Weak support for higher % - 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]
  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]

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. Feedback ☎ 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]

Neutral for Probation, and Discussion
Retrieved from "https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia:Requests_for_adminship/2013_RfC/3&oldid=547932025"