Jump to content

Wikipedia:Requests for adminship/2013 RfC/3: Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
Oppose "Limited block/unblock": SmokeyJoe took the words right out of my mouth. Bad idea
Line 48: Line 48:
#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. '''''[[User:AutomaticStrikeout|<span style="color:#00008B;">Automatic</span><span style="color:#FFA500;">Strikeout</span>]]''''' <small>([[User talk:AutomaticStrikeout|<span style="color:#00008B;">'''T'''</span>]] • [[Special:Contributions/AutomaticStrikeout|<span style="color:#FFA500;">C</span>]] • [[WP:AAPT|<span style="color:#00008B;">AAPT</span>]])</small> 02:54, 28 March 2013 (UTC)
#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. '''''[[User:AutomaticStrikeout|<span style="color:#00008B;">Automatic</span><span style="color:#FFA500;">Strikeout</span>]]''''' <small>([[User talk:AutomaticStrikeout|<span style="color:#00008B;">'''T'''</span>]] • [[Special:Contributions/AutomaticStrikeout|<span style="color:#FFA500;">C</span>]] • [[WP:AAPT|<span style="color:#00008B;">AAPT</span>]])</small> 02:54, 28 March 2013 (UTC)
#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. [[User:Fluffernutter|A fluffernutter is a sandwich!]] ([[User talk:Fluffernutter|talk]]) 02:57, 28 March 2013 (UTC)
#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. [[User:Fluffernutter|A fluffernutter is a sandwich!]] ([[User talk:Fluffernutter|talk]]) 02:57, 28 March 2013 (UTC)
# SmokeyJoe took the words right out of my mouth. Bad idea...[[User:RxS|RxS]] ([[User talk:RxS|talk]]) 04:01, 28 March 2013 (UTC)


===Neutral for "Limited block/unblock", and Discussion===
===Neutral for "Limited block/unblock", and Discussion===

Revision as of 04:01, 28 March 2013

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]

"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"

  1. 'Support' Conditional 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)[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 (TCAAPT) 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]

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]

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]

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 VTalk 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]
  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 (TCAAPT) 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]

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]