Wikipedia talk:Moderators/Straw poll

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Before commenting, please read the proposal thoroughly.

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.


RfC[edit]


Support[edit]

  1. Support as an excellent way of helping in understaffed areas. It's all very well saying the RfA process should be improved, but nothing has worked so far. StAnselm (talk) 22:07, 8 July 2016 (UTC)[reply]
  2. Moral support. I know from history and experience that a proposal of this magnitude stands no chance of passing, so this support will have no real effect. But on the idea itself, I must respectfully disagree with those who oppose this proposal (one of whom is a fellow member of the reform WikiProject). The popular sentiment is that we should work to improve RfA, but RfA cannot be meaningfully improved. Even the reforms that were passed last year have failed to remedy the basic hostility and sheer unreasonableness of the process. Even clerking, which in past years was hailed as the most needed reform, did not fix the process. (It doesn't make any difference that only bureaucrats were to do the clerking. Clerking is clerking.)
    RfA is steadfastly and hopelessly resistant to any form of radical overhaul—I have learned that from experience. And since there is always fierce backlash from rabid oppose voters, the process has the tendency to blunt any other reforms given enough time. In addition, editors are currently under the impression that we have enough admins and that there is no sense of urgency, even though the number of overall admins (and also active admins in particular) continues to steadily erode—desysoppings far outpace promotions, and it is evident that long-term admins continue to slowly drift away from activity. These things have led me to the conclusion that RfA will never be improved at this time. But soon enough, there will be so few promotions that the process will become worthless and de facto historical, and the steady attrition will be clearly visible. We are rapidly nearing that point; at our current rate, we are set for a promotion decrease of approximately 33% this year, and the number of months with no promotions continues to increase. When this urgent situation finally arrives, there may be some emergency measures passed to overhaul the system, although even that is not certain—the stubbornness of the deeply entrenched anti-reform faction may very well lead to the complete demise of the process. So due to the hopelessness of RfA, I have ended all efforts to reform it, and I have become a wholehearted supporter of unbundling. That is the reason I am supporting this proposal. Biblio (talk) WikiProject Reforming Wikipedia. 23:17, 8 July 2016 (UTC)[reply]
  3. Support It's all very well saying we need to improve RFA, but how has that been going these last several years? Johnbod (talk) 02:21, 9 July 2016 (UTC)[reply]
    And how is this going to improve RFA? It's just another process that, quite frankly, will have the opposite effect. -- Tavix (talk) 19:26, 9 July 2016 (UTC)[reply]
  4. Moral Support I can easily see some editors that would be useful to the project that would not want to have the even the possibly of being able to block/unblock someone. I know that's one of the reasons I'd never want to try to be an admin myself. I do have some concerns about the name but as this is currently unlikely to pass will leave it at that. PaleAqua (talk) 02:50, 9 July 2016 (UTC)[reply]
    1. I still have concerns with a double RfA process that could turn into a two stage admin barrier which would be counterproductive. PaleAqua (talk) 21:03, 7 August 2016 (UTC)[reply]
  5. Support Since most editors seem to agree that RfA is broken, I see no reason to not start testing new solutions asap -FASTILY 06:14, 9 July 2016 (UTC)[reply]
  6. Support As a way of allowing editors who don't want to deal with conduct (and who some members of the community don't trust to deal with conduct) it sounds great. Yes it inherits some of the problems of adminship (RfA-type problems and involuntary removal hurdles) but at least it will help us deal with some of backlogs in this area, and give appropriate tools to those who will and can use them. I'm not wild about them being able to use revision deletion since it's mainly used to deal with behavioural issues (BLP etc), but I can see why it's been included given the need to clean up copyright vio stuff. Callanecc (talkcontribslogs) 14:00, 9 July 2016 (UTC)[reply]
  7. Support. I've proposed this myself before. Should reduce backlogs, allow for some potential future admins to get experience, reduce time wasted by so many at RfA. Many advantages, little or no drawbacks. Big net gain for WP. --A D Monroe III (talk) 15:18, 9 July 2016 (UTC)[reply]
  8. Weak support on the condition that such an appointment for moderator isn't lifetime. RfM should have intentionally low standards, with an appointment of up to 1 year. This should allow more editors to pass as moderator, by limiting the amount of damage they can perform with the tools. It also can limit the potential increase in RfA standards by requiring all editors wanting lifetime appointment to run for RfA. I've said that a way to solve the high standards of RfA is to make removing tools easier, because the community would be more willing to pass editors at RfA if they know they are able to remove their tools easily if they run amok. SSTflyer 15:36, 9 July 2016 (UTC)[reply]
  9. Weak Support - Not completely sure about this, but at current RfAs, which we all agree are fraught and could use improvement in some way, there are some clear groupings of opposers. Two of the big ones are (a) opposes for deletion-related concerns, (b) opposes based on concerns over judgment, and insufficient experience in particular matters necessary to demonstrate good judgment. The real selling point of this proposal to me is that while (a) and (b) would both remain part of the RfA process, this proposal would in some ways assuage the concerns of (b). For example, several people oppose candidates who do not have much experience with content creation. On one level, there is the philosophical argument "you should have experience writing an encyclopedia before you have power over the encyclopedia". On another level, however, there's the judgment-related worry that "if you don't have experience laboring over an article over a long period of time, taking it through the various processes on the improvement path, then you aren't qualified to act in an admin capacity in disputes in those spaces." It's a controversial, but very real concern that comes up again and again. Divorcing deletion may allow people with such concerns to support granting tools. All of this said, I do have significant reservations. First, it seems like it would be really difficult to implement, and second, it creates another place of strife with the same problems as RfA without doing anything to change the process. — Rhododendrites talk \\ 15:45, 9 July 2016 (UTC)[reply]
  10. Support per Fastily. Enterprisey (talk!(formerly APerson) 19:11, 9 July 2016 (UTC)[reply]
  11. Support – If it fails horribly, we can get rid of it, but RFA is not working, so we need to change it however we can. KSFTC 23:35, 9 July 2016 (UTC) After reading some of the opposes, I'm no longer convinced that this is the best way to achieve its goal. KSFTC 01:26, 10 July 2016 (UTC) I'm reinstating this support. This might not be the best possible way to fix RFA, but we should try everything we can. KSFTC 02:34, 12 July 2016 (UTC)[reply]
  12. Weakest support possible Honestly, I don't think this is a great idea, but I'm not entirely convinced by the opposes and think they haven't properly thought through the proposal (though neither have I). I can understand how this might help editors deal with the non-conduct related things like how page mover or pending changes helps deal with content backlogs, but it seems too much like an "admin-lite" for me to see this being a real solution. If you're going to become a moderator, why not just become an admin considering it's basically the same process just with fewer rights? The only reason I'm not opposing is that I don't think it will cause many problems. As long as it does not involve conduct related rights (block and protect to name the two biggest), I don't think new editors will be very confused, and if they are it will be minimally problematic: point them to AN so an admin can help them (but with this many rights, a moderator probably could help a new user). I'm still pretty on the fence, and will keep thinking, but I'm going to default support unless I am given a reason to think this would be harmful. Wugapodes [thɔk] [kantʃɻɪbz] 23:46, 9 July 2016 (UTC)[reply]
  13. Support Separating file work and user conduct shepherding is a logical idea. In fact, we should establish a corresponding user conduct (block, etc.) class as well, such that the traditional sysop/admin becomes a conglomeration of those two toolsets. Jclemens (talk) 06:16, 10 July 2016 (UTC)[reply]
  14. Moral Support As a form of 'admin apprenticeship'. Maybe the biggest reason RfA is a failing process is that it is simply too big a step for an editor to jump from some fairly harmless enhanced user rights to administrator in one go. It's a big ask of the community's trust. Staggered introduction of admin-like responsibilities, in contradistinction to unbundling all of the admin tools, may be the way forward. However, I notice the huge backlog at WP:UAA and opine that this proposal will do nothing to assist in that area, expect perhaps by proxy if administrators are freed up from other areas. Bellerophon talk to me 20:37, 10 July 2016 (UTC)[reply]
  15. Support - Fully support a limited-time trial of anything remotely reasonable, simply because the alternative is to accept the status quo. If a trial fails after being given a fair chance—without conscious or unconscious undermining by opposers of unbundling—we will have learned something real and tangible, and that experience will inform further attempts to improve things. Those who oppose because it's not their preferred solution would get my support for those trials as well, but we can't trial two things at the same time. In a nutshell, avoid inertia. There is more to gain than to lose. ―Mandruss  07:28, 11 July 2016 (UTC)[reply]
  16. Support. If there are users who want to help out with the content-related side of admining but do not want to deal with the user behaviour-related side (and the eloquent proposal makes it clear there are) then I see no problem with this at all. The standards for access to tools will not be lowered and there is going to be nothing stopping someone who becomes a moderator from later requesting adminship if they wish. Although I don't anticipate this becomming a regular stepping stone to adminship I do not see if as problematic if it does become so. Thryduulf (talk) 09:32, 11 July 2016 (UTC)[reply]
  17. Support. It seems entirely reasonable to want to do content-related closures and help with content related revision deletion, but want nothing to do with blocking users. (I could see myself interested in such work.) Also, it makes sense to have an additional level in which future administrators could learn skills and discretion without jumping into all roles at the same time.--Carwil (talk) 20:08, 13 July 2016 (UTC)[reply]
  18. Weak support I just moved here from oppose. The community has agreed on several occasions that RfA is a terrible process. With the number of active sysops at an all time low, backlogs are disgustingly high. I'm not supporting this because I like the idea, I'm supporting because I know that this is definitely a way to make "becoming a sysop" less terrible. If RfA never ends up being fixed, this is the only solution. I know so many users who are in the anti-vandalism field, and I really think this will end up being useful. Music1201 talk 00:35, 19 July 2016 (UTC)[reply]
  19. Support As stated in previous arguments, 'moderator' and 'admin' are tasks that may appeal to two different types of people. Let's encourage more participation in the work that needs to be done on Wikipedia.ABF99 (talk) 13:46, 23 July 2016 (UTC)[reply]
  20. Support I always wanted to be able to do good things, without having to deal with editor related problems. Debresser (talk) 18:57, 23 July 2016 (UTC)[reply]
    Administrators aren't required to use the tools to "deal with editor related problems", nor does the community expect all administrators to participate in that aspect of the work, as can be shown by Tavix's recent RfA (i.e. their answer to Question 1).Godsy(TALKCONT) 19:11, 23 July 2016 (UTC)[reply]
  21. At this point, I'm desperate enough to support virtually anything that in any way circumvents or undermines the hopeless idiocy of the RfA process.—S Marshall T/C 14:40, 24 July 2016 (UTC)[reply]
  22. Support to reduce admin backlog and free deserving wikignomes to do the work they enjoy - Reidgreg (talk) 14:48, 25 July 2016 (UTC)[reply]
  23. Support to help reduce backlogging and have more people help out on Wikipedia so that it stays great for years to come! AnAwesomeArticleEditor (talk) 15:40, 25 July 2016 (UTC)[reply]
  24. Weak/Moderate Support - I think the idea in principle is a good one. Creating this user-right would establish a list of editors that are "globally trusted" on Wikipedia to handle technical processes and backlogs. They would have the ability to perform technical and non-controversial changes (within policy!) that would not directly remove a user's ability to edit Wikipedia (blocking). Many editors may (and definitely do) count the ability to delete and protect pages as direct interference or directly preventing a user from editing, but I think that this may be a good start. The reason that I am supporting on a weak basis is because I feel that the criterion for applying and being granted the user right needs more analysis and criticism. I think that the requirements should be much stronger than that of a normal permission request, but definitely not in the range of requiring an RFA; an appropriate middle-ground must be discussed. ~Oshwah~(talk) (contribs) 03:48, 26 July 2016 (UTC)[reply]
  25. Support with few reservations I support this in theory. However if this is going to have to go beyond an "RFA Process" its not going to work. RFA is broken seeing "Oppose user doesn't have 50,000 edits" or "User has too may edits to User Talk Space" (if you fight vandalism you have a lot of edits to user talk space). "User doesn't have 12 GA's" these are things I have seen in RFA's. So if we don't pass this user right can we focus on fixing the broken process of RFA? --Cameron11598 (Talk) 03:55, 26 July 2016 (UTC)[reply]
    Another example: "in ... the "Wikipedia:" namespace, <user> only has about 900 edits". DexDor (talk) 05:57, 26 July 2016 (UTC)[reply]
  26. Support Let's do, if it's been requested before let's make it happen because it looks like a good way to reduce the backlog. --OMouse (talk) 19:00, 26 July 2016 (UTC)[reply]
  27. Weak Support - I like the idea of unbundling admin responsibilities, but I feel like the screening process should be just about as rigorous as that for admins to make sure nobody abuses these tools. The main part of this that I agree with is the fact that going from regular user to admin is a huge step and this would be a good solution for people who don't want to make such a big leap or have slightly less responsibility. That said, these people, aside from the amount of tools they can use, should be up to the same standards as admins to make sure moderators don't abuse/over-use their powers. Gpapazian (talk) 23:27, 27 July 2016 (UTC)[reply]
  28. Strong Support This allows greater specialization and division of labour, thus enabling Wikipedia to be the best it can be. Emir of Wikipedia (talk) 14:24, 29 July 2016 (UTC)[reply]
  29. Support. Content-related tasks are distinctly different from actions regarding individual users. Moderators would be able to spend more time working with actual content, because they would not have to deal with troublesome users like administrators must. I imagine that a moderator would be about 80-90% of an administrator from a qualifications standpoint: moderators would still be well-qualified, just not on the level required for the additional administrator responsibilities. Mooseandbruce1 (talk) 00:30, 30 July 2016 (UTC)[reply]
  30. Strong support - though I do share a concern about the name. To me, the core admin ability is in dealing with editors. Splitting out the article work seems wise to me. As the project continues to grow, it is both going to be harder and harder to administer and quite frankly harder to find enough people trustworthy enough to perform the various tasks. One user opposed saying "fix the RfA process"... no, it is not the process, it is the egalitarian nature of WP. The RfA process has problems, and they are painful, but they are good problems. Every candidate we trust with the full admin package is quite powerful. And we will likely never know them... only their edits.Shajure (talk) 05:50, 30 July 2016 (UTC)[reply]
  31. Weak support I don't think this will be particularly helpful in achieving it's stated goals, but it won't hurt either. To really be useful this would have to have a lower standard than RFA, but of course OFFICE has made clear that's not in the cards. If a responsible user only wants a subset of the tools, why stand in their way. Xymmax So let it be written So let it be done 16:28, 30 July 2016 (UTC)[reply]
  32. Support. As I read this proposal, I knew it would fail. RFA is broken, and any proposal to make it a simpler, easier process is always shouted down. So I knew when I saw a proposal to unbundle some of the admin tools, the likely outcome would be that it wouldn't pass. The project is dying a slow, preventable death--a slow, status-quo suicide. Hallward's Ghost (Kevin) (My talkpage) 06:39, 31 July 2016 (UTC)[reply]
  33. Support Acalycine (talk) 12:58, 31 July 2016 (UTC)[reply]

Oppose[edit]

  1. Strong Oppose per the last time this was discussed and failed miserably, and I agree with the opposition from that discussion. Instead of creating yet another usergroup, we should be making the RFA process better. If someone is trusted enough to be a "moderator," they should be trusted enough to be an "administrator." I actually think this would create the effect of making the RFA process even more of a big deal than it already is, and we need to be doing the opposite. -- Tavix (talk) 21:55, 8 July 2016 (UTC)[reply]
    The "last time" that you link to was done as a way for admins to "step down", with many opposing because they wanted this open to everyone to request. And I already noted in the proposal about not forcing tools on people because "we" decide they "must" have all or none. So I won't further restate that here again... - jc37 22:03, 8 July 2016 (UTC)[reply]
    Adminship is about trust. I don't understand why we'd be able to trust people with some things and not others. I requested adminship because I wanted the ability to delete redirects, and that's pretty much all I use it for. I have no desire to block people, but I'm still a trusted member of this community should a situation arise where I needed it. Anyone who I would trust for this so-called "moderator" right I would also trust for admin, so this proposal makes no sense to me. -- Tavix (talk) 22:30, 8 July 2016 (UTC)[reply]
    "I don't understand why we'd be able to trust people with some things and not others." That probably needs rewording, otherwise you're saying that everyone who is an autoreviewer should also be an admin, checkuser and bureaucrat. --Slashme (talk) 13:22, 24 July 2016 (UTC)[reply]
    And you're of course welcome to feel that way, but please understand that others may find even merely having the block tool as "uncomfortable". This has been stated in the past many times by other editors. - jc37 22:43, 8 July 2016 (UTC)[reply]
    And they're not required to use them if they're uncomfortable with them... -- Tavix (talk) 23:06, 8 July 2016 (UTC)[reply]
    Unfortunately, many RFA voters won't support someone who only plans to use some of the tools. KSFTC 01:18, 10 July 2016 (UTC)[reply]
    My recent RFA would suggest otherwise. I explicitly stated that I only want to work in deletion and that I have no desire to block people, and I didn't get any opposition based on that. -- Tavix (talk) 02:04, 10 July 2016 (UTC)[reply]
  2. Strong oppose: The only good reason to request moderator rights instead of administrator rights is because it may be easier to pass. It looks like it would be almost as hard or just as hard as RfA as it is a lifetime appointment. In addition, this will complicate our ever-expanding bureaucracy, increasing our six-caste system to a seven-caste system: sandwiching moderator into IP users, registered users, autoconfirmed users, PERM rights, administrators, and bureaucrats. Numerous studies suggest (e.g., doi:10.1145/1641309.1641322, p. 4 & p. 8) that bureaucracy is a major reason why growth is slowing on Wikipedia and why occasional editors are disenfranchised.
      And it would waste more time for the moderator and the community: what if a moderator needs to, for example, block a vandal occasionally, protect a page that should obviously be protected, or even perform simpler tasks such as send a mass message (which is not in the toolkit)? The moderator would have to face a seven-day RfA if they decide they want more advanced rights or request simpler from WP:PERM. Additionally, this will spike hat collecting: administrator, to a newbie, sounds like a system administration or advanced right, while moderator sounds like a three-week right where they only need to submit some application and hope for the best. I also agree with Abraham Maslow's quote: "if all you have is a hammer, everything looks like a nail", except that moderator allows editors to use more hammers on the wrong things. Esquivalience (talk) 21:56, 8 July 2016 (UTC)[reply]
  3. Oppose - not comfortable with moderators being able to delete pages, and agree with sentiment that our work should be to improve RFA. GiantSnowman 22:13, 8 July 2016 (UTC)[reply]
  4. Oppose. The intended effect here is to make it easier to get certain aspects of the admin toolkit, and I fully agree with that goal. I think this will have the opposite effect. RfMs would acquire the RfA level of standards, especially because many of the usual opposes at RfA usually relate to working with content. The bar for RfAs may increase as a result. I don't think this is a solution that would work out. ~ Rob13Talk 22:27, 8 July 2016 (UTC)[reply]
    Please see this - jc37 22:43, 8 July 2016 (UTC)[reply]
    What does that have to do with my arguments against establishing this user right? I figured the WMF would allow this given that it uses the same process, yes. ~ Rob13Talk 22:48, 8 July 2016 (UTC)[reply]
    Perhaps I misunderstood, but I was responding to: "...RfMs would acquire the RfA level of standards..." - in other words, that is alreay required per the WMF. - jc37 22:58, 8 July 2016 (UTC)[reply]
    Ah, I understand now. The WMF is presumably referring to the standards of going under a thorough community review as opposed to something like WP:RFR. I'm referring to the somewhat ridiculous standards with which some editors vote at RfA. For instance, citing a GA as an example of poor content creation. I think it's clear that this proposal hopes to fix the completely real problem of inflated RfA standards, but I think it will have the opposite effect. Does that make sense? ~ Rob13Talk 00:36, 9 July 2016 (UTC)[reply]
    Yes, thank you for clarifying. While I obviously disagree, you are more than welcome to that perspective. I've written at length on this elsewhere (such as here), but imnsho, RfA is what it is due to "community trust" being such a personal and undefined quantity, among other things. YMMV, of course. - jc37 00:55, 9 July 2016 (UTC)[reply]
  5. Oppose While I do see the point of this usergroup, I do think that some of the rights are not warranted. These are: deleterevision, move-rootuserpages and mergehistory. Deleterevision is basically an light version of what oversighters do (or more specifically the suppressrevision right) - it does handle issues like specifing personal information. Move-rootuserpages is a really questionable right for this group in my opinion, after all, user renames are not handled any more on enwiki and I very much doubt that any of the content-related discussion portals have to do with renaming user pages. Finally, mergehistory is questionable in my opinion and I do not see how the mentioned discussion portals handle that kind of issues.--Snaevar (talk) 22:46, 8 July 2016 (UTC)[reply]
    move rootpages is given out to all users. I added it here for MFD closures, and to help newbies if needed. But agreed that it is unnecessary. mergehistory could essentially be done with merely the move tool and delete. delete revision also allosws for viewing a deleted revision, which may be needed when closing a discussion. - jc37 22:58, 8 July 2016 (UTC)[reply]
    Oppose. I am very much in favor of unbundling admin tools, but this proposal gets it exactly backwards in terms of what should be unbridled and in which order. In my opinion, closing XfDs is among the most nontrivial admin tasks. I believe that granting access to the "delete" button requires a high degree of community trust and should always require some form of a confirmation process similar to RfA. We cannot start giving out this right in a way similar to rollback, with some possible narrow exceptions (e.g. the ability to delete expired non-BLP prods). On the other hand, I do think that granting experienced users the ability to issue short-term blocks to IP vandals and to set certain kinds of low levels of protection settings, under some clearly defined sets of rules, can be done in terms of new user-rights, similar to rollback, easily granted, and easily removed. But this proposal strikes me as exactly the wrong way to go about unbundling the tools. Nsk92 (talk) 22:50, 8 July 2016 (UTC)[reply]
    This isn't available to be given out "like rollback". Please see this. As for a blocker userright package, please feel free to propose that : ) - jc37 22:58, 8 July 2016 (UTC)[reply]
    OK, I see, thanks. I admit that I misread the proposal. I was thrown-off by the sentence "The request may obviously coincide with a request for one or more admin-granted tools, such as rollback." I have crossed out my vote as I need to reconsider this proposal from scratch. Nsk92 (talk) 23:21, 8 July 2016 (UTC)[reply]
  6. Oppose per WP:PERRENIAL. I'm in favor of such an idea on paper, but honestly I think the status quo of having some rights unbundled rather than having a "junior admin" userright works. Narutolovehinata5 tccsdnew 23:16, 8 July 2016 (UTC)[reply]
  7. oppose mostly as I don’t see what this would solve, only it would introduce another layer of bureaucracy which we don’t need. The idea that deletion is somehow less important, and so can be granted to editors with a lesser degree of trust than admin rights, is I think misplaced. Deletion is arguably the most dangerous tool in an admin’s toolbox as it’s so final. Blocks and page protections are temporary except in rare cases, and straightforwardly challenged and reversed. But deletion and related processes like rev-del are much more final: even our processes to reverse them such as deletion review are difficult by design.--JohnBlackburnewordsdeeds 23:25, 8 July 2016 (UTC)[reply]
  8. View deleted revisions? Nope. No way. Absolutely not. This is a very privacy-sensitive right and I would even call it second admin right on importance scale, right after blocking. I'm absolutely agains lowering requirements for getting it. As of the whole moderators idea, can we stop kicking the dead horse already? It's been demonstrated multiple times that we don't want this, why not concentrate on some alternative measure like RFA reform instead? Max Semenik (talk) 23:36, 8 July 2016 (UTC)[reply]
    If I may ask, where in this proposal do you see a "lowering of requirements"? - jc37 23:49, 8 July 2016 (UTC)[reply]
    @MaxSem: To be clear, moderators would be able to see revisions deleted by admins, not revisions suppressed by oversighters. KSFTC 01:23, 10 July 2016 (UTC)[reply]
  9. Strong oppose. I'll happily support the unbundling of some minor user rights to non-admins, but definitely not something like this. Creating a "junior admin" user group is going to make the standards for actual adminship rise significantly. RFA has serious problems, the implementation of this will only worsen things. Omni Flames (talk) 00:23, 9 July 2016 (UTC)[reply]
  10. Oppose Viewdelete is a nonstarter for me as is the regular delete function in general for non-admins. So the entire "handle deletion" section would need to be eliminated for me to even begin thinking about this. Once that is gone, the rest of the package can pretty much be gotten from other PERM requests on an as needed basis. The only new thing I can really see is the ability to merge histories which should only be done if people know what they are doing anyways for copyright reasons. So nope, sorry. Can't support this. --Majora (talk) 00:23, 9 July 2016 (UTC)[reply]
    Oppose Let's fix RfA first, also, didn't the "straw poll" proposal fail? Music1201 talk 02:24, 9 July 2016 (UTC) Move to support.[reply]
    How should we fix RFA? KSFTC 01:23, 10 July 2016 (UTC)[reply]
    @KSFT: Wikipedia:Village_pump (proposals)#5th RfA reform Music1201 talk 02:20, 12 July 2016 (UTC)[reply]
    @Music1201: That would be great, but that proposal will almost certainly not pass. KSFTC`
    @KSFT: Nothing has really been proposed to the community yet. Some editors are just throwing out ideas. Music1201 talk 02:27, 12 July 2016 (UTC)[reply]
    @Music 1201: Yeah, I was one of those editors. I support many of the ideas there, but I think it's unlikely that any of the current ideas will be passed if they are formally proposed. KSFTC 02:30, 12 July 2016 (UTC)[reply]
  11. Oppose. I do support unbundling the admin tools, but this proposal is not the right way to go. In general, deletion (closing XfDs, performing CSDs, performing revdel, access to to deleted content, etc) is regraded by community as a core admin function requiring a high degree of community trust. As such, the confirmation standards for the envisioned "moderator" status are likely to be essentially the same as for the full admin status, at least initially. As proposed, the "moderator" group is not a sufficiently specialized subset of the current admin group. Given that the confirmation standards are likely to be similar, I personally doubt very much that there is a large untapped pool of potential recruits who would apply for the "moderator" status but would not apply for the "admin" status. The amount of hassle is about the same. On the other hand, creating the "moderator" status will fairly likely, over the long term, result in getting full adminship harder to obtain. When an extra rank of this type is introduced, it will almost certainly eventually come to be viewed as a necessary prerequisite step to getting full adminship. I don't think that's the intended outcome but I believe that this is very likely to happen. I think that unbundling has to be done very differently. It has to start from below, starting from creating new relatively minor user-rights, granted and removed in a way similar to rollback. Eventually the unbundling process would reach some of the higher-level admin rights, perhaps in smaller, very specialized packages, requiring very specialized forms of confirmation. But I would certainly start from below, not from above. Nsk92 (talk) 02:32, 9 July 2016 (UTC)[reply]
  12. Oppose (edit conflict). I don't doubt for a moment that this proposal has been made in good faith with the very best of intentions; it may be based on the proposer's ideological convictions, or it may be based on a dispassionate proposal to obtain a clear community consensus on an oft mentioned community suggestion (such as I did with BARC), but it's not going to be a silver bullet for the dearth of Adminship candidates. …we should be making the RFA process better. If someone is trusted enough to be a "moderator," they should be trusted enough to be an "administrator."
    'Admin lite' is not something to be obtained easier than Sysop and its broad scope would require it to be subject to an RfA-like election process - it's too delicate to be accorded through the discretion of one admin at WP:PERM (see: WMF statement). What we would end up with is just an additional (RfM) venue where users will be allowed to break all the rules of collaborative harmony and respect for each other with total impunity just as they continue to be at RfA.
    The solution and the only solution, IMHO, to address the lack of candidates for adminship of the right calibre is to clean up the voting requirements and to actively RfA-topic ban users who demand outrageous levels of experience, trolls and socks (and to illustrate these points: this vote by a blatant troll), and those who tactically oppose all candidates.
    I could almost certainly see my way to supporting extremely limited extended rights to Rollbackers, for example (or a new user group) to short-block vandals (@WereSpielChequers:) on a spree and to short-semi-protect pages subject to heavy, almost unstoppable vandalism sprees, but the current proposal goes far, far too far. Kudpung กุดผึ้ง (talk) 02:52, 9 July 2016 (UTC)[reply]
    Just to be clear - ...it's too delicate to be accorded through the discretion of one admin at WP:PERM..." - That is in no way being proposed here AT ALL. - jc37 03:00, 9 July 2016 (UTC)[reply]
    Just AGF for a moment, OK? It wasn't, but it needed to be mentioned. Don't shoot the messengers or you'll torpedo your own RfC very quickly. Kudpung กุดผึ้ง (talk) 03:04, 9 July 2016 (UTC)[reply]
    Kudpung, I think you know me better than that, too : )
    Mentioning it though, in the way you did, could lead others to think that that is what this is proposing (just as someone did, above). So it needed to be clearly clarified. So thank you for that : ) - jc37 03:20, 9 July 2016 (UTC)[reply]
  13. Oppose on the grounds that at the least, "moderator" should not be used for this. By definition, a moderator in an online community deals with user conduct issues - precisely the opposite of what this proposal intends.--Jasper Deng (talk) 06:14, 9 July 2016 (UTC)[reply]
    Moderators close discussions... But as I said in the proposal, I welcome other name suggestions. How about implementer? - jc37 06:38, 9 July 2016 (UTC)[reply]
    Highlighting Jasper Deng's nomenclature point here. The way the WP community functions, the type of conduct issues often handled by "moderators" on Internet discussion boards (such as mediation and conflict resolution) can be handled by any mature, experienced Wikipedian. But enforcing any penalties on user conduct (such as community bans or other decisions reached via RfCs) that require blocking or page protections, require the admin tools. As currently any Wikipedian can do the non-admin part of Internet moderator duties, to call a position that lacks the tools needed to enforce consequences "Moderator" would be meaningless and make our system yet more confusing to users. - CorbieV 20:09, 12 July 2016 (UTC)[reply]
  14. Oppose As simply a half-arsed way of granting rights to editors that they would not otherwise be deemed fit to receive. Muffled Pocketed 11:30, 9 July 2016 (UTC)[reply]
  15. Oppose. Bleh. I think this would just add another layer of confusion and complexity. People need to earn community trust for the tools. I know that's hard these days but I don't think adding another layer of confusion would help, especially if it lowers the standards on some of the privacy issues (as others have noted above). - CorbieV 17:50, 9 July 2016 (UTC)[reply]
    If I may ask, where in this proposal do you see that it "lowers the standards", or that "community trust for the tools" is any different than requesting admin tools? - jc37 18:02, 9 July 2016 (UTC)[reply]
  16. Oppose. If the proposed issues are how the closings at the various discussion boards are handled, then change those requirements. Everything, even closings by an admin, are subject to review. It's just the level of review so I'm not seeing this as anything more than another way to avoid the reality that RFA sucks because the silent majority of voters there want it to suck and don't really care about all the backlogs and/or believe there is a "lack" of admins. -- Ricky81682 (talk) 23:39, 9 July 2016 (UTC)[reply]
  17. Oppose. Despite a rigorous process for selecting admins, a few admins quickly demonstrate that they were never qualified to have been entrusted with tools. Wikipedians are not immune from the corruption of power. The last thing Wikipedia needs is to distribute any of the admin tools, or other special powers, more widely.—Finell 23:58, 9 July 2016 (UTC)[reply]
  18. Oppose I've followed RFA for along time including WP:RFA2013 and WP:RFA2015. The notion of simply "fixing RFA" is a task that I do not expect to occur until there is a fundamental change in the community. There is almost a universal desire for RFA reform but a seemingly unsurpassable division on how it will be done. We see proposal after proposal defeated with minimal gains. Nothing even remotely close to the reform needed to get it to a place where the community would consider it "fixed". I do not think we should prioritize RFA reform ahead of new proposals to unbundle the tools otherwise it will mean an indefinite wait. However, I think this unbundled package needs to be widely distributed among experienced editors for it to become effective. Otherwise it simply becomes another hierarchal tier and something that will further divide the community. That being said, I do not think that revdel, delhistory, deltext, and browsearchive should be included. The potential for damage and access to sensitive material is too great for it to be widely distributed among editors and therefore defeating the purpose of unbundling these tools in the first place. Mkdwtalk 00:01, 10 July 2016 (UTC)[reply]
  19. Oppose - the requests process would basically have to be the same as RfA, and there's no point in going through that for only part of the same toolset. ansh666 01:58, 10 July 2016 (UTC)[reply]
  20. Oppose RFA is a little bit tougher than when I passed mine in 2013, but I still see strong candidates passing RFA with 100+ supports pretty regularly. Perhaps some improvements in the RFA process could be made, but a new half-admin group doesn't sound like much of an answer. There's a reason we have a toolkit. Attack pages need to be deleted, and often the creator needs to be blocked. Pages may need to be salted after deletion. The same goes for spammers and sockpuppets and all the messes they make. RFA is a challenge, but so are sockmasters, vandals, edit-warriors, and pissed off people coming to your talk to ask about a deletion you did. You've got to be able to handle pressure to be a good admin, you've got to be trusted and experienced, and you've got to be at least ready and willing to help out with a block or protection in a pressing situation, even if you don't want to work in those areas on a regular basis. I oppose any unbundling whatsoever. INeverCry 02:02, 10 July 2016 (UTC)[reply]
  21. Oppose First, we have sufficient administrators for all the key functions--unlike 8 years ago, CSDs are handled very quickly,and except around major holidays, AfDs are closed fairly promptly. Second, content and behavior are often related. Of the CSdD I deleted today, more than half called for applying create protection, and half of those, for blocking the promotional contributors. The key problem at Afd will not be delat with by this: they key problem is the recurrent opposes by those who think that even one year of content work is not sufficient--since this will deal only with content, the same problem would apply--those who object to good people with adequate but not extensive experience would object just as much here. Mofre basically, the system needs to be simplified, not made more complicated. The current userright system and the current jungle of admin procedures and relevant policies and guidelines is uncoordinated and confusing. Adding anything else to it is moving in the wrong direction: we need to do just the opposite. DGG ( talk ) 02:39, 10 July 2016 (UTC)[reply]
  22. Oppose As others have said, deletion and other admin tools go together in important ways. For example, if User:ExampleSpamCompany put an advert on their userpage, and it was tagged for G11, they would need a {{uw-spamublock}} as well as a deletion. If a moderator handled that (and they would, because there will always be keen beans overreaching themselves) they would a) let the user drop through the net (bad) b) report the user to AIV for a real admin to block (excessive bureaucracy). Secondly, we already have so many levels of user (IP, account, autoconfirmed, extended-confirmed, admin) that further social stratification seems offputting to me. Lastly, I can envisage the effect on real RFAs: opposes on the grounds of "hasn't been a moderator, so no reason to trust them" and so on. Because moderator includes the viewdeleted right, it will have to have RFA levels of scrutiny, which will almost surely push up the criteria at RFA. BethNaught (talk) 13:09, 10 July 2016 (UTC)[reply]
  23. I'm OK with the name moderator, and with logical unbundlings. But this is the wrong set of tools for that name. RFA is difficult to pass for vandalfighters who need the block tool but who don't have sufficient content creation. It is also difficult to pass for those content creators who don't do enough admin type activities to show a need for the tools. I'm not convinced this helps either group, and I'm not greatly bothered with the second group as those content creators who can demonstrate a need for the tools usually pass RFA by acclamation. I'd support a moderator user right that didn't include delete but did allow experienced vandalfighters to block and unblock vandals and spammers who hadn't yet contributed 100 edits. I'd also be happy with an extended RFA role for bureaucrats to judge if consensus has shifted on unsuccessful RFA candidates. ϢereSpielChequers 05:27, 11 July 2016 (UTC)[reply]
  24. Oppose – As formulated, this proposal is likely to transfer admin requirements to moderator requirements and to raise the bar further for full admin tenures. After a few years of bickering over minor details escalating scrutiny for admin hopefuls, things have thankfully eased down a bit and I believe that we have reached a point where the admin corps is being sufficiently renewed, so this change risks swinging the pendulum in an unproductive direction. On the other hand, WereSpielChequers makes a cogent summary of the usefulness of an alternative moderator package tailored for easing the fight against vandalism without granting "excessive" powers; I would approve that one. — JFG talk 11:42, 11 July 2016 (UTC)[reply]
  25. Oppose per above - If an editor could be trusted with this usergroup then they should be trusted with the admin tools and IMHO we should somehow fix the RFA process instead of creating silly usergroups. –Davey2010Talk 19:27, 11 July 2016 (UTC)[reply]
  26. Oppose. With all of these privileges, the editor might as well run for administrator. Steel1943 (talk) 22:47, 11 July 2016 (UTC)[reply]
  27. Oppose - If an individual is trusted enough to hold the rights this proposal would grant, there is no reason block and protect shouldn't be included. Different classes of administrators isn't a good path to go down. The community has been open to unbundling smaller pieces of the administrator toolset (e.g. Wikipedia:Template editor and WP:Page mover), if a need can be shown, and that is seemingly the best way to go in the future (if these type of proposals are to have a chance of gaining consensus).Godsy(TALKCONT) 23:08, 11 July 2016 (UTC)[reply]
  28. Oppose per Finell. We don't need another class of unaccountable, lifetime-appointed super-users. Coretheapple (talk) 23:41, 11 July 2016 (UTC)[reply]
  29. Oppose. By including deletion and ability to view deleted, this would probably be required by the WMF to have the same level as backing as an admin now, and this would only push the bar for admins higher, which isn't that RfA needs. The solution is to fix RfA, not create new classes of admins. ---- Patar knight - chat/contributions 02:54, 12 July 2016 (UTC)[reply]
  30. Oppose, all moderators should be administrators, just like most other experienced editors. —Kusma (t·c) 04:59, 12 July 2016 (UTC)[reply]
  31. Oppose - This is basically a copy of most of the rights that administrators get. I mean I do understand the concept for this userright because it provides some experience for an editor in some admin-related tasks that provides a transition to the full admin set, however this just raises the bar for those who want to go straight to an RFA. Hx7 13:01, 12 July 2016 (UTC)[reply]
    My math may be different than yours, but afaik, 22 out of 82 isn't "most". (and 7 of those 22, "most" editors already have.) - jc37 02:24, 13 July 2016 (UTC)[reply]
  32. Oppose the need for half-ops has not been established --In actu (Guerillero) | My Talk 20:26, 12 July 2016 (UTC)[reply]
  33. Oppose @Jc37: The three things that were mentioned at this discussion as "never allow anyone but admins to do this" were put down as tools. They were closing deletion discussions (never going to work), CSD's (not going to happen) and viewing deleted content (WMF-Legal won't allow it without an "rfa like process"). There is no way that this would succeed. ThePlatypusofDoom (talk) 01:34, 13 July 2016 (UTC)[reply]
    Also known as a self-fulfilling prophesy. "We don't think this will ever succeed, so we'll 'vote' against it to make sure it doesn't" - jc37 02:24, 13 July 2016 (UTC)[reply]
    @ThePlatypusofDoom: You might want to read the proposal. It specifically states that moderators would only be appointed through a request for the tools, similar to RFA. Omni Flames (talk) 23:54, 17 July 2016 (UTC)[reply]
  34. Oppose. As perfect as this would be for me, and as much as I would love to have these tools sans the behavioral ones, I find this package insupportable. The thing is, and I'm probably not alone in this, I'm not unhappy with the present situation of asking for an admin's help when I need it. If I were to acquire this package, I don't think I'd ever try to be an admin. Add that to what others are saying about what this would do to the adminship vetting process and I just don't think this would or should fly.  Wikipedian Sign Language Paine  21:33, 13 July 2016 (UTC)[reply]
    And why would it be bad for you to never ask to be an admin? As a volunteer project, no one is required to do more than they are comfortable volunteering to do. - jc37 06:50, 15 July 2016 (UTC)[reply]
    Yes, I see now the strong implication of badness, so I worded it badly. I simply meant that, for me, the fact that I'd probably never try in the future to be an admin added to the "badness" of what others here say about what this unbundling would do to the RfA process to become an admin tends to make me agree with opposers. I know that a lot of your work has gone into this, and I'd really love these tools; however, it very much appears that it's going to be "back to the ol' drawing board". Simply put, your As a volunteer project, no one is required to do more than they are comfortable volunteering to do is just as good a reason for not supporting this unbundling.  Wikipedian Sign Language Paine  16:00, 15 July 2016 (UTC)[reply]
  35. Oppose - The main reason to unbundle admin rights is to allow "cheap" groups with the abilities to handle some admin actions - where "cheap" means the lack of any major RFA or similar process to get it. The proposed right, however, isn't "cheap" - it would require a full RA-like process. עוד מישהו Od Mishehu 03:43, 15 July 2016 (UTC)[reply]
    By your arguement, we shouldn't have bots either then. A situation where the requester has different needs, and is not asking for all the admin tools, but which still requires the full rfa process. - jc37 06:50, 15 July 2016 (UTC)[reply]
    Bots are a different issue. No one trusted me with the tools to edit extremely quickly with little scrutiny, and no one trusted AnomieBOT with the ability to delete pages or block users. These are non-comparable. On the other hand, these "partial adminship" packages are clearly designed as "cheap" methods of getting some of the admin tools without the others, and should be used only when they are, in fact, "cheap". עוד מישהו Od Mishehu 09:25, 20 July 2016 (UTC)[reply]
  36. Oppose per points made in WP:Perennial. Another RFA process will complicate the process more than help it. ZettaComposer (talk) 11:29, 15 July 2016 (UTC)[reply]
  37. Oppose per above. - Yellow Dingo (talk) 01:53, 16 July 2016 (UTC)[reply]
  38. Oppose. I don't think I could put it better than any of the other voters above, esp Tavix up top. I understand the ostensible purpose of helping with backlogs, but I don't really understand the ways in which this usergroup has been carved out of the regular admin position. I agree with what has been expressed, that if someone is trusted enough to have these specific privileges, then they should really also be trusted enough with the rest of the tools in the mopbucket. Deciding some are ok to include but others aren't seems arbitrary. Tpdwkouaa (talk) 19:35, 18 July 2016 (UTC)[reply]
  39. Oppose: Mods just should treated as admins. KGirlTrucker81 talk what I'm been doing 14:17, 20 July 2016 (UTC)[reply]
  40. Oppose per BethNaught and DGG. Softlavender (talk) 11:38, 21 July 2016 (UTC)[reply]
  41. Oppose I don't see the point of creating another layer to our user-rights hierarchy (with all of the bureaucratic and technical complications that entails, if the vetting process is more or less identical. There's really no reason why the same contributors who would otherwise apply for the "moderator" toolkit cannot simply clear the same process to become admins and then abstain as much as they care to from utilizing the block and protect tools. Even more worrisome is the possibility that over time the standards for these two levels of user rights may diverge, with the standards for moderator and administrator becoming viewed as more lax and stringent, respectively. This would almost certainly have a two-fold effect on our already almost crippling lack of administrators capable of resolving behavioural issues: 1) it would almost certainly drive a large portion of tool applicants to opt to request moderator status; even many of those who show an interest and capability for handling disputes might consider it a safer route to request limited tools first, and 2) there might develop a stigma to users applying directly for admin status (even though there is little in how one handles the tools of the moderator package which would go to demonstrate whether they are capable of handling the block and protect tools soberly), thus greatly complicating an RfA process that is already often brutal and produces !votes predicated on all kinds of bizarre and idiosyncratic standards. Anything that has potential to create a substantial bottleneck in our admin recruitment process is about the last thing the project needs right now. Add in an increase in institutional complexity, with no obvious substantive benefit, and I have to view this as a borderline WP:SNOWBALL call. Snow let's rap 13:55, 21 July 2016 (UTC)[reply]
  42. Oppose. Per a lot of the above, if I trusted someone to use these tools (which are core admin tools) I would trust them to be an admin, and anyone getting the admin tools is under no obligation to use all of them. If we want to see more admins, the solution is to encourage editors with the right aptitude and experience to apply, and to stop putting off potential admins by constantly moaning about RfA and building it up to be more of an ordeal than it really is. --Michig (talk) 15:33, 21 July 2016 (UTC)[reply]
  43. Oppose. Giving viewdeleted to users who aren't admins is a terrible idea and would open the door to all kinds of legal nightmares for Wikipedia. Also, this keeps coming up and the community has resoundingly rejected it every single time (see WP:PERRENIAL). Andrew Lenahan - Starblind 19:55, 21 July 2016 (UTC)[reply]
    @Starblind: WMF Legal has approved this proposal; that shouldn't be a reason to oppose it. I also don't think past rejections mean on their own that it should be rejected again. — Preceding unsigned comment added by KSFT (talkcontribs) 00:02, 24 July 2016‎
    I assume you're referring to [this comment]. If so, please note the following: (1). That was 4 years ago (2). The user who posted it quit last year (3). The WMF lawyer supposedly consulted is also no longer with WMF as of late 2012! Given those facts, trying to twist that into claiming WMF has "approved this proposal" is disingenuous at best. Besides, you seem to have missed the stipulation that WMF Legal states that the process and criteria for moderators would have to be exactly the same as for admins, making this doubly pointless. Finally, I disagree with your belief that the same proposals should be rehashed again and again and again. Squashing the same terrible ideas over and over every few years is a huge waste of volunteer time and resources better spent improving the encyclopedia. Andrew Lenahan - Starblind 18:40, 24 July 2016 (UTC)[reply]
  44. Oppose Was going to say the same as Starblind. I get why this proposal is different than the past ones, but it's the same premise of unbundling admin tools that has been proposed time and time again. The "bundle" is meant to be a bundle, the tools work together, plain and simple. A delete button isn't always the right answer. And yes, we do need a formal entry in WP:PERRENIAL to strongly discourage these proposals that prove to be a waste of everyone's time MusikAnimal talk 23:46, 22 July 2016 (UTC)[reply]
  45. Oppose largely based on Esquivalience's hammer/nail analogy (which I completely agree with) and MusikAnimals comment on the reason for it being a bundle. I oppose anything that splits block/delete/protect, as often one uses two or three of those to fix the same issue. Giving the ability to use only one will mean that someone else has to come along and finish the job. --kelapstick(bainuu) 05:01, 23 July 2016 (UTC)[reply]
  46. Oppose The deletion functions, particularly revdel and viewing deleted edits, require nearly the same degree of trust as the blocking functions, and certainly enough that we'd still need an RfA-like process to grant them. If that were the case, the same problems that RfA has would probably spread to the new "Request for moderatorship" process, and RfA would probably get even harder thanks to "why can't you run for moderator instead" becoming a counter-argument to anyone who mostly does content work. We absolutely need to address the admin shortage (and the resultant backlogs), but this isn't how to do it. TheCatalyst31 ReactionCreation 15:11, 23 July 2016 (UTC)[reply]
  47. Oppose Per Starblind. Class455fan1 (talk) 15:35, 23 July 2016 (UTC)[reply]
  48. Oppose The RfA process is already a mess. Soon people will draw up their own personal 'moderator' criteria, have their single-issue opposes at the ready, or return to revive dead disputes with the candidate in question. I hope, that this might not be the case, but that's what is in everyone's minds. The scale of power and authority must meet the rigorousness of the selection process, and this might be just a bit too hard. My name isnotdave (talk/contribs) 16:53, 23 July 2016 (UTC)[reply]
  49. Weak oppose mostly per Nsk62 (oppose no. 11) I don't like to oppose this one; I'd like to see more unbundling; but if it's as hard to become a moderator as an admin, I don't see much point. Chickadee46 (talk|contribs) (WP:MCW) 18:15, 23 July 2016 (UTC)[reply]
  50. Oppose. Either moderators would have the same standards for appointment as administrators have, or they'd have lower ones. If they were to have the same standards, then they should be trusted to be full administrators; if they aren't "comfortable" with having full administrator tools, then it means they don't trust themselves enough for them (or to refrain from using them if they don't want to), in which case, neither will I. If, on the other hand, this paves the way to lower standards, then it would be unacceptable for these moderators to have things like deletion rights. If adminship requesting is broken, fix it; and if we feel that lowly users should be able to close all discussions, then let's just let them (which I would be in favor of, since Wikipedia tells us that administarators are janitors with tools, not people in power and yet somehow closers-with-admin-rights are more equal than other closers). LjL (talk) 00:16, 24 July 2016 (UTC)[reply]
    You'll pardon me for saying so, but your post is incredibly in bad faith. If someone isn't comfortable with tools, it of course in your worldview means they don't trust themselves? In my not so humble opinion, the words that your comments deserve, aren't for polite public discourse. Perhaps if you had bothered to investigate this proposal instead of merely ILIKEIT/IDONTLIKEIT "voting", like all too many on this page, maybe, just maybe, you would have seen the several places explaining even just some of the reasons. I'll presume, it's merely your lack of due diligence, and not religious bias against certain Quakers' beliefs (for merely one example), that leads you to make such intolerant comments. - jc37 01:30, 24 July 2016 (UTC)[reply]
    What in the world, jc...maybe you ought to take a step back and read aloud what you're writing right now. It's frustrating that your proposal is failing, but you're definitely not AGFing here by accusing someone of not paying attention to your proposal, as you say you are; personally I think it's a pretty nasty and completely uncalled for ad hominem. ansh666 02:07, 24 July 2016 (UTC)[reply]
    I appreciate your concern, but please, read their comments again. "...then it means they don't trust themselves..." - who the <blank> do they think they are to decide what someone thinks or feels? The motives for this proposal came out of MANY discussions, and afaik, NEVER suggested that another Wikipedian didn't trust themself. It's almost like accusing someone that they must not trust themself to teach children, if they only want the ability to help students by only teaching classes and not wanting to be a school hall monitor. The personal choice of the teacher not wanting to be a hall monitor means that the teacher in question doesn't trust themself to be a hall monitor? In my nsho, it's such an asinine statement that it should be redacted at the very least. - jc37 02:50, 24 July 2016 (UTC)[reply]
    @Jc37: no, as a matter of fact I won't pardon you for saying so. Responding to a reasoned opinion in a straw poll with a direct accusation of being in bad faith is a blatant violation of WP:AGF, and much of the rest of what you said is a blatant violation of WP:WPA and, honestly, downright rude. I won't answer your specific points because 1) others have done so 2) I don't want to interact with you given your rather terrible attitude. Cheers. LjL (talk) 14:14, 27 July 2016 (UTC)[reply]
    You both should re-read WP:AGF. I quoted you directly. Attempting to do a dramatic exit doesn't change your words.
    (I'm wondering what WP:WPA has to do with this. I have a guess that perhaps a different page may have been intended - and if I've guessed correctly, you may wish to re-read that page as well - but I'll wait for you clarify that.) - jc37 15:39, 27 July 2016 (UTC)[reply]
    Yes, I meant WP:NPA. Just drop it. You've been called out by others on the inappropriate of your behavior above. It's unbecoming. Let me express my reasoned opinion, as I have, and move on without attacking me. Thanks, bye. LjL (talk) 21:34, 29 July 2016 (UTC)[reply]
  51. Oppose. This adds needless bureaucracy and yet another level to the perceived hierarchy of contributors. Editors who want access to the proposed moderator group should request admin rights and simply go about life without using the tools they aren't interested in using. I was very clear in my RfA that I would not be using the delete function to actively close AfDs and I still to this day avoid the area entirely. No. --auburnpilot talk 01:22, 24 July 2016 (UTC)[reply]
  52. Oppose - Any actions on Wikipedia that involve the deletion of Wikipedia article material (like CSD, AfD & DRV) should be done by Wikipedia administrators only. Guy1890 (talk) 05:14, 24 July 2016 (UTC)[reply]
  53. Oppose - any editor can give advice, there is no need to have a special group for this. For a part this will just give an advice to an admin who will then need to carry out the advice (e.g. delete a page), an advice that can be given by any independent editor and does not need a special right, for the rest this is just an 'non admin close' (and also there it does not matter whether the user is part of a special group or not). Instruction creep and/or bureaucracy creep. --Dirk Beetstra T C 11:06, 24 July 2016 (UTC)[reply]
  54. Oppose - it would be better to focus on improving the RFA process - if a user is worthy of "moderator" status then they are most likely worthy of the administrator tools. --Zerotalk 14:04, 24 July 2016 (UTC)[reply]
  55. Oppose as written. The group of tools is too large for someone who is not comfortable with bad behavior from users. The ability to view deleted revisions is not needed. Binksternet (talk) 20:34, 24 July 2016 (UTC)[reply]
  56. Oppose. The ability to see deleted items and undelete them should remain admin functions. Jonathunder (talk) 21:37, 24 July 2016 (UTC)[reply]
  57. Oppose. I'm sorry, but I'm quite heavily against this. I agree that the RFA system has become ridiculous and needs reform, but I don't feel that this is the answer at all. It would create a larger administrative backlog, for a start, due to the need to assess poor moderation decisions on top of everything else at present. The sentiment is right but this isn't the right proposal to tackle the backlogs; Improving RFA is, but further thought on that is beyond the scope of this debate. KaisaL (talk) 23:46, 24 July 2016 (UTC)[reply]
  58. Oppose. Since it's obvious that many contributors feel the RFA process is flawed, it seems to me that we should be addressing that first, and the proposal of yet another new semi-admin position like mod is an attempt to get around the main problem instead of tackling it, which we'll have to do sooner or later anyway. --Katangais (talk) 16:37, 25 July 2016 (UTC)[reply]
  59. Oppose I liked this idea but I'm sorry to say that I'm opposing this. This user-group kinda beats the purpose of having an administrator here by giving 20% of the tools. Tasks that requires admins such as AfD, CSD, etc.... should be done by admin only. Ayub407talk 18:18, 25 July 2016 (UTC)[reply]
  60. Oppose per various comments above. This proposal would add more bureaucracy (making it even harder for editors to understand the workings of Wikipedia) whilst doing little to increase the number of editors with additional rights (those who oppose at RFA for silly things would probably also oppose at RFM). A much lighter system might be worth considering - e.g. have a list of admins who have have made a commitment (e.g. at their RFA) not to use particular parts of the toolkit (e.g. block) and have a system (e.g. bot or database report) to flag up any violations of that commitment. DexDor (talk) 20:48, 25 July 2016 (UTC)[reply]
  61. Oppose while I'm tempted to support this on the grounds that we need to try something to fix the RfA process I also think this is likely to backfire by making it far harder to get the current admin right. There is already a faction which sees the block button as particularly dangerous, far out of proportion to what it is actually used for, and this proposal would effectively institutionalise that view, leading to much higher requirements for people trying to get that tool. I'm not sure this would help. Hut 8.5 21:29, 25 July 2016 (UTC)[reply]
  62. Oppose The rights proposed are not ones that I want non-admins to have. Blue Rasberry (talk) 00:38, 26 July 2016 (UTC)[reply]
  63. Oppose - See WP:RFA Mlpearc (open channel) 02:11, 26 July 2016 (UTC)[reply]
  64. Oppose. Not with deletion. All the other ones are fine and I would support otherwise. However the better plan would be to just relax WP:NACD, ie. simply call it a 'closure' instead of a non-admin closure, as if they're not worthy enough. -- œ 05:06, 26 July 2016 (UTC)[reply]
  65. Oppose Just no. Natuur12 (talk) 08:50, 26 July 2016 (UTC)[reply]
  66. Oppose. Hell no. Someone with poor judgment misusing the block or protect tools is easily fixed; the astronomically high bar at RfA stems from the rampant possibilities to screw stuff up with the authority handed to admins for most of the things this proposal targets. I'd actually be more likely to support this if it were the other way around. The Drover's Wife (talk) 10:33, 26 July 2016 (UTC)[reply]
  67. Oppose. The last thing we need is to make Wikipedia more bureaucratic by adding yet more layers to the hierarchy. The editor who uses the pseudonym "JamesBWatson" (talk) 13:54, 26 July 2016 (UTC)[reply]
  68. Oppose. I respect those who've supported this proposal, but after considering it I'm not sure it fits a need we currently have. This would also be an entirely new structural change to our system that hasn't been tested. I'd want to see this in a pilot stage of some kind before I'd feel comfortable with expanding it to the entire wiki. Lord Roem ~ (talk) 18:39, 26 July 2016 (UTC)[reply]
  69. Strong Oppose The ability of non-admins (Moderators/Curators/whatever) to view deleted content is very concerning. Accidental IP exposures, right-to-vanish compliance, and even legal risk BLP issues become highlighted under this new power. Who will monitor the non-admins (and how) to ensure they do not abuse this power by browsing deleted content that should not be disturbed? Koala Tea Of Mercy (KTOM's Articulations & Invigilations) 02:07, 27 July 2016 (UTC)[reply]
    I'm cleanly in the oppose camp, but just so we're clear, the concept of the right to be forgotten is not really relevant here; that legal principle has no compulsory effect on Wikipedia and we would not remove content just because someone covered by one of our articles opened a RTBF action. This is not just a matter of Wikimedia being based in the U.S., but also because the way the right to be forgotten is implemented in the EU generally involves mandating that search engines remove links to content; as a general rule, publishers of original content cannot be compelled to remove material, as their work product is not a part of the doctrine and is usually protected under freedom of speech and freedom of press protections. There was one effort to try to get the Deutsch Wikipedia to remove content about a convicted murderer, but that information remains to this day.
    Even if the doctrine were at some date modified or interpreted to focus more on original content rather than links, it is unlikely that a legal challenge could have much effect on Wikipedia, since A) it is unlikely the U.S. would enforce a foreign injunction on services performed in the U.S. when said injunction would violate its expansive freedom of expression rights, B) Wikipedia is not-for-profit and thus cannot be threatened with having its services sanctioned and impeded, except to the extent that it could be blacklisted or have some local resources shut down and C) it is unlikely the WMF or the movement at large would cave to these demands just to maintain links, not without watershed controversy and a huge amount of debate, D) probably no government wants to deal with the fallout of cutting off access to Wikipedia, which enjoys enormous popularity and is a symbol of a service representing freedom of information, E) it is unattractive for the party who wants to be forgotten, given the Streisand effect is multiplied a hundred thousand times over through the lens of a Wikipedia controversy/major legal action, and F) this is just generally the last fight any proponent of (or agency tasked with administering) the right to be forgotten wants to pick. All rather incidental to this discussion, of course, but I didn't want anyone walking away from this thinking Wikipedia censors its content to meet the demands of those who would rather they weren't mentioned here. We have our own notability guidelines that cover that question. Snow let's rap 11:09, 27 July 2016 (UTC)[reply]
  70. Strong oppose. This is a classic case of band aid approach. The main problem is the ever reducing number of administrators (check the administrator count). For nine years in row, the active admin count has been falling and does not seem to stop. Whilst people always talk about AGF, there is massive hostility, criticism, scrutiny, blame etc that goes on during RFA. Till we don't accept the fact and recognize the main problem, nothing will be solved. To me, the entire approach of RFA seems to be finding reasons why a candidate should NOT be an admin (and a fault finding mission), rather than looking for merits and promoting experienced people as administrators. In 2015, I had raised the concern of falling number of administrators (check Wikipedia:2015 administrator election reform/Phase I/RfC) where clear closing consensus were following;
    C: Hostile environment
    D: More participants
    I: Ease the load on admins
    O: The discretionary range is too narrow
    Despite the long exercise and the consensus, there has been NO improvement to the situation and as result, we are discussing something as silly as this. If the current attitude (towards RFA candidates) were to prevail pre 2007, most of the administrators we see today (from pre 2007 time) would not have been administrators at all. Most would have got frustrated and left Wikipedia. The solution is NOT is diluting the access levels BUT the solution lies in grooming more administrators. I am sorry to say that with everyday passing, Wikipedia is becoming more and more "bureaucratic" with punitive and harsh approach towards senior non-admin editors. Only solution is to identify and encourage experianced editors, groom them and get the administrator count up. Should we fail to do that, in few years, almost all the admin functions will be diluted to other user access levels. Arun Kumar SINGH (Talk) 19:31, 27 July 2016 (UTC)[reply]
  71. Oppose - while having "moderators" who aid administrators makes sense in an internet forum, I don't think this concept is compatible with Wikipedia. The problem is the inadequate number of admins, which this proposal would not change, if not make worse. --Laber□T 02:25, 28 July 2016 (UTC)[reply]
  72. Oppose - performing deleting and protected articles requires just as much community trust as blocking users. With that said, the proposed RfM would be just as brutal and unforgiving as the RfA process, and wouldn't meaningfully increase the number of admins/moderators, and would likely decrease the number of admins. I don't see how that's helping anything. Pianoman320 (talk) 18:34, 29 July 2016 (UTC)[reply]
  73. Strong Oppose Increase the number of administrators. Rainbow Archer (talk) 10:54, 30 July 2016 (UTC)[reply]
  74. Strong Oppose We need more admins. A moderator, with a moderator toolset, requested with a Request for Moderatorship [nonsense word?] is no solution. ProgrammingGeek (Page!Talk!Contribs!) 15:43, 31 July 2016 (UTC)[reply]
  75. Strong Oppose This at its core is nothing more than a thinly veiled attempt to cover up the catastrophic hemorrhaging of contributors and an RFA process that is widely regarded as broken but that no one every seems to have interest in disbanding and rebuilding from the ground up. For that reason I will not be supporting this proposal, all this shows is how truly desperate we have become to gain and retain editors who actually contribute in a meaningful way. TomStar81 (Talk) 05:47, 2 August 2016 (UTC)[reply]
  76. Oppose The idea that someone might feel they aren't sufficiently qualified or confident enough to protect an article yet they do feel able to delete it completely just doesn't make much sense to me. I still believe in the idea that if a user is trustworthy enough to be given any of the admin tools, they can and should be trusted with all of them. Admins are not compelled to use every tool at their disposal should they wish to refrain from operating in certain areas. The more steps there are on the ladder between non-admin and full admin, the more lofty a position being an administrator appears to be, when it should still be no big deal. WaggersTALK 10:35, 2 August 2016 (UTC)[reply]
  77. Oppose if you're not ready, or won't pass, as an administrator, then you're not ready for additional tools. Further, we need more admins, which this will not only not address, it may make worse - because admins take such heat from everyone, perhaps those who might stand RFA will choose instead the Moderator path. Bad either way. KillerChihuahua 11:26, 2 August 2016 (UTC)[reply]
  78. Oppose Unnecessary bifurcation of adminship with ensuing complications. DavidLeighEllis (talk) 02:18, 8 August 2016 (UTC)[reply]

Neutral[edit]

  • Here, unsure if I'll be moving yet. Experiencing cognitive dissonance. I'd support this morally, although I feel that unbundling in specific areas (rather than a wide-scope batch of flags) may help more with project productivity. The RfA process isn't kind right now, and if it takes an editor as much effort to go through this, many folks will probably be uninterested. I don't know the WMF stipulations, but would the delete and deleterevision flags alone require some form of RfA process? And another thought on adminbots: we have some of these because block is needed, or because editprotected is needed, but if these were unbundled in some way, (possibly this user group here, or preferably a group with fewer flags) the bots could be desysopped for greater security and assigned to the new group instead. — Andy W. (talk ·ctb) 01:07, 9 July 2016 (UTC)[reply]
    It's a catch-22 of sorts. My understanding is that the ability to viewdeleted has WMF privacy concerns, but on the other hand, closers of deletion discussions should be able to, in order to effectively carry out the tasks. Imagine undeleting something because you couldn't see it was private info. Not all edit summaries are created equal. And sometimes the edit summaries themselves can be an issue. WP:BEANS territory, to be sure. And I think we'd like to avoid making a Mod afraid to do WP:REFUND. That's a core issue here - many of these userrights are interdependent in practice (and policy in some cases). If we get technical, this group is essentially a discussion/deletion/move implementer. I'm not sure how this could be pared down any further for bots. Maybe a "boteditor" usergroup which has the 4 kinds of ways to edit protected pages listed here, though only to supplement the "bot" usergroup? But otherwise, afaict what's here is pretty much interdependent. - jc37 01:27, 9 July 2016 (UTC)[reply]
    Most discussions are allowed to be closed by non-admins. CFD explicitly doesn't even require it to be a non-contentious discussion (and the CFD bot page can't even be edited by non-admins). The minimal technical issue you are resolving is literally the time it takes for a G6 deletion to occur and that's not terrible. The remainder could be solved by actually proposing to allow non-admins to close more discussions. Frankly, I don't see why not, admins are subject to the same DRV/AN review of closures as non-admins. The only difference is that, currently, non-admins can be overturned by any admin. If you want to revise that to all non-admins or confirmed non-admins or another standard, that's another issue but that doesn't require a change in the tools. -- Ricky81682 (talk) 23:43, 9 July 2016 (UTC)[reply]
  • Here, too. I feel that any admin power appropriate to be more widely distributed should be so. Agree with Rob on page mover, also (going back a few years) rollbacker. But I don't feel that admin, jr. grade is the way to go. Moral support as well.--Wehwalt (talk) 10:38, 9 July 2016 (UTC)[reply]
  • Delete is a very powerful tool. It isn't as powerful as forbidding users from editing a page (protection) or from editing from an account (blocking), but it can remove a whole lot of useful information from Wikipedia in a second. So, I'm neither-supporting-nor-opposing here. Kylo Ren (talk) 01:08, 10 July 2016 (UTC)[reply]
  • Here. I don't favour unbundling in principle, but i rather like this proposal as a suggested exception to prove the rule. I would rather, however, if we are making somewhat radical proposals to change the problem that RfA seems to have become, make this one even more radical: Why not, since it is being set up from scratch, set some rules for RfM participants ~ they must have already have participated in three RfX discussions, or they must have been here six months, or they must have 500 edits, or some such filtering mechanism, in order to be allowed to participate. Such a gatekeeper mechanism might well function to ease the vitriol which seems to spew at RfA. I would also, since we're talking radical, set this up as a test, temporary, for say six months, to be evaluated, both to see how the RfM worked and if the pressure on admin backlogs had been reduced by the presence of moderators. The outline of the trial would be that the position would be removed without clear evidence and obvious agreement that it had been. I do, though i cannot quite support the proposal, thank Jc37 for all the thought and effort; we cannot move forward in the search for the solution to the Admin Problem without such effort and thought. Happy days, LindsayHello 05:11, 11 July 2016 (UTC)[reply]
  • Neutral. (!vote changed to oppose) I might get "squished like grape" for standing in the middle of the road, and yet I am so close to the thoughtful rationales of both supporters and opposers in this debate. On the one hand as more of a gnomelike editor, a package like this would seem to be perfect for me. On the other hand, if it is going to take a pretty-much identical community vetting process to join this user group, and since nobody forces admins to use any tools with which they are uncomfortable or just prefer not to use, then it is difficult for me to justify an unbundling of this nature. I'll have to bitt/bik/grok on it some more, so please don't leave home without me.  Wikipedian Sign Language Paine  04:51, 12 July 2016 (UTC)[reply]
  • I'll place myself here too. Moral support for ideas about unbundling. But not only is page deletion a big deal, but the proposal also allows editing full-protected pages. The latter would present the problem of moderators editing through full protection when other editors cannot. --Tryptofish (talk) 22:48, 14 July 2016 (UTC)[reply]
  • Support in theory but not in specifics. The more unbundling the better; the more we make the actual functional things that presently only admins can do back into "no big deal" again, the better. But the current draft is too much of a sprawling change that would probably just create another RfA process no easier or better than the regular one. See the proposals that lead to the file-mover, template-editor, and page-mover bits. Narrow, focused, do-able.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  17:13, 15 July 2016 (UTC)[reply]
    • I think this is where I am, as well. I think deletion should be unbundled – but it needs to be done in a non-RfA-like process, otherwise it won't work. --IJBall (contribstalk) 15:58, 23 July 2016 (UTC)[reply]
  • Comment: While I think the idea behind this proposal is somewhat good, I think the name Moderator should be changed to something else since people might confuse "moderators" with forum moderators which can lock (protect pages) and ban users (block). Feinoha Talk 16:15, 23 July 2016 (UTC)[reply]
  • What bothers me about this is that moderators will be given deletion powers, which not only raises legal issues, but also trust issues. I support the intentions of this proposal, but in practice, as has been brought up, we'll end up with (essentially) another RfA, since anyone being given deletion powers will have to be approved by the community. Colonel Wilhelm Klink (Complaints|Mistakes) 19:24, 23 July 2016 (UTC)[reply]
  • Neutral. I think this is probably going to make some tools much easier and some others much harder to reach. Do we really need to make adminship a de facto two-step process? This seems to be a step sideways from the current situation. Daß Wölf (talk) 00:03, 26 July 2016 (UTC)[reply]
  • Neutral. Unbundling is good, but I think there is a chance this proposal might make the RFA harsher. —MartinZ02 (talk) 20:42, 8 August 2016 (UTC)[reply]

Discussion[edit]

  • I still think unbundling page protection is the next step, personally. Page protection is relatively easy to understand, it's extremely visible to the point that a bad protection will be swiftly fixed, and it's a good way for a "typical" admin candidate who is interested in handling behavioral issues to get their foot in the door and show they can be trusted. It also has no privacy concerns that would cause the WMF to demand RfA-level affirmation to grant the right. ~ Rob13Talk 02:31, 9 July 2016 (UTC)[reply]
    In my experience, proposing a separate usergroup for "protect" will gain a hefty opposition, because there are those who feel nothing (or very few things) should be protected, and the block tool used instead. With the rationale being: "This is the encyclopedia anyone can edit". So they tend to want that a "protect" userright package must include "block" as well (plus related userrights). As I noted above, it may sound simple to separate the userrights, but wikipedia policy, process, and practice makes things rather interdependent in practice. But who knows, WP:CCC, after all, maybe that is no longer a concern, but I'm doubting it. - jc37 02:43, 9 July 2016 (UTC)[reply]
    I agree that the community seems to have shut down unbundling of protect. If there's any individual unbundling, I'm guessing it would be delete/block related. — Andy W. (talk ·ctb) 03:22, 9 July 2016 (UTC)[reply]
    • Also, I'll add my moral support (without the corresponding vote) as well. I urge those opposing to remain engaged beyond this one RfC. Fixing RfA is easier said than done. It's heartening to see most editors agreeing that it needs fixing, and we have made some progress recently. WP:Page mover was a huge step in the right direction. ~ Rob13Talk 02:36, 9 July 2016 (UTC)[reply]
  • As I side note, I would not oppose the creation of a user right called "limited-sysop" which contains all the flags of a sysop except "block", provided that any admin may request to swap from "limited-sysop" to "sysop" or back by submitting a request at WP:BN and waiting 72 hours. Same RfA requirements, same everything. This could potentially address the "uncomfortable" aspect that Jc37 mentioned. If editors are genuinely putting off an RfA because they're uncomfortable with the block button, then "limited-sysop" would allow them to become an admin without having to deal with it. The lack of any barrier between the two userrights (other than a brief waiting period) would prevent this from becoming the new stepping stone to sysop. ~ Rob13Talk 20:18, 12 July 2016 (UTC)[reply]
  • Propose Immediate desysopping of BU Rob13 for treating the neutral section like a discussion section.
^^^joke Muffled Pocketed 20:38, 12 July 2016 (UTC)[reply]
  • User:BU Rob13 - tried that last time and they seemed to want it this way, now you're saying you want it that way. Merry-go-rounds are fun : ) jc37 02:24, 13 July 2016 (UTC)[reply]
    @Jc37: I don't know who "they" are, but it is what it is. This is the problem with RfA reform. Even though everyone agrees it's not running optimally, no-one agrees on how to fix it. I'm willing to try just about anything so long as I don't think it will make things worse, but this doesn't fit that bill for me. I seriously doubt that any of the hardline opposers will compromise their stances when you debundle the delete button, and that means the adminship standards have nowhere to go but up since it does make some sense to have higher standards for the whole package than just a part. ~ Rob13Talk 02:32, 13 July 2016 (UTC)[reply]
  • So... if I read all this correctly, say a person is vetted by the community and becomes a moderator. Then later, if that person decides she or he can be even more helpful as an admin, he or she would have to enjoy the gauntlet again? a second time? at an RfA? or will a moderator, having been trusted once by the community, just have to ask to be adminized to receive the bigger mop?  Wikipedian Sign Language Paine  23:47, 12 July 2016 (UTC)[reply]
  • Please consider those questions rhetorical because I think the answers are clear. And to expect someone to endure what are essentially two RfAs before actually fixing the RfA process is, well, pretty much insupportable. No matter what has been said about being an admin, the fact is that admins are like captains and above in the military. So two colonels decide that a trusted lieutenant should be promoted to captain. The trick is that the lieutenant must run a gauntlet of everything from soup to nuts, they have to be set upon by all ranks, from long-trusted other lieutenants right on down to the buck privates. Our colonels' new proposal for promotion didn't get to the rank of lieutenant without making some enemies, because no matter how hard one tries, one cannot please everyone along the way as one digs in and makes the hard decisions in various venues. And then there's the domino effect: An enemy shouts very loudly about what a skank they think the lieutenant is, and viola! A waterfall of opposition pours down on the lieutenant's po widdle head. You admins want more captains to help "swab the deck"? Then take the bull by the horns, the horse by the reins, and promote the people you trust. The community trusts admins to make the best decisions possible in a number of venues, some quite difficult. Admins should also be trusted with the promotions. Sure, there's nothing wrong with the privates, corporals and such to have their say at an RfA; however, the results of an RfA should be used only as an advisement, not to make the final determination and promotion, which should be left up to admins, the (most) trusted bunch.  Wikipedian Sign Language Paine  00:11, 13 July 2016 (UTC)[reply]

When unbundling works, and when it doesn't[edit]

I've addressed this matter broadly at an essay, WP:When unbundling admin power works [originally started as a sub-thread here].  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  19:17, 15 July 2016 (UTC)[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.