Please leave your comments below. Objections, approval, or suggestions for changes or extensions are all welcome. Dcoetzee 11:59, 16 November 2011 (UTC)[reply]

The tools that an editor would most likely request are also the ones that the community considers the most sensitive and that drive the most concern at RFA. My understanding is that the ability to Block and to Delete are considered the most dangerous abilities to hand out, followed in a distant third by Protection. Yet I think 90% of requests for tool access will end up involving at least deletion, in the case of NPP, vandal patrolling and those active at deletion venues, and in the case of vandal patrolling, they will have a strong need for block, and may also request protection for semi-protect. Now it is true that we can just apply stricter scrutiny when those tools are requested, but as we do so, we turn it right back into the mess RFA is in now.

The only place this would really help is in the really edge cases where someone is highly active in an unusual and specialized niche that is uncontroversial, the only that come to mind would involve editing protected templates and/or edit notices. So I would ask, what are the other types of requests envisioned by this proposal that would not include deletion or blocking and be subject to RFA like scrutiny, and how often would they end up being made? Monty₈₄₅ 14:32, 16 November 2011 (UTC)[reply]

My response: it is true that block and delete are both dangerous tools that one would not grant lightly on an indefinite basis. However, I believe granting them on a trial basis to a user in good standing with an immediate need for them, and removing them immediately in case of abuse, is a much less risky proposition. Not only does this directly limit the damage the user could cause, but it sets up incentives to discourage abuse (the user wishes to continue to participate in the task they requested the tools for, and is aware that they could easily lose the tool if misused). This is why I centered my example around delete, which is seen as a dangerous tool. And yes, I would expect vandal patrollers to request both block and protect (as already noted). Dcoetzee 19:42, 16 November 2011 (UTC)[reply]

• Wikipedia:PEREN#Hierarchical_structures.

Plip!

. That's all I have to say on this subject. Beeblebrox (talk) 17:20, 16 November 2011 (UTC)[reply]

• • I am of course familiar with WP:PEREN. Not only does that entry openly contradict itself ("Can't be done! Already done!"), but the reasoning is easily refutable:

    If we can't trust people to use their tools sensibly, they don't become admins

  • I already respond to this on the page (trust in one area does not necessarily imply trust in another; trust in a particular tool should be based on experience with that tool). Moreover, in my proposal there are no administrators in the traditional sense (only persons who have acquired a certain set of tools). It's certainly not the case that "anyone we can trust with rollback we can trust with all the tools" - this is a simple extension of that idea.

    A "partial admin" process would at least double the already considerable frictional effort expended at WP:RFA, as users debate who gets full sysop powers versus who gets only partial abilities.

  • As argued in the proposal, the discussion effort expended would be considerably less, because the stakes would be lower (we don't have to be as careful and thorough when handing out a subset of powers on a trial basis as we do when giving out the full package indefinitely - the trial component, which is novel, is critical here). Additionally, my proposal dispenses with people getting "full sysop powers" altogether, except if they happen to eventually acquire them all. Dcoetzee 19:28, 16 November 2011 (UTC)[reply]
    • Added some responses to this to the page. I do realise the importance of directly addressing objections to prior similar proposals. Dcoetzee 20:06, 16 November 2011 (UTC)[reply]
    • After further thought I have struck the idea of eliminating RfA at the present time. Dcoetzee 16:26, 17 November 2011 (UTC)[reply]
  • I agree with Dcoetzee here. The rebuttal at PEREN is pretty weak. I think, by suggesting such a measured approach to access to administrative tools, this proposal is a great improvement on earlier proposals with a similar goal. — This, that, and the other (talk) 01:10, 17 November 2011 (UTC)[reply]
  • Although you say above that 'Additionally, my proposal dispenses with people getting "full sysop powers" altogether, except if they happen to eventually acquire them all.' Is this suggesting that RFA would be done away with? It still produces new admins, so I see no reason why it should be abolished. I see this proposed process as a parallel, for users who do not want all the tools, or who believe they would not pass an RFA on the basis that they do not have broad experience in many different areas. — This, that, and the other (talk) 01:31, 17 November 2011 (UTC)[reply]
    • Thanks for the feedback - see the new section "Does this supplant or supplement RfA?", which I think addresses your concerns. Dcoetzee 16:26, 17 November 2011 (UTC)[reply]
• For whatever it may be worth, I 100% support unbundling the tools. Apprenticeship for each tool is a reasonable idea but not nearly as important as eliminating the idea of "one size fits all" adminship. A person may be very well experienced with, say, page deletions from their experience as an editor (nominating/tagging pages, participating in discussions) and thus well-prepared to assume the deletion tool, while having little preparation for blocking. Or vice-versa. --RL0919 (talk) 01:56, 17 November 2011 (UTC)[reply]
  • I wonder how existing admins would be viewed then. Would it reinforce the stereotype that we're superusers because we have the entire toolset, while the 'lower classes' struggle to prove themselves with each tool so that they may 'rise up in rank'? Would you still be in support if the proposal included apprenticing existing admins for each of their tools? -- œ^™ 08:10, 17 November 2011 (UTC)[reply]
    • That's part of the reason why I would want this to remain in parallel with RFA, so that current "total sysops" don't become an elite class. Of course, one mustn't worry about this sort of nicety too much: this tool apprenticeship proposal, in itself, deserves merit. — This, that, and the other (talk) 08:59, 17 November 2011 (UTC)[reply]
      • Yes, I agree that retaining the current RfA process at least for now is important for ensuring a smooth transition. Dcoetzee 16:26, 17 November 2011 (UTC)[reply]
• It'd work on principle, but in practice it would establish the very sort of social hierarchy which most of us oppose. By unbundling the sysop tool set, there'll be more haberdashery and the rights will be viewed as prizes by those haberdashers and it'll reinforce the elitism which does have an active presence amongst our admin and user corps (the current mentality that I can observe is that the more individual rights there are, the more users will want to apply for them, the standardised user rights are already frequently sought out by the unready, imagine what the media of requesting these "mini-admin" rights will be like).

I'm that certain users show exemplary knowledge of certain areas of Wikipedia's administration, but that will be problematic as admins are expected to assist wherever they can, as that is their duty, to assist. By unbundling the rights, we'll have users who are essentially proving themselves unable to do any work outside of their area(s) of comfort/expertise, this would create a problem as these users would then NOT need to learn about other areas other than their area(s) of expertise.

Admins are specialists but they're also expected to lend an extremity wherever possible, their primary job is to maintain the cleanliness of the encyclopedia where standard users are unable to do so, blocking etc. Having a user right dedicated solely to blocking, while seemingly a good idea is pointless, that user can do nothing more, which would effectively limit their usefulness. Furthermore, it would add to the cruft of bureaucracy that is present in our requests for permissions pages and there would be a larger number of overall individual requests, I know admin promotion rates have been steadily declining, but RfA has not had as much of a problem with curbing requests from the unready, but the general daunting nature of running is a deterrent enough. Unbundling the rights would lessen the workload and the responsibilities attached, thus making these individual RfP pages prime targets for haberdashers.

I know I'll probably be criticised for opposing this system, as I advocated such a system in the past, but time on Wikipedia and observing the habits, tendencies and general mentality of haberdashers has made me see there would be no hope for such a system and would limit the efficacy of adminship, each department occasionally has an overlap in duties and may be required to collaborate, that would require several admins at most, but with this system it'll require several users OF THOSE INDIVIDUAL rights, that would create more work than is necessary. —James ^{(Talk • Contribs)} • 9:03pm • 11:03, 17 November 2011 (UTC)[reply]

Hi M.O.X., thanks for your feedback. To address some of your specific points:

there'll be more haberdashery and the rights will be viewed as prizes by those haberdashers

I do expect many requests from users who are unready. This is why I've included the list of requirements for a trial period, evaluated by consensus discussion, which I've now tried to make more explicit. I believe these will filter out "haberdashers" effectively.

admins are expected to assist wherever they can, as that is their duty, to assist. By unbundling the rights, we'll have users who are essentially proving themselves unable to do any work outside of their area(s) of comfort/expertise [...] Having a user right dedicated solely to blocking [...] that user can do nothing more, which would effectively limit their usefulness

The overall number of users having partial rights would be much greater than the number of admins, enabling them to do more work overall, although each individual may do less. Also, as I'm not presently eliminating the RfA process, there would still be admins with a "duty to assist".

it would add to the cruft of bureaucracy that is present in our requests for permissions pages and there would be a larger number of overall individual requests

It would - the bureaucratic overhead is nontrivial. In return, we get more users with more tools to help complete more work in other areas. I think it's a net win.

each department occasionally has an overlap in duties and may be required to collaborate, that would require several admins at most, but with this system it'll require several users OF THOSE INDIVIDUAL rights, that would create more work than is necessary

You are right that some collaborations would require more individuals to succeed, increasing communication overheads. However, most work is contained to limited areas, and I think overall efficiency would increase.

These are reasonable concerns and if I'm missing something still please explain. Thank you! Dcoetzee 16:41, 17 November 2011 (UTC)[reply]

I still have my doubts, having increased collaborations in contrast to the controlled number we have now, to me, doesn't seem like a benefit, if the admin package will exist in conjunction with the individual rights, I believe there should be bundling. The ability to block users, move media and categories and page protection should be bundled, those are basic admin functions and the ability to function with these rights is exemplary of an admin's ability to carry out simple maintenance, notwithstanding the occasional extraordinary incident. Instead of that, you could use certain tools from the admin package and put them into their own package (eg. blocking and page protection, for the anti-vandal users). —James ^{(Talk • Contribs)} • 12:49pm • 02:49, 18 November 2011 (UTC)[reply]

I'm a little unclear about your explanation here. I agree that certain sets of tools are useful for certain tasks, like blocking and page protection for anti-vandal users, but because the set of potential tasks is very large and fluid, I think it's more flexible to permit any set of tools to be requested. But I don't see why it'd be useful to bundle block users, move media, etc. The primary purpose of the system is not to provide evidence that you can capably function as an admin (that's a secondary benefit) - the primary purpose is to help people who have an immediate need for a tool to get work done. Does that make sense or am I missing something? Thanks again. Dcoetzee 09:43, 18 November 2011 (UTC)[reply]

No, that was poor wording on my part. The bundling of rights would mean that the simple tasks can effectively be handled by anyone and the specialist tasks handled by the specific users with the concerned rights, I understand that the reasoning behind this proposal is that admin workload is now somewhat overburdened and that there are more than capable users who are afraid of RfA or the harsh standards of RfA would mean they'd not pass, however, the problem I see is that this would make adminship a triviality and the immediate ramifications of unbundling the package would be that we'd have a surplus of users who effectively cannot work outside their chosen departments, increased and highly trivial collaborations and an increase in overall workload, to me this outweighs any inherent benefits. —James ^{(Talk • Contribs)} • 8:58pm • 10:58, 18 November 2011 (UTC)[reply]

Okay I think I understand that. My response would be that it all depends on how it's used in practice. There will be some users who get a tool or two for a single task and then stop, while other users would acquire multiple tools before eventually shooting for a full RfA. The experience would help users who are intimidated by RfA and would never run otherwise to eventually go for it. Which type of user turns out to be more common is difficult to anticipate. I don't think availability of tools by another path would make adminship trivial, partly because adminship includes a large number of tools that would be quite taxing to accumulate individually (perhaps some won't be available via apprenticeship at all), and partly because adminship (for better or worse) includes a sense of status and authority that partially empowered users would not possess to the same degree. Dcoetzee 17:37, 18 November 2011 (UTC)[reply]

Hm, I see. In a way you've inadvertantly supported my position, adminship does contain an enumerous amount of tools, individual acumulation while taxing would be easier to achieve than to run for RfA straight-out, while it would give users the experience and knowledge necessary, this can be achieved without the need for the unbundling of the package, apprenticeship, just seems like Admin Coaching but without the limitations. From my perspective it just seems like this encourages users to aim lower than they should be, adminship is daunting for a reason, that is to deter the unready from running and to encourage people to serve the community the best they possibly can and show that the tools would assist their work.

Having specialist rights has already been criticised, look how much the admin package has been de-bundled so far, that in itself has attracted scrutiny and criticism, the proposal is good in principle but from what I can see it would only encourage users to aim for second-best, it would create more work and add to the bureaucracy we already have, while you have dispelled some of my doubts I can't see this system working. This proposal is haberdasher-fodder. —James ^{(Talk • Contribs)} • 11:03am • 01:03, 19 November 2011 (UTC)[reply]

I think part of what makes the proposal unattractive to people looking to game the system is the sheer amount of work involved in acquiring a single tool, and the continual scrutiny every time they make a request. It requires months of effort both before and after the initial request just to get one tool permanently, and if they subsequently abandon use of the tool, this would be noticed in future requests for other tools. In short, I think forcing periodic consensus discussion can do a good job of detecting haberdashers. Re "encourage users to aim for second-best", I don't think it would result in less people running for administrator, but actually more people, since people with tool experience would feel less intimidated by the role and the RfA process and have more evidence to support their case. This is difficult to predict without running a trial though. Dcoetzee 18:17, 20 November 2011 (UTC)[reply]

Please forgive me, for just a moment, going off the topic of this proposal - so I can explain the angle I'm coming from. I'll be as brief as I can be, and come back to this proposal after a few sentences;

My view of "The trouble with RfA", in brief: Adminship is a big deal, because it's so hard to remove it. If it were much easier to remove, we wouldn't be so super-cautious about handing it out.

We block users pretty quickly - e.g. for a username vio - and we say "hey, this is why you're blocked - it's nothing personal; let's just discuss it and sort things out"

Imagine that for SysOp - "Hey, I've removed your SysOp status, because I noticed a couple of dubious deletions that didn't seem to meet CSD criteria. So, let's discuss them, and if we sort it out, you can have your SysOp back"

For similar reasons, I think 'admin' should be renamed 'janitor'. It's become far too much a 'badge of honour'. Even most admins seem to think that they've got special authority to make decisions in e.g. closure of consensus discussions. They haven't.

Having said that, I doubt it'll ever happen. In part, because most people who make such decisions are either admins, or people heavily involved in the 'pipework' (non-content) parts of the wiki. Sadly, because those people deal with blocks/socks and nastiness all the time, they naturally forget we're here to build an Encyclopaedia.

</gets off soapbox...>

So - if that is unrealistic / unlikely to happen, then perhaps some trial-system of temporary/partial SysOp is a way forward. A hell of a lot of us think some change is needed...so, perhaps we can give this system a try? Even just a very limited run (few people), and with extra-careful-watching by some well-respected admins/CU/'Crat-folks. For example: We could try it out on just 6 people for a month, and could allocate a couple of mentors to check every single action they take. Net result of that could be 6 new admins before Xmas.

The key stat, to me, is: New admins: 2007, 408; in 2008, 201; in 2009, 119; in 2010, 75. 2011, so far, 46. Surely this is a worrying trend. Hence, even just another few via an attempt at something new would be progress.

Of course, there's a lot of problems and complications with this proposal - I'll mention a few first thoughts, below. But hey - it's a wiki - problems can be fixed.  Chzz  ►  08:21, 17 November 2011 (UTC)[reply]

How many potential set/s of tools are there? Are any of them possibilities? Seems like it could easily get complicated. For example, at a quick glance right now, in addition to the more obvious examples of delete/prot/block, I could use;

• "moodbar-admin" (Alter visibility on the feedback dashboard) - I've been actively involved in work on that extension, and can easily make a case for me to see, and hide, comments
• "edituserjs" - I'm frequently trying to help others sort out problems with their script; this would save lots of hassle saying "try removing that third wiggly-bracket", etc.
• "move-subpages", "suppressredirect" - because I very often help people manage userspace pages, and constantly have to ask admins to tidy up
• Add groups: Confirmed - to make it easier when I help new users, and they need to upload a file or move a page

I'm just showing those examples to indicate some of the potential complications of this idea. Personally I'd prefer to KISS and allocate SysOp, and trust the carefully-watched-users to only use what they'd been told they could use; but, I understand if that might be less acceptable.

One particularly problematic user right is, (deletedtext) - View deleted text and changes between deleted revisions - because I can imagine a lot of people finding that handy, but there's probably no way to evaluate if they use it responsibly or not; it won't actually show up anywhere (unless they copy/paste something). So if a user were granted that for a few months, how could we decide if they should keep it?

Re. the Responses to anticipated objections, WRT "If we trust a user enough to give them one tool, we trust them enough to give them all of them."

-this is pretty key, I believe. The refutation overleaf says, Trust in one area does not necessarily transfer into other areas (consider the aphorism "I trust my bank with my money and my brother with my children, but not vice versa")

Well...consider this: if I trust my brother to borrow my hammer, my power-drill, my screwdriver, etc. then it's a lot more simple to give him a key to my shed - per KISS. After all, if he breaches my trust, I can just take away his key.

I can imagine difficulty in telling who-does-what, and indeed who is allowed to do what; unbundling does have a lot of potential for instruction-creep.

Another example overleaf talks of a user undeleting, but unable to delete - that sounds problematic, as they cannot rectify their own errors.

 Chzz  ►  08:21, 17 November 2011 (UTC)[reply]

You say above (after your descent from the soapbox) that part of the trouble with admins is that it is so hard to revoke sysop-ship. But your example above refers to "taking away the key" of the mischievous brother, without any trouble. This seems a contradiction to me: one good reason not to give a sibling (or anyone) a key to one's garage is, once they have it, it can be very hard to get it back from them again, especially if they are up to mischief. They aren't likely to willingly give it up: nor are admins who bend the rules.

Re rectification of one's own errors, a normal user has to rely on CSD G7 to get a page deleted after it was created in error. A "deleter" deleting and then desiring to undelete could go through WP:REFUND just like any other user, and an "undeleter" wishing to delete would of course use CSD tags. I don't see that as being a huge impediment to the proposal, particularly given the suggested trial period would help to weed out candidates who lacked full maturity and responsibility.

Also re deletedtext: Alongside the problem you point out with granting it alone, I don't think the WMF would like it if non-admins were given this permission. So this one might have to stay out of this plan for the moment.

As you say, this could easily get complicated, but where are we now? Rollbacker, file-mover, accountcreator, edit filter manager, importer, checkuser, oversight, and even reviewer and autopatrolled (obviously not so important at the moment)... a few more would hardly hurt...

Many of the points you mention are certinaly worth keeping in mind. — This, that, and the other (talk) 09:14, 17 November 2011 (UTC)[reply]

Re. key - sorry if the analogy wasn't great, but...on my shed, it's trivially simple and cheap to change the (pad)lock.  Chzz  ►  09:41, 17 November 2011 (UTC)[reply]

Hi Chzz, thanks for your feedback. I have blatantly ripped off your idea of a limited trial of the process, something I had not even considered but which is absolutely necessary. Responses to your comments:

Adminship is a big deal, because it's so hard to remove it

While I make no attempt to address this issue for admins, note that tool trials in tool apprenticeship are subject to probation (tools can be removed in case of misuse, then later restored after the user learns their lesson and makes a fresh trial request).

How many potential set/s of tools are there? Are any of them possibilities?

There would simply be a user group associated with each user right. This would enable us to easily grant any combination of tools to any person, and allow a person to accumulate a variety of seemingly unrelated rights over time such as the ones you listed. Note also, I'm presently proposing this as a supplement to RfA, so in practice a user who participates in a diversity of areas would probably start out with just a 2-4 tools, then jump to RfA there.

One particularly problematic user right is, (deletedtext)

This is indeed problematic. It is technical limitations that prevent us from monitoring use of this right, and in the long run I would hope for software changes that introduce auditing (logging each use of viewing deleted revisions). In the short run, I would only introduce this right in combination with a right that obviously requires it, such as undeletion, which can be monitored.

if I trust my brother to borrow my hammer, my power-drill, my screwdriver, etc. then it's a lot more simple to give him a key to my shed - per KISS. After all, if he breaches my trust, I can just take away his key.

This is partly why at the present time I'm not suggesting eliminating RfA. If I've watched my brother use the circular saw and power-drill for a while with supervision, and he knows what he's doing, I might then develop enough confidence to give him the key to the shed.

they cannot rectify their own errors

Replied to this already in the objections - it is a bit awkward to seek help from others to rectify your own errors, but I expect these requests to be processed quickly.

Thanks again and please let me know if your concerns have been addressed. Dcoetzee 17:15, 17 November 2011 (UTC)[reply]

Support the general idea. As it becomes more specific I may have questions or comments about specifics. Pine^talk 09:10, 17 November 2011 (UTC)[reply]

Requirement Provided the user is in good standing and has a need, they receive the tool on a trial basis

I'm concerned that it might attract a very large number of new-ish/relatively inexperienced users, which could create considerable - and probably pointless - stress. So, should there be some specific requirements? e.g. been around for <xx months>, at least <xx> <mainspace? any?> edits? Of course, exceptions could be made...but I'm mostly thinking of avoiding lots of NOTNOW candidates.  Chzz  ►  10:50, 17 November 2011 (UTC)[reply]

I have added the requirement "To the greatest extent possible, the user should be active and have sufficient experience in the area in which they plan to use the tool." This is intentionally vague - I expect each area to formulate its own specific requirements over time. I don't think general requirements make a lot of sense, since different areas use different metrics. Dcoetzee 17:19, 17 November 2011 (UTC)[reply]

After or shortly before the end of their trial, the user can file a request to retain the tool permanently

How would that be decided? Who would make the decision? Would there be a certain opportunity for any others to object?  Chzz  ►  10:50, 17 November 2011 (UTC)[reply]

I can see this being like an entry at WP:RFPERM, except maybe open for 7 days, to allow for objections and discussion; however, AFD-style consensus and RFA-style !voting are probably not necessary. I would imagine that bureaucrats would make the decision, after perusing the user's logs; but I'm not sure about this. — This, that, and the other (talk) 11:10, 17 November 2011 (UTC)[reply]

I have proposed an AfD-style consensus discussion. I think AfD is a great model here because it invites community input, takes load off decision makers (here, our small number of bureaucrats), but most discussions are short and straightforward. Dcoetzee 17:19, 17 November 2011 (UTC)[reply]

• Comments Assuming that current admins would remain as they are we have a mildly hypocritical situation: "Old money" verses "Nouveau riche".
  • Admins come and go. If no more can be made then admins only go (retirement, real life reasons, drama etc.). It is possible that we could end up with no admins. With no admins, who decides who gets what tools?
    • There is a possibility that too few or even no users could have use of any particular tool or set of tools at any one time for needed work to be done in a timely fashion. It is further possible that no users at all have use of some tools. Who would fix it and how?
  • At present admins have a position of responsibility that they are publicly answerable about. Their position is not to be taken lightly. The potential for abuse is thus greatly reduced as the rights are special and they want to keep them. If tools could be aquired by anyone at any time they could feel a little disposable. The family silverware and crockery may be cherished by generations but, why cherish paper plates and plastic cutlery?
  • The workload of admins with the power of oversight (those who dish out the tools) would be potentially too great for the requests to be dealt with in a timely fashion (assuming there are any pseudo admins left with the power to dish them out). We might find that little administration is being done since the few who can, spend all their time answering requests for tools.
  • I know this is covered in the previous posts but it's worth another mention: this would allow a whole new level of vandalism that could only be fixed by select individuals. If all vandalism could only be cleaned up by some particular kind of admin, we could kiss this project goodbye.
  • Finding admin to get a job done is at present very simple. It could be a great deal more difficult to find the right kind of admin to get things done.
    • A user could find a pseudo-admin to do some task and then the pseudo-admin may need to find another with different tools who may in turn need to find another. The leg-work would be time consuming and wasteful.
• At present admins are peer reviewed by a dedicated team who don't take the position lightly. Those few who get through are regarded as being pretty much unquestionable worthy. If we reduce adminship to a set of temporary add-ons, we could find that fewer and fewer take seriously the guardianship of the encyclopaedia.
• Summary: Some tools could be dished out in this fashion without causing too much trouble but not all. However, I think this idea should only be considered to run along side the present system so as to not degrade or trivialize positions of authority. It might prove useful to real-admin to have a record of use of certain tools dished out to users if they were to apply for real-adminship (just as use of rollback would be) later.
  • Analogy: I wouldn't want the police force to be created and maintained this way. We would end up with vigilante-ism on a grand and uncontrollable scale. I like my police to have gone through thorough training, to have been tested and vetted by qualified uber-officers, and to be constantly monitored by their peers and the public. I don't want my police to be a rag-tag disperate group of wannabes with truncheons looking to acquire guns. fg 13:23, 17 November 2011 (UTC)[reply]

Hi Fred, thanks for your feedback. First of all, based on feedback by yourself and others I am currently proposing this only as a supplement to RfA. Other comments:

With no admins, who decides who gets what tools? [...] The workload of [...] (those who dish out the tools) would be potentially too great for the requests to be dealt with in a timely fashion

Anyone can participate in request discussions. They are closed by bureaucrats. If the load becomes too high for bureaucrats, a recursive approach can be taken, in which the right to grant rights for tool apprenticeship is granted via the tool apprenticeship process to existing admins who are experienced in tool apprenticeship discussions.

• Potentially disastrous, blind leading the blind. Also the only re to my re that almost touches on the main problem, how many have what tools and when? We could hypothetically run out of "pot scrubbers" or "hammer wielders". Although I do now see (from your comment above) that you are now not proposing we replace administrators with have-a-go-heroes. fg
  • Yes, I've reframed this as a supplementary process. While I hope that we would always have enough users interested in each right/privilege, it is possible a small number of them would be very unpopular for whatever reason (e.g. only useful in specialized situations). This is one reason to keep the full sysop package around. Dcoetzee 18:58, 17 November 2011 (UTC)[reply]

If tools could be aquired by anyone at any time they could feel a little disposable [...] I don't want my police to be a rag-tag disperate group of wannabes with truncheons looking to acquire guns.

As is now emphasized, people on their tool trials are under probation. Although they are easier to obtain, tools can be rapidly revoked for misuse. I consider this acceptable because all tool actions (unlike police actions) are easily reversible.

this would allow a whole new level of vandalism that could only be fixed by select individuals

For most types of vandalism only a couple tools are required (protection, blocking, rollback). Some types of vandalism may require other tools (deletion for attack pages and move vandalism), but the person user the vandal can merely tag these pages for speedy deletion, and have another user delete them. Deletion is not an urgent matter.

• Scenario: User acquires tool to apply protection to pages, either with the intent of misuse or because of mental breakdown, personal tragedy, Wikidrama (whatever reason) etc. suddenly takes to abuse. They (by use of a simple bot) replace the text on 10000 pages with "F@#K WIKIPEDIA" in 500px text and then protect the pages. The only people who can clear it up are admin-like. This is fine if an admin-of-sorts or a real admin is around who actually has the tools needed to nuke the edits. fg 17:59, 17 November 2011 (UTC)[reply]
  • In this scenario actually any user with the protect right and access to a suitable bot could reverse the damage. The bot could be supplied by any trusted user. Nuke isn't so helpful for users who happen to also have legit edits that we want to preserve. But yes, admins would still be around. Dcoetzee 18:58, 17 November 2011 (UTC)[reply]

It might prove useful to real-admin to have a record of use of certain tools dished out to users if they were to apply for real-adminship

This is indeed an advantage of running the tool apprenticeship along RfA, which I have noted in the proposal.

A user could find a pseudo-admin to do some task and then the pseudo-admin may need to find another with different tools who may in turn need to find another

I do expect higher communication costs in some situations. I expect overall efficiency to increase due to having a much larger number of partially-empowered users available to help with the workload.

I hope this addresses your concerns, but please let me know if you have other feedback. Thanks! Dcoetzee 17:35, 17 November 2011 (UTC)[reply]

I've been in total support of the idea of unbundling admin tools for quite some time, so I like the idea of tool apprenticeship. Would this (excuse me if I've missed it somewhere!) run alongside some kind of tool-mentoring? In real life, apprentices work alongside / under the supervision of a journeyman or master in the same trade, and I think this might be a good idea. Pesky (talk …stalk!) 17:39, 17 November 2011 (UTC)[reply]

Hi Pesky, thanks for your comments. I've been reluctant to propose mandatory tool mentoring, although it is a splendid idea and one that I had in mind, because I fear the overhead of an assigned mentor responsible for continuous monitoring of every apprentice may be substantial. I've been going for the more ad hoc notions of probation (if you mess up and someone notices, your tool can get revoked) and review (when you come back for your next request, your logs are reviewed at that time). However there's no reason not to have voluntary mentors, and I would support mandatory mentors for problematic users. I haven't written any of this up yet but will give it further thought. Dcoetzee 18:01, 17 November 2011 (UTC)[reply]

Getting together a list of people who'd be willing to be mentors in specific areas would be good. Then apprentices could hand-pick a mentor from the list. Pesky (talk …stalk!) 18:20, 17 November 2011 (UTC)[reply]

Support but I don't really understand why tool should be automatically removed after trial, however it looks like role based security model which is rather useful for this site, explanation: having more permission sets would make it easier to give one access to the tool they exactly need while there wouldn't be need for such restrictions as now for whole sysop bit, I myself needed a single permissions once (global confirmed) unfortunately "lowest" permission including this is a global rollback, which I wasn't considered trust-worth enough for, other example are people working on AFC who need to perform tasks like deletion or edit of some protected template very often. Petrb (talk) 20:15, 17 November 2011 (UTC)[reply]

Hi Petrb, thanks for the feedback. The reason for removing the tool after trial is that it forces the user to go through a review if they want to get the tool permanently (or for a second trial). Besides offering them direct feedback on their usage, this also makes it more likely they'll receive the tool the first time around, since people are more willing to give someone a chance for a limited time. I forgot about editprotected, I think I'll add that to phase 1 trial. Thanks! Dcoetzee 09:27, 18 November 2011 (UTC)[reply]

According to previous comments where users were concerned about damage possibly caused by this I think it would be necessary to review nearly everyone, thanks for explantion, it makes sense Petrb (talk) 10:24, 18 November 2011 (UTC)[reply]

Just my two cents: In short, I don't think it is a good idea. Many technical-related reasons have been given in past discussions, so I will only mention the social ones: growing into adminship requires learning about various policies. Granting just one tools subset to a user we encourage them to specialize in this particular category and not try to match criteria for adminship. Also, on a more general level, adminship should not be a big deal. It does not require high-level technical skills at all anyway. Therefore, clearly users who have not passed RfA are not yet approved by the community not for their lack of knowledge or technical skill, but rather for not being proven and trustworthy. Giving them the selective possibility to delete/protect/block/etc. is probably not such a great idea then. Finally, apprenticeship is about learning from somebody who already mastered some lore, and it works. Just giving tools may, paradoxically, lead to less supervision and less learning :) Pundit|utter 22:26, 18 November 2011 (UTC)[reply]

Hmmm. I've considered a mandatory mentoring component, do you think it would improve the proposal? I want to avoid giving the impression that this is just about learning how to use the tools on a technical level - it's also about learning related policies in a hands-on way, and about exhibiting responsibility given access to dangerous tools. I also think a system with less discussion would be an attractive interim option for users who are good RfA candidates but don't yet feel ready to run. Overspecialization is a concern, but I tend to think the degree of specialization of a user is driven primarily by their interests. I'm speculating at this point but that's why I hope for a trial to help answer this kind of question. Dcoetzee 22:50, 18 November 2011 (UTC)[reply]

You might want to consider a mock trial to work out and study how well requests for tools could be handled. Since no tools would actually be handed out everyone involved would be simply playing along like those paramedic training days with the volunteer corpses. fg 22:58, 18 November 2011 (UTC)[reply]

You're right that all this is just speculation. I'm just not necessarily persuaded if adminship is scalable in the sense that I, for instance, either trust a person to be a good admin or not (and this trust applies to all tools in the administrative arsenal). I agree, of course, that such apprenticeship would help in developing more confidence in good RfA candidates, and also probably provide them with useful cred for the RfA itself. Yet, deep down, I don't see the significant added value component over the regular mentorship model already in place. Pundit|utter 00:31, 19 November 2011 (UTC)[reply]

You say that "Granting just one tools subset to a user we encourage them to ... not try to match criteria for adminship." There is no reason why tool apprenticeship should lead to adminship in all cases. A deleter, for example, may have no desire for other tools, and might not be interested in becoming an admin. Keep in mind that this proposed process would attract other users (particularly those without a broad range of experience in many different areas), not just those who have applied for RfA and failed. — This, that, and the other (talk) 02:03, 19 November 2011 (UTC)[reply]

• Btw, instead of selecting tools for limited adminship, one COULD consider probationary periods for people (not)passing RfA marginally. E.g. in case of somebody with 75% support, and a group of admins vouching and guaranteeing supervision, this person could get a 3-month adminship extended to regular edminship without a vote, just by approval of the mentors. But I don't believe that this idea could go through in the community :) Pundit|utter 01:10, 19 November 2011 (UTC)[reply]

There are quite a lot of people (myself included) who just don't want the full admin bit, for one reason or another (or many reasons). If someone were to nominate me for adminship, I'd decline it; but if it weren't possible to decline it I'd oppose myself on the basis that I don't need the whole mop! However, if people could have unbundled tools to apply in their own specific areas of choice / expertise, it would certainly reduce the workload on the full-admin types. We may want to have more active full-admins, but specialists are certainly not to be sneezed at just because they are specialists. To go back to the police parallel, they have all kinds of specialists, too - computer experts, scene-of-crime experts, you-name-it experts. What results is teamwork. Nothing to stop tool-apprentices applying for full adminship if they want to, at a later stage.

@Dcoetzee - you say that "over-specialisation is a concern" - why on Earth should it be? Consider your local large hospital.. It's crammed with people with extremely narrow areas of specialisation; neurosurgeons, orthopaedics surgeons, dermatologists, internal medicine specialists, plastic surgeons, cardiac surgeons ... the list is extensive! And because they specialise, they have extensive practice, experience and expertise in their own field. And they can work as a team (and often do), as well. I have to say I'm far happier about the idea of my ace neurosurgeon operating on my neck than I would be about the idea of my local GP (general / family practitioner) doing it! Pesky (talk …stalk!) 09:36, 19 November 2011 (UTC)[reply]

I haven't thought that there may be a large part of people not aspiring to adminship because of too many tools that come with it. If it indeed is so, the proposal makes quite a lot of sense. The comment about over-specialization is applicable only if we assume that limited adminship is just a step towards full status. Using your metaphor, to become a surgeon you still need to get your education in all areas of medicine. Pundit|utter 14:54, 19 November 2011 (UTC)[reply]

Thanks for the feedback - I agree that some users will definitely want to specialize and have no interest in becoming an admin, and I think this proposal will be attractive to them, so I revised a bit to emphasize that possibility. The reason I say overspecialization is a concern (as opposed to specialization, which is good) is that too much specialization could lead to requiring more people with more overhead to get certain tasks done. However, I think there will always be enough "general practitioners" (admins) to work on those cross-cutting problems, and that creating specialists to target the enormous workload present in limited areas will increase overall efficiency. Dcoetzee 15:24, 19 November 2011 (UTC)[reply]

Well, admins often have narrow specializations, too, but it is just up to their choice :) Pundit|utter 15:38, 19 November 2011 (UTC)[reply]

The obvious answer is to do what we already have with OS and CU - have lists of specialists, and a list of GPs. :o) Pesky (talk …stalk!) 22:26, 19 November 2011 (UTC)[reply]

Could you please create a list of tools which would be allowed to users? Probably we could list there also recommended requirements / trial time for each of them. Thanks Petrb (talk) 12:15, 20 November 2011 (UTC)[reply]

Here is my proposal:

Requirements:

Divided to two levels

2000 non automated edits
account old at least 60 days

2500 non automated edits
account old at least 80 days
no conflicts or edit warring

Permissions:

• Block other users from editing

User should be active in antivandalism activities and match level B requirements

• Change protection levels and edit protected pages

Users should be established as editors and should prove need to for a tool, be active in dealing with semi-protected edits etc and match level A requirements

• Delete and undelete specific revisions of pages
• Delete pages

Both should be given together, probably to people active in afd, csd, patrollers etc and match level B requirements

• Edit other users' CSS files
• Edit other users' JavaScript files
• Edit the user interface

All together - to people with technical knowledge assisting on support boards / dealing with updates of things like blacklists, or scripts, even helping to people whom own scripts are broken or causing harm

and match level A requirements

• Not create redirects from source pages when moving pages

For people in afc project, or others who need it, should be matching level A requirements

• Undelete a page
• View deleted history entries, without their associated text
• View deleted text and changes between deleted revisions

For people dealing with undelete requests from others and match level B requirements

Others:

• Mass delete pages

IMHO no need to give to anyone

maybe you could insert your ideas or regroup it, thanks Petrb (talk) 12:25, 20 November 2011 (UTC)[reply]

Hi Petrb, I appreciate the thought you've put into this, but I want to deliberately avoid specifying this type of detail in the proposal. To clarify:

• I want to avoid bundling together rights into "sets" because it makes the system more inflexible - I want to instead be able to grant any combination of rights. This way it can handle not just common tasks, but all possible tasks that might arise in the future. Users can request multiple rights as needed, and common requested sets are expected to develop organically without technical intervention.
• Although I would want to make all of these rights available eventually, I'm excluding most of these rights from the process trial in order to simplify the trial. I don't think they're all needed to demonstrate whether the idea is viable or not.
• I'm avoiding specific criteria on the people making requests because I think a short consensus discussion is more capable of making that evaluation. Such criteria might be developed later as a way of managing load, if too many newbies are requesting.

Does this make sense? Thanks for your feedback. Dcoetzee 17:54, 20 November 2011 (UTC)[reply]

I like some of the ideas presented here. I would like to see the B set requirements be similar to RFA's requirement for six months of activity, 2000 non-automated edits, and clean or minimal block history. I agree with Dcoetzee that this level of detail could be designed after the trial is complete. Pine^talk 04:34, 25 November 2011 (UTC)[reply]

So I propose that we have some set criteria to obtain this proposed userright. So I propose:

• 5000 edits
• 25 log entries
• Got admin coaching

Optional, but prefered:

• Has sysop access on 1 or more wiki (including test-adminiship on incubator)

Also, I propose that it will not include "unblockself", since it may be nessesary to block the user, and that the rights expires after 1 month.
~~Ebe123~~ → report on my contribs. 12:53, 20 November 2011 (UTC)[reply]

Actually I think that different requirements could be for certain permissions, see my post Petrb (talk) 13:22, 20 November 2011 (UTC)[reply]

It seems like your proposal misses the fondamental nessesary criteria and not only the AfD people need the suppressredirect right. I sometimes need it but not for AfDs, typos in pagenames. ~~Ebe123~~ → report on my contribs. 14:00, 20 November 2011 (UTC)[reply]

My proposal misses many things that's why I said feel free to insert more / regroup it. It's just a skeleton Petrb (talk) 14:15, 20 November 2011 (UTC)[reply]

Also it seems to me that your requirements are higher than recommended requirements for rfa (5000 edits, sysop on other wikis, etc.) Petrb (talk) 14:20, 20 November 2011 (UTC)[reply]

Actually, the sysop on other wiki is optional. May I also see a recent RfA where the user has been promoted and has less than 7,500 edits. ~~Ebe123~~ → report on my contribs. 12:13, 24 November 2011 (UTC)[reply]

Hi Ebe123, thanks for your feedback. As noted above, I'm avoiding specific criteria like these because I think a short consensus discussion is more capable of making that evaluation, taking factors like these into account. Such criteria might be developed later as a way of managing load, if too many newbies are requesting. (Update: I've added a question-answer to the proposal regarding this design choice.) I also think it's probably unrealistic to force every requester to find a coach/mentor, since there aren't enough mentors to go around, but it would be nice if as many as possible of them could get one (see the question about mentors in replies section of proposal).

Regarding your final note, I agree that tool apprenticeship should never supply the right unblockself to any user. This is not one of the rights included in the trial. Dcoetzee 17:59, 20 November 2011 (UTC)[reply]

• I also believe that introducing criteria of the number of edits higher than for admins does not make sense. Remember that writing one good article is more work than correcting 1000 commas. Pundit|utter 19:10, 20 November 2011 (UTC)[reply]

I propose having no specific criteria other than having sufficient experience in the area the user wishes to work in. An administrator will make the final decision. →Στc. 02:54, 23 November 2011 (UTC)[reply]

"An administrator will make the final decision" - why? This is the whole point here; just because admins have a few special buttons does not magically make 'em good at deciding consensus. And if you mean technically - that they'll assign the right - then, I'm not sure about that; presently, those rights can only be assigned by bureaucrats, not admins.  Chzz  ►  08:22, 23 November 2011 (UTC)[reply]

In my view, bureaucrats should close the discussions, since they have (or if not already, they should be granted) the technical ability to instate the user groups and thereby act on the closure. I don't see how else the discussions should be closed properly, other than by a user with a "title of responsibility". — This, that, and the other (talk) 09:31, 23 November 2011 (UTC)[reply]

I think the difference lies in the volitional or automatic character of the action. Either a bureaucrat makes a decision (and has a right to approve or disprove a candidate), or just technically executes the decision of the community. Currently on en-wiki bureaucrats exercise some decisional power in closing RfAs, while on many other projects they just execute the community's decision. I believe that some discretionary decision scope is sensible. Pundit|utter 16:22, 23 November 2011 (UTC)[reply]

In the proposal as written I'm having bureaucrats (or other users able to grant rights) close successful closures, and permitting non-admin closure of unsuccessful requests, as a way of dealing with load. I don't see any particular reason for the closers to play a decision role, when presumably if they disagreed with the outcome so far they would leave a comment of their own (which would carry a lot of weight) rather than closing it. Dcoetzee 17:38, 23 November 2011 (UTC)[reply]

That'd be a "Non-bureaucrat closure", rather than a NAC, would it? ie, anyone could close an unsuccessful request, but only a 'crat could close a successful one?  Chzz  ►  20:10, 24 November 2011 (UTC)[reply]

Well yes, basically... I thought at first maybe other admins would be able to grant rights in the future, but then they'd just be bureaucrats, effectively. I didn't realise their additional powers were so sparse. Dcoetzee 07:01, 25 November 2011 (UTC)[reply]

Hey all, I'm planning to RfC this pretty soon so I prepared a mock-up of the request page and an example entry. I'd like to get your feedback on it if possible. Thank you! Dcoetzee 02:14, 26 November 2011 (UTC)[reply]

I like it, maybe expand the instructions how to request it and also instructions for rest of the community so that it's clear that anyone can participate in discussion / voting. Petrb (talk) 10:52, 26 November 2011 (UTC)[reply]

I'd make it more like RfA. There's a very good reason why it's just that little-bit-hard-to-do; it stops an awful lot of NOTYET stuff; because users that can't figure out how to transclude a subpage aren't ready for any kind of special rights.  Chzz  ►  11:07, 26 November 2011 (UTC)[reply]

Right, I was a bit bold and changed some stuff on the page, feel free to revert it, or change, I agree that people who request there should be able to handle input box extension at least, however I think it should be at least more clear to community that anyone can participate on discussion there, not just admins. Petrb (talk) 11:10, 26 November 2011 (UTC)[reply]

Hi Petrb, I added a section on discussing requests, which was a great idea and I think will address your concerns. I also introduced the concept that discussants can propose limitations, which can become requirements if there is consensus for them - I think this will be a really flexible way to handle cases where people are uncertain about a requester without adding too much complexity. @Chzz: I originally had manual creation of subpages, mostly because I didn't know how to do a form, but to be honest I think with non-bureaucrat speedy closure available, there's no need to put up little technical barriers to requesters, we can just shut down the NOTYET stuff immediately whenever it appears. Dcoetzee 23:33, 26 November 2011 (UTC)[reply]

The status of the "Task tool(s) will be used for" entry is a little unclear: it sounds as if it is binding on the user - i.e., they are not allowed to diversify their use of the tool beyond the area they specify. Perhaps this should be clarified. — This, that, and the other (talk) 01:50, 27 November 2011 (UTC)[reply]

I actually do want to discourage usage outside of the task, which I think the current wording does. The reasoning is that use of the tool should be informed by experience in a particular area, and that's what discussants are evaluating them based on. If they attempt to diversify into an area in which they are comparatively inexperienced, they might misuse the tool accidentally. On the other hand I don't think this needs to be made a hard requirement in most cases. I think it should be permitted but at their own risk - since they're on probation, any mistakes could cost them the tool. Dcoetzee 05:25, 27 November 2011 (UTC)[reply]

Should the proposed tool apprenticeship process, whereby experienced users with a need for an administrator tool may be given the tool on a trial basis, conduct a six-month three-month trial? Dcoetzee 05:32, 28 November 2011 (UTC)[reply]

• Support as proposer. I believe tool apprenticeship will effectively allow users to gain experience with tools and related policy and combat our many backlogs, while keeping the level of scrutiny required low and so avoiding long discussions. Instead of speculating about future user performance, we can let them demonstrate it in a restricted setting. Dcoetzee 06:25, 28 November 2011 (UTC)[reply]
• Support: RPP and AIV backlogs are becoming a daily occurence.Jasper Deng (talk) 05:48, 28 November 2011 (UTC)[reply]
• Oppose. No way for community to vet potential candidates before granting tools, too open for abuse, too many convoluted "rules" to qualify for tools. Effort would be better spent on fixing RFA than this clusterfuck. --Jayron32 05:54, 28 November 2011 (UTC)[reply]
  • RFA is a little too stressful, because the user must get vetted for all, not just one of, the tools. There are only three rules, no more than the 3 parameters of WP:SOCK. WP:RFA2011 has not produced anything the community can agree on so far (and it will soon be RFA2012 if it doesn't do so soon).Jasper Deng (talk) 05:57, 28 November 2011 (UTC)[reply]
    • Still not convinced. Anyone who should qualify for any one of the tools should qualify for all, and if RFA is broken, this is not the solution. I fail to see how any user who is trustworthy enough to block another user is somehow not trustworthy enough to delete a page. --Jayron32 06:01, 28 November 2011 (UTC)[reply]
      • I probably know enough to block LTAs, socks, and vandals, but not enough to evaluate NFCCs or CSDs (A7), for instance.Jasper Deng (talk) 06:04, 28 November 2011 (UTC)[reply]
        • Knowledge is not my concern. Trust of the community is. If a person has the trust of the community to not abuse the block tool, then they also should have the trust of the community to not abuse the delete tool, and that includes not using the tool when they don't understand the underlying issues. Adminship is about having the faith of the community to make good decisions, and nothing more. This process does not (IMHO) have an effective method to guage that, and a user is either trustworthy or not. Period. If I would not trust them to use any one of the tools, I wouldn't trust them to use any. --Jayron32 06:12, 28 November 2011 (UTC)[reply]
          • I don't see how the trust must be determined by 1 single tool (I've seen lots of RfAs fail due to one minor flaw).Jasper Deng (talk) 06:18, 28 November 2011 (UTC)[reply]
          • Hi Jayron32, thanks for your feedback. I give my opinion on trust under Wikipedia:Tool_apprenticeship#Responses_to_anticipated_objections (trust does not always transfer between areas; trust should be based on experience). The many limitations placed on apprentices are also designed to reduce the amount of trust needed to approve their trial (probation, time-limited trial, other optional restrictions). Consensus discussion at Wikipedia:Requests for tool apprenticeship gives the community the opportunity to vet candidates, but my expectation is that not as much scrutiny would be required as for a full RfA. Dcoetzee 06:21, 28 November 2011 (UTC)[reply]
            • I think we're going to have to agree to disagree on trustworthiness; for me trustworthiness applies to the person and not the task: either I believe you are going to work in good faith and have the competency to produce good results, or you don't. A trustworthy person also has the self-awareness of their own competency: I wouldn't trust a person with ANY admin tool if I didn't believe they would have the wherewithal to avoid using the tool in situations where they didn't have a good understanding. For example: I don't have the edit-filter user right, even though I am an admin and could grant it to myself. Why haven't I? Because I don't have a clue how to operate the black magic that is the edit filter. I would expect any admin to have the self-awareness to use any tool similarly; if they didn't have it, I wouldn't trust them with ANY of the tools. The other issue, the "many limitations placed on apprentices" is what makes the process so convoluted and unworkable. You've replaced "trust of the community" with a complex, convoluted, and messy network of requirements, conditions, and rules which don't make a workable process, IMHO. There is no solid substitute for the trust of the community, and the only way to guage it is via a community discussion, not a set of unworkable "checks and balances". As I admited, RFA is broken; this process doesn't fix it, it merely takes the broken pieces of RFA and smashes them even smaller. --Jayron32 06:34, 28 November 2011 (UTC)[reply]

I understand what you mean, but I think that this feature would be helpful for current process as well, this would help to people who would be good sysops, but aren't established enough (I know many people who are good candidates for sysop but they don't believe that they would pass since there are too many people who could oppose, whatever the reason would be), and this would allow them to prove that they are good candidates for rfa later, so that it can improve the current rfa procedure. It's not about separating sysop bit to many "smaller" groups just to create some security issue, but rather to give the opportunity to the people who would like to be sysops in the future to prove that they would be good in that. Petrb (talk) 09:43, 28 November 2011 (UTC)[reply]

@Jayron32: I was thinking about your "edit filter" argument and here's my counterargument: if admins are people we "trust to know their own limitations," why do we not simply give all of them bureaucrat + checkuser + steward? The answer is that we don't trust them with everything, and with especially dangerous tools extra caution is warranted. I think a similar analogy applies here. I don't think the procedure is excessively complex (RfA, in fact, has more complex requirements). Dcoetzee 04:08, 29 November 2011 (UTC)[reply]

Dcoetzee, I don't appreciate this blanket claim of 'distrust', as I have attempted to explain without success on your talk page through several metaphors and analogies. In real life we have policemen, but this does not automatically infer that every citizen who is not a cop is a potential criminal. And a lack of trust is not the reason either why every traffic cop can't be a chief constable. --Kudpung กุดผึ้ง (talk) 06:05, 2 December 2011 (UTC)[reply]

I think we'll just have to agree to disagree here. I've got into quite a few arguments on this page, and I don't think either side will get the other on trust.Jasper Deng (talk) 06:09, 2 December 2011 (UTC)[reply]

Hi Kudpung, I explained this misunderstanding in some detail on my talk page, and reworded the proposal page accordingly. I never meant to imply that non-admins (or non-bureaucrats) are not trustworthy people, or should be treated with suspicion. That's what WP:AGF is all about. But we quite reasonably take care in evaluating candidates before giving them access to dangerous tools, just as the police do a background check on job applicants. In real life, police also train new staff in the use of their weapon according to the law and department policy, and tool apprenticeship is a natural analogy to this. Dcoetzee 02:25, 3 December 2011 (UTC)[reply]

An extension to that analogy is the paradox that while in the USA citizens have a constitutional right to bear arms, in the UK they have to provide a very good reason for wanting one, and 'not trusting my workmates' or 'just in case' are not on the list. In the UK even the normal patrolman is not armed, and neither are our vandal patrollers who actually do a pretty good job without weapons. Kudpung กุดผึ้ง (talk) 02:37, 3 December 2011 (UTC)[reply]

• Support - I don't remember the last time CAT:CSD was empty. →Στc. 05:59, 28 November 2011 (UTC)[reply]
• Somewhat opposed: vetting is important. As far as I can see, this proposal would only create a new class of user rights (or pseudo-rights, whatever). We cannot bypass the community. Sysop actions affect new (and old) Wikipedians daily, and the buttons should be granted only after a thorough process. I do believe RfA needs significant improvement, but I don't believe handing out semi-adminship or so-called "conditional"-adminship is the way to go forward. CharlieEchoTango (talk) 06:02, 28 November 2011 (UTC)[reply]
  • Less editors are meeting the strict standards of RfA and willing to go through that, so we have to reduce that standard, in my opinion.Jasper Deng (talk) 06:06, 28 November 2011 (UTC)[reply]
    • Or rise to meet it? fredgandt 06:08, 28 November 2011 (UTC)[reply]
      • Either way we have to lower the standard or do this.Jasper Deng (talk) 06:08, 28 November 2011 (UTC)[reply]
        • As I explained below, I don't believe we need to lower our RfA standards. The standards for a tool trial are naturally lower because the potential for abuse is lower. Dcoetzee 05:32, 29 November 2011 (UTC)[reply]
  • Actually Jasper, most probably the opposite is true. As Wikipedia matures, and the longevity of its users extends, there are far more candidates of the right calibre. The problem is, as we all know, that the performance of the voters isn't high enough, and that's why many candidates are not coming forward. --Kudpung กุดผึ้ง (talk) 06:35, 4 December 2011 (UTC)[reply]
  • Hi CharlieEchoTango, thanks for your feedback. I want to note that all requests would go through a consensus discussion process at Wikipedia:Requests for tool apprenticeship; the process is not intended to circumvent the will of the community, but rather to limit discussion and scrutiny as compared to a full RfA by granting less power and imposing restrictions on the apprentice. Dcoetzee 06:30, 28 November 2011 (UTC)[reply]
• Support - some editors (like myself) just don't want the full admin bit (so are highly unlikely to put themselves through the stress of RfA for it!), but could make good use of a limited subset of tools. Personally I could make good use of delete (& undelete) when I'm on NPP, but that would be about all I;d want. Pesky (talk …stalk!) 06:16, 28 November 2011 (UTC)[reply]
• Neutral Still have my own doubts about the efficacy of such a system, but we'll see. I still see potential for abuse, though. —James ^{(Talk • Contribs)} • 4:23pm • 06:23, 28 November 2011 (UTC)[reply]
• Oppose. Anyone who can use the sysop tools competently, with a mature sense of judgement and civility would pass RfA with flying colours, and an appreticeship to admininship would possibly only be considered by many as shortcut to what they consider to be an award for good work. While it is undeniable that RfA is most certainly an extremely unpleasant experience in many cases, it nevertheless continues to demonstrate that generally among those who are prepared to be subjected to it, those who should pass do, and those who are not ready for adminship don't.

Of even greater concern is the danger that a 7-day consensus discussion at Wikipedia:Requests for tool apprenticeship would be just as unpleasant, and would simply multiply the number of occasions for some individuals to be disparaging to the candidates and each other with impunity.

Current backlogs are not (yet) a deep cause for concern, and while reform of the RfA process may seem slow to some, so is the discussion and implementation of all major reforms and new policy, such as for example improvements to NPP that are being discussed since August 2010 that may or may not become a user right, that might or might not include some very limited powers of deletion. WP:RFA2011 is still in the process of gathering statistics and feedback in order to prioritise the many suggestions that have been made for RfA reform; there is no question that the task force is unable to agree on anything. --Kudpung กุดผึ้ง (talk) 07:44, 28 November 2011 (UTC)[reply]

• • No, people look (unnecessarily) for content too, and I think RFA2011 needs to try one of its radical alternatives.Jasper Deng (talk) 23:20, 28 November 2011 (UTC)[reply]
  • Hi Kudpung, thanks for your feedback. Some responses: this proposal is not actually about "an apprenticeship to adminship," exactly - it's not even possible during the trial for the user to acquire more than a few tools this way. It serves two groups of users: one, users that need just a couple tools to do work in a particular limited area, and two, users that want to develop experience with and show responsibility using tools prior to their RfA. Even if these users would in fact pass RfA, many feel more comfortable running if they have an opportunity to develop more experience first. Users can still pursue RfA directly without using it. I don't know whether the consensus discussion would be unpleasant, but the goal was to limit discussion by imposing restrictions on apprentices, so that less scrutiny is needed. Dcoetzee 11:33, 28 November 2011 (UTC)[reply]
    • @Jasper: Radical alternatives are not part of the manifesto of RFA2011. The project is concerned specifically with improvements - namely the level of civility and the quality, accuracy, and honesty of voting - to the current system. Contributors to the project were ignoring this primary goal, hence the sub-section was created to provide them with a forum for their ideas and suggestions for other systems, and at the same time enabling them to benefit from the enormous collection of resources that have been created for the project and are quickly available from the project's navigation.
    • @Dcoetzee: Tool apprenticeship is a euphemism for 'tool unbundling'- for however long, and is a solution for the wrong problems: there is no proof that the general nastiness of the current system is in any way related to fears of the tools being granted for life. To substantiate such claims, one must consider the broader picture, some numerical evidence should be presented that demonstrates the actual tenure and actual number of tool related operations of admins who have been appointed, together with graphs of their performance after the euphoria of being 'promoted'; of the 53 withdrawn rights, around 50% were desyoped by arbcom in the last 3 years, while 277 (to date) have been procedurally desyoped for inactivity, while of the 142 resignations, around 33% were during the last two years. The actual criterion (30 edits in the last 2 months - about 50% of the round 1,500) of what is considered an 'active' admin, is ridiculously low, nevertheless, in spite of the concern that that fewer and fewer candidates are now presenting, there are still no serious backlogs and the point at which the present proposal is needed - or any other radical solution - is a long way off being reached, while suggested measures to clean up the kind of voting that is keeping candidates away may soon be gaining more thrust.

Furthermore, an in-depth, neutral and objective study of New Page Patrol is shortly to be published by the WMF) that may or may not (depending on the way it will be interpreted by the community) lead to proposals for some of the rights discussed here being accorded to patrollers of the right calibre. Kudpung กุดผึ้ง (talk) 13:10, 29 November 2011 (UTC)[reply]

Hi Kudpung, I'll start out by saying that I absolutely think the less radical RfA reform proposals you mention also have merit independent of this proposal, and I would be happy to examine them as they arise. I also agree that, despite my efforts to prevent it, it is a real possibility that the discussions in this proposal may devolve into discussions resembling the current RfA. Although I could take a data-driven approach as you suggest to predict whether this would occur, in light of the relatively low risk of the outlined trial, I think this is better tested by experiment. I also plan to be operating "in the trenches" to help moderate discussion and do my best to prevent this outcome. I understand if you remain skeptical that this is possible. Dcoetzee 03:45, 30 November 2011 (UTC)[reply]

• Oppose at this time Supporting since parameters changed As careful as Dcoetzee has been putting this proposal together, I still have the feeling this will create far more mess than it aims to solve. Very oddly I must also oppose on grounds laid out by one of the proposals proponents. See above "...we have to reduce that standard..." followed by my suggestion that we could instead "...rise to meet it" followed astonishingly but pointedly by "...we have to lower the standard...". I can't support lowering standards, and I feel this is exactly what is being proposed. Basically a shortcut around thankfully tight guardianship of powerful tools. fredgandt 08:01, 28 November 2011 (UTC)[reply]
  • No-one's rising to meet it, so we have to drop our part of it.Jasper Deng (talk) 23:20, 28 November 2011 (UTC)[reply]
    • I've worked in aerospace engineering and electronics and now in web development (noob). In these fields we have standards or tolerances. I've built circuitry so small it's components are fixed under microscopes and even made nuts used in part to hold the wings on the Eurofighter. If my colleagues and I were to have lowered our standards because we couldn't meet them, planes would be falling out of the sky and circuitry would be fizzing to death as we speak. Relaxing standards to fit the unfit is frankly retarded. I expressed these concerns earlier (near the top of this page), so don't think I'm picking on you Jasper. You have just reinforced my concerns. fredgandt 00:01, 29 November 2011 (UTC)[reply]
      • This is not quite the same as aerospace engineering. It isn't like we could lower the pass vote by 5 percentage points and have rogue admins horsing around within a few months.Jasper Deng (talk) 03:04, 29 November 2011 (UTC)[reply]
        • I want to clarify that I don't support Jasper's ideas that we need to "lower our standards." I think our standards for adminship should stay right where they are. Rather, I'm pushing the idea that when less tools are given with more restrictions (time limit, probation, other optional restrictions), naturally standards don't have to be as high, because the potential for abuse is much lower. Dcoetzee 05:17, 29 November 2011 (UTC)[reply]
          • That view by me is for the purposes of WP:RFA2011.Jasper Deng (talk) 05:19, 29 November 2011 (UTC)[reply]
            • Jasper, can you please point to where WP:RFA2011 is supporting lower standards? I'd like to kill it with fire. That is not a goal of the project and I think you will find that the majority of the task force do not support it. Worm^TT · (talk) 07:33, 30 November 2011 (UTC)[reply]
              • It isn't there. It's my opinion on that, and one of the proposals on the talk page (or the radical alternatives talk page, don't remember).Jasper Deng (talk) 00:32, 1 December 2011 (UTC)[reply]
                • It isn't in the manifest of the RFA2011, but being an open platform, there are occasional comments from people whose views and ideas detract from the goals of the project. I'll hasten to add that there are no 'standards' per se - the level is set anew at each individual RfA depending upon the criteria of those who turn up to vote. Any perceptible increase of any such standards is due to the increase in the pool of longer term users as the Wikipedia matures, and the editors who mature with it. In any case, RfA also has a part element of a (un)popularity poll, and there are no immediate remedies for that. Kudpung กุดผึ้ง (talk) 05:02, 2 December 2011 (UTC)[reply]
                • @Jasper: Please direct discussion of criticisms of RFA2011 to Wikipedia talk:RfA reform 2011. This proposal is not intended to compete with other meritorious efforts. Dcoetzee 02:29, 3 December 2011 (UTC)[reply]
                  • Was going off on a tangent a bit, and that's OK. I'm a staunch supporter of this proposal, and I was discussing with Kudpung as he coordinates RFA2011 and had thoughts here.Jasper Deng (talk) 02:35, 3 December 2011 (UTC)[reply]
          • Understood Dcoetzee. I am still concerned, but open minded and paying attention. fredgandt 03:00, 30 November 2011 (UTC)[reply]
• Support Excellent idea + if you needed any help with mediawiki modifications in order to make this possible, I would be very happy to help you as dev. Petrb (talk) 08:26, 28 November 2011 (UTC)[reply]
• Support. There are many users who can be trusted with administrative tools, but who lack the broad experience in many areas which is required at RFA, or simply may not want to become a full admin for various reasons. This process is perfect for this sort of user.
  From the perspective of others who may oppose this on grounds of lack of trust - that is why there is a built-in probation period: if someone is found to be abusing tools under this process during a trial period, the tools can be instantly revoked. The term "high standards" is vague, and I believe this process requires high standards of tool apprentices, in quite a different way to the way in which RFA requires high standards. — This, that, and the other (talk) 08:40, 28 November 2011 (UTC)[reply]
• Oppose. Mostly per Jayron32, and because I just don't subscribe to the "RfA is broken" myth. This isn't needed. -- œ^™ 09:11, 28 November 2011 (UTC)[reply]
  • Neutral. Still skeptical, but after discussing it and looking at from another's perspective, I (grudgingly) agree that change can be a good thing and there's no harm in giving it a try. I'll sit back and watch how the trial goes, if it turns out to be a kind of paradigm shift in Wikipedia administration then great, if it crashes and burns, then that's great too. -- œ^™ 02:52, 29 November 2011 (UTC)[reply]
  • It's not RfA, it's the way it's being carried out here.Jasper Deng (talk) 23:20, 28 November 2011 (UTC)[reply]
• Support test round to see how it goes. Pine^talk 09:44, 28 November 2011 (UTC)[reply]
• Support this small test - I think there is very little danger from the proposed trial, as it will be closely watched; I think it extremely unlikely it would cause any significant problems. And at the end of that small test, if nothing else, I think we will have learned a lot - which may lead to further ideas. Plus the test subjects might have a better shot at RfA (if they want). Thus, the test itself seems to be a net benefit, whether it proves successful or not. RfA is broken, totally.  Chzz  ►  10:05, 28 November 2011 (UTC)[reply]
• Query What's to stop an editor who is in good standing - but crucially has already failed an RfA - from requesting all the tools in a procedural manner? The editor clearly does not have the trust of the community, but this less high profile discussion may mean it is not noticed. I do like the idea and the limited period offsets the risk, but I do think it could be abused to the extent that it snubs current community discussion. Worm^TT · (talk) 11:33, 28 November 2011 (UTC)[reply]
  • Hi Wtt. If you're asking whether a user could make a request for all tools, such a request would almost certainly be rejected, since a single request has to be aligned with a single task, and no task involves all tools (and the more tools a request involves, the more scrutiny is applied). If you're asking whether a user could accumulate many tools slowly over time: not under the process trial, which won't grant tools permanently. With the full process this might be a possibility, but it would take years and involve more effort (and community discussion) than an RfA ever would. Dcoetzee 11:48, 28 November 2011 (UTC)[reply]
    • Well, that does allay at least one of my fears - I'll Tentatively Support a trial. I'd like to see that due care is being taken over the community discussion. For example, I don't want to see someone with a history of being uncivil being given access to the delete button as deletions often have to be discussed with new users who do not understand why they should not have created that article. I'd also like to see some sort of throttle during the period of the trial, so they can be checked. All in all though, I think this would be a positive - it worked for rollback (ish). Worm^TT · (talk) 11:55, 28 November 2011 (UTC)[reply]
      • Thank you for your support - I'm not sure if a throttle is currently technically possible, but that could certainly be made a condition of a user's trial. I agree re: due care in discussions, and moreover whenever possible I like to see concrete experience - in your example, I'd like to see them have a history of not only civility, but actually tagging articles for speedy deletion and subsequently discussing their taggings with affected users. It's important to remember the social skills. Dcoetzee 12:12, 28 November 2011 (UTC)[reply]
  • @Worm: Content work is regarded as important at RfA too, and it is often unrelated to the judgemental qualities of a user.Jasper Deng (talk) 23:20, 28 November 2011 (UTC)[reply]

  Content work is indeed regarded at RfA. I think people compare the candidate to themselves and point out areas the candidate seems lacking. Now, if the majority of work they do is content work, it's hardly surprising that it's checked. This then means the editor gives a measure of trust to the candidate and supports based upon that. I like this proposal for thinking "outside the box" of RfA, only giving relevant tools. I worry slightly as all the repercussions of the tools may not have been seen - and I do think people who have never written content should not be deleting it - so I still tentatively support. Worm^TT · (talk) 07:39, 29 November 2011 (UTC)[reply]

• I think this is a decent idea, and don't see the major harm conducting a trial will do. Don't count this as a support or oppose, more an observation. Steven Zhang ^{The clock is ticking....} 11:41, 28 November 2011 (UTC)[reply]
• Oppose for now I don't know whether this will be a good thing in the long term or not, but that is exactly what a trial is for. One of the proposed restrictions on the trail was for there to be a maximum number of concurrent test subjects (for want of a much better term), and that is something I strongly support. My oppose is based on the lack of explicit criteria by which the trial will be judged a success or failure, which was one of the reasons the flagged revisions trial ended with the drama it did. Once the criteria are agreed, then I'll have no problem supporting a trial. Thryduulf (talk) 12:29, 28 November 2011 (UTC)[reply]
  • Hi, I don't think there should be criteria, just after the time of trial we can start another rfc if others want to make it permanent or not. But it's good point, I think that this could be clarified in definition. Petrb (talk) 12:50, 28 November 2011 (UTC)[reply]
    • If it is clarified, drop a note on my talk page and I'll revisit my opinion. Thryduulf (talk) 14:58, 28 November 2011 (UTC)[reply]
      • Hi Thrydulff, I've now added Wikipedia:Tool_apprenticeship#After_the_trial briefly detailing how the process trial will be assessed. I'm open to other suggestions on improving this evaluation. [also leaving talk page message] Dcoetzee 05:23, 29 November 2011 (UTC)[reply]
        • Support the trial. I'm still not sure whether this is going to be a good thing in the long run, but a trial is going to give us information to make a judgement based on facts not assumptions and rhetoric. Thryduulf (talk) 23:01, 29 November 2011 (UTC)[reply]
• Support the trial, nothing more. After the trial there should be a "study" how successful the trial was and what changed. (that means we need something like a monitoring of the related backlogs) Similar to other supported I think that although many non-admins will success a RFA, they simply don't have the courage to do the RFA, or the need of the full sysop-tools. They shouldn't affected in improving this encyclopedia by limits of their rights. Also the argument that the community should trust in their admins and thus giving them the full tools might not be correct: as correctly stated above: edit filters and other areas need knowledge and the trust is normally given in gaining respect. This can't be transfered (in my eyes) to other areas. mabdul 12:56, 28 November 2011 (UTC)[reply]
  • Hi Mabdul, thanks for your support. A post-trial study is an excellent idea and I've added details at Wikipedia:Tool_apprenticeship#After_the_trial. I'd appreciate any other suggestions in this area. Dcoetzee 08:43, 29 November 2011 (UTC)[reply]
• I like the idea of unbundling the block button, at least to deal with vandalism only accounts. I'm less comfortable with a generic unbundling as some things need to be used in combination, for example you shouldn't appoint an Autopatroller without checking their deleted contributions. I'm uncomfortable with the delete button being unbundled as this is an area where I fear mistakes are already made. Also the most pressing urgency is at AIV most other admin areas can handle having hours when there is no-one on call. At the very least an RFC should have the option of unbundling specific tools rather than all of them. WereSpielChequers (talk · contribs) 13:27, 28 November 2011 (UTC)[reply]
  • Hi WereSpielChequers, thanks for your comment. I want to clarify that users can request multiple tools, if they are needed for a particular task. A request that does not include all necessary tools for performing the task would not be approved. The full unbundling is intended to offer maximum flexibility in the types of tasks that could be served. Re deletion: I am aware that administrators make errors while deleting, but some non-admins have exceedingly good judgement in this limited area, and the tool would be revoked if they misuse it. I agree that AIV is a great place for apprentices to contribute. Dcoetzee 06:52, 29 November 2011 (UTC)[reply]
    • Thanks for the reassurance re combinations, I've struck that part as resolved. In my view non-admins who are ready for the deletion button should run at RFA, as I'm uncomfortable handing out the delete button lightly. I'm more comfortable unbundling some other tools, and I see our most pressing need as the gaps at AIV. So I'm keen that we do this for the block/unblock buttons - though perhaps with the proviso that if you aren't a full admin your block button should only work on IPs and accounts with fewer than 100 edits. I also think that any unbundling needs to include the ability to fix ones mistakes, so the unblock tool goes with the block tool and the ability to remove Autopatroller flags with the ability to set them. ϢereSpielChequers 09:58, 1 December 2011 (UTC)[reply]
      • This worries me: I want to clarify that users can request multiple tools, if they are needed for a particular task; the actual number of tools is not many, so there is no basic difference here than applying for the full set through the regular RfA process. At least RfA takes into account the performance that is not measured by the potential use of the tools themselves, such as maturity, civility, and a keen sense of judgement. Kudpung กุดผึ้ง (talk) 05:50, 2 December 2011 (UTC)[reply]
        • This is an understandable concern. When I say "multiple" the case I have in mind is vandalism patrol, which requires heavy use of both protect and block. I don't expect requests for more than two tools to ever be necessary or get approved - and even requests for two tools would be treated with more scrutiny. Just to make this more obvious, I'm restricting it to at most two as a condition of the trial. Dcoetzee 02:36, 3 December 2011 (UTC)[reply]
• Support as a trial only. It seems to me that, although the concept is admittedly a work in progress, any harm that may result during the trial as proposed will be readily correctable, with no irreversible harm, and only a low risk of a lot of hassle in reversing anything. I think that it addresses a genuine need, and is the kind of improvement we should explore, rather than automatically rejecting as generally happens with administrator-related reform. But it should only be a trial at this point, subject to scrapping if it doesn't satisfy the community at the end of the trial period. About that period, I also note that the proposal seems to say that users would be given tools for a maximum of one month at a time, but then goes on to describe a scenario in which the term is three months. I'd like it to be clear that there is a one-month limit. --Tryptofish (talk) 15:21, 28 November 2011 (UTC)[reply]
  • Hi Tryptofish, thanks for your support. I've revised the example to suit the terms of the trial. Dcoetzee 08:58, 29 November 2011 (UTC)[reply]
• Oppose the trial until it is made clear what happens at the end of the trial. I'm not fundamentally opposed to a trial, but after the disaster of the end of flagged revision trial, it needs to be clear that all trials should stop at the end of the 6 months and that afterwards a clear consensus is needed for either a further trial, or for rolling out generally. The limit of 10 at a time should be enforced strictly until the end of the trial. Also I know the trial does not include giving any right permamently, but when/if the trial happens and is successful, there must be a way to remove the right(s) from users who have been granted them "permamently" without having to go to Arbcom. I will not support establishing any more rights that can only be removed by Arbcom. Davewild (talk) 16:02, 28 November 2011 (UTC)[reply]
  • The end of the trial will simply result in the complete disuse of any extensions and/or user groups used in the trial. The right will always be temporary for apprentices, and it's basically a hands-on approach to admin coaching.Jasper Deng (talk) 23:20, 28 November 2011 (UTC)[reply]
  • Hi Davewild, I've added Wikipedia:Tool_apprenticeship#After_the_trial to directly answer your concerns. I have, for the moment, eliminated the concept of permanent rights assignment altogether. Dcoetzee 03:55, 29 November 2011 (UTC)[reply]
    • Withdraw my oppose as my main concern has been addressed. Will think about whether I should support or not. Davewild (talk) 07:50, 29 November 2011 (UTC)[reply]
• Oppose - I see no reason to over-complicate an already imperfect RfA process. The issue of trust has not been sufficiently answered for me. Trust is not about whether we think a potential admin would be able avoid accidentally/maliciously deleting the main page, it is about whether, as a community, we trust them to have the required discernment and judgement to properly use the tools given to them and to not use tools which they are not confident in using. RfA is more than "will this user break anything?" (which is how other requests for permission, such as rollback, work); RfA is asking "does this admin have the right skills to undertake the role of adminship, both technical ability and their reasoning, judgement and discernment?". I'm not opposed to releasing more powers from adminship (such as rollback) per se, but this should not be party of the RfA process. Whereas requests for permissions is a simple question of whether someone will use a tool properly, RfA carries a lot more responsibility. Admins are given the right to close AfD discussions, for example, and (in most cases) users cannot do this. The reason that I, as a non-admin, cannot close an AfD discussion as keep (without near-unanimous consensus) is not to do with the technical abilities I have - technically, I could close any AfD as keep/redirect - it is because the community has not elected me as a trusted individual. Therefore, adminship is about community trust; tool apprenticeship is about a few tools that some people might find useful - these are very distinct things. ItsZippy ^{(talk • contributions)} 17:06, 28 November 2011 (UTC)[reply]
  • This is not part of RfA, and is not intended to be. It's about training people to gain trust.Jasper Deng (talk) 23:20, 28 November 2011 (UTC)[reply]
  • Hi ItsZippy, thanks for your feedback. As Jasper noted, tool apprenticeship is not part of RfA but a supplementary and independent process. You are quite correct about AfD discussions, and that is why we would not give the delete tool to apprentices for closing AfD discussions (unless the community later chose to allow apprentices to close AfD discussions). In general, any place that policy says "an administrator must do this" now, apprentices will not be eligible to do those things without a change in policy, because they are not administrators. I have amended the proposal to clarify this point. Dcoetzee 05:37, 29 November 2011 (UTC)[reply]
• Oppose. Getting the admin tools has always been a trial-and-error process, and that's what made it good. Adding this in would not only complicate things and add more bureaucracy, but would probably end adminship. Wizardman _{Operation Big Bear} 17:26, 28 November 2011 (UTC)[reply]
  • It wouldn't end adminship, as that is a permanent right, while these are temporary and limited rights.Jasper Deng (talk) 23:20, 28 November 2011 (UTC)[reply]
  • Hi Wizardman, I understand your concerns about apprentices displacing administrators. My expectation is that, to the contrary, apprentices who have more experience with tools and related policy will feel more confident running for administrator later, increasing the number of admins. The trial will help to evaluate this impression in practice. Dcoetzee 06:11, 29 November 2011 (UTC)[reply]
• Support trial. This seems to me to be an excellent way to put the tools into the hands of people who are willing to do the work. We need more people doing the work. I'm hopeful that something like this would be more of a feeder to adminship than a challenge to it. Spending some time doing similar tasks can give people experience and confidence to undergo RFA. :) Before a trial would begin, I would like to see clear consensus, though, on how tools are to be "revoked for blatant misuse". Is there a discussion, or is this a single administrator's opinion and action? If the latter, does discussion follow? Is removal permanent or just until the misunderstanding that led to blatant misuse (assuming it's not "blatant abuse") is worked out? I like that the permission follows a discussion period; I have seen users granted "autopatrolled" status, for instance, in spite of multiple copyright warnings on their page, and I would be uneasy with this if it were quite as lightweight as that. I also wonder if there would be a possible way of tracking usage of the tools. Could we create, for example, a Special:Log/delete for people who have this tool so that admins might do spot-checks? --Moonriddengirl ^(talk) 19:08, 28 November 2011 (UTC)[reply]
  • Hi MRG, thanks so much for your feedback. I've added a section Wikipedia:Tool_apprenticeship#Probation to address your questions that I think people should be able to agree on. I think it's okay to have removal be rapid and without discussion, since the user can issue a new request if it was made in error (I think it goes without saying that discussing the issue with the user either before or after removal is important). The idea of tools to help audit apprentices is an excellent one and something I could work on myself if the trial is approved. Dcoetzee 05:03, 29 November 2011 (UTC)[reply]
• Support as a trial only, with a one month limit. I'd be happy for the proposed limit of ten simultaneous apprentices to be raised at least a little bit.-gadfium 19:56, 28 November 2011 (UTC)[reply]
• weak oppose though a shorter trial (1-2 months) would move me to neutral. I think, per Wizardman, that this will have significant long-term impacts on the wikipedia culture. Not sure if those would be good or bad though. Hobit (talk) 20:21, 28 November 2011 (UTC)[reply]
  • Hi Hobit, thanks for your feedback. I'm certainly willing to consider a shorter trial, but I want to make sure that users have the opportunity to request renewal/extension of a trial at least once, since this is one of the primary feedback mechanisms of the system. A 3-month trial would be long enough for this. Would you consider this acceptable? Alternatively I could consider making tool trials shorter, perhaps 2-3 weeks. Dcoetzee 06:22, 29 November 2011 (UTC)[reply]
    • Either would be acceptable to me. After the pending changes trial I have serious issues with trials. Throw in a fairly clear statement that after the trial is scheduled to end the trial _will_ end unless there is consensus otherwise and I'll move weak support. I'm not sure it's needed, I'm not sure it's wise, but I'm willing to give it a shot as long as the trial duration is short and well defined. Hobit (talk) 04:31, 30 November 2011 (UTC)[reply]
      • Hi Hobit, I agree that a shorter trial is a better starting point. I've made it 3 months, and added all manner of language making it as clear as I possibly could that the trial will really, really end after 3 months. Hopefully this will ease the concerns of those who still remember the botched Pending Changes trial. :-) Dcoetzee 06:46, 30 November 2011 (UTC)[reply]
        • Changed to weak support. I think this is probably a bad idea, but I see little harm in testing the waters if the trial is shorter and now that it has a well-defined ending. Hobit (talk) 18:29, 30 November 2011 (UTC)[reply]
• Support: this is a great idea as one user who would love to help out in page protecting where there is always a backlog. A trial will not cause harm to the community and no irreparable damage can be done by this. Edinburgh Wanderer 20:59, 28 November 2011 (UTC)[reply]
• Support. It sounds like a useful trial, seeing whether some tasks can be done without being a "superuser" capable of passing the increasingly high bar of RfA is a great idea. If it doesn't work, don't extend it beyond the trial. Fences&Windows 22:03, 28 November 2011 (UTC)[reply]
• Oppose We don't need "apprenticeships" on Wikipedia. That's yet another bureaucratic sublevel for eager newbies to get promoted to. There is no real shortage of admins that this proposal will resolve. /ƒETCHCOMMS/ 22:05, 28 November 2011 (UTC)[reply]
  • No, this is not intended for newbies at all. The gist is that there are many experienced users who are afraid to get into the other stocks at RfA to get the tools, and giving the tools gradually would remedy that.Jasper Deng (talk) 23:02, 28 November 2011 (UTC)[reply]
    • I didn't mean it was for users when they were newbies. I said newbies would see it as some "level-up" achievement. Either way, admin tasks are not mutually exclusive; thus, while some users may be competent enough to block a vandal or sockpuppet, the fact that they are not confident in their CSD abilities or file policy knowledge does not instill in me any level of trust in their competence to wield any sort of administrative tool. /ƒETCHCOMMS/ 00:58, 29 November 2011 (UTC)[reply]
      • Hi Fetchcomms, thanks for your feedback. Regarding the status-seekers, User:M.O.X also raised this concern earlier. A user who is clearly not ready would not be approved; while a user who is just pretending to be active, experienced, and responsible in an area, would ultimately "become the mask" and actually accomplish things. Regarding your final point: I really believe a user can confidently and responsibly wield tools in a limited area without a complete understanding of all areas (indeed many admins fit this description). I believe a trial would help to demonstrate this. Dcoetzee 07:20, 29 November 2011 (UTC)[reply]
        • I disagree with the last part of what you wrote. I think it's very concerning that some admins still do not understand the non-free content policy or other important policies/guidelines, yet these are the people that new users are going to look up to for advice. /ƒETCHCOMMS/ 15:21, 29 November 2011 (UTC)[reply]
          • I won't discuss here the degree to which admins should understand policy comprehensively, but the terminology of apprentice was chosen to emphasize that these users are "in training" and not as generally experienced as full administrators, a message that I think new users will understand, especially in combination with other factors. I also hope that by acting as a stepping stone to RfA that in the long term, new users will have a greater number of admins to choose from when seeking advice. Dcoetzee 04:03, 30 November 2011 (UTC)[reply]
  • The "apprentice" part concerns me especially because I generally have less trust for apprentices. There's plenty of connections to be made with the simple viewdeleted right, and that's at least one privilege I don't feel comfortable letting less-experienced users have. /ƒETCHCOMMS/ 21:13, 30 November 2011 (UTC)[reply]
    • The viewdeleted privilege would not be available in this trial, and I don't think it's really that important to warrant apprenticeship.Jasper Deng (talk) 00:37, 1 December 2011 (UTC)[reply]
      • So these apprentices would be able to delete pages, but not be able to view the pages they've deleted? That seems ludicrous. Jenks24 (talk) 01:12, 1 December 2011 (UTC)[reply]
        • I'm sure the apprentices would remember why they CSD'd a page. If something's wrong, the page creator can be forwarded to a real admin. They have no other reason to view deleted stuff (I wouldn't want to be able to view RD2'd material (revdeleted)).Jasper Deng (talk) 01:16, 1 December 2011 (UTC)[reply]
        • Yes, this is related to Wikipedia:Tool_apprenticeship#undo. Apprentices, like any other user, can seek help when they need tools they don't have. If they give clear deletion reasons, as they should be doing anyway, this will largely obviate the need to view the deleted material. Dcoetzee 02:59, 1 December 2011 (UTC)[reply]
      • Doesn't that seem a little ... you know ... inefficient? A regular admin can undo a deletion themselves, whereas an apprentice would need to find someone else every time they made a mistake. That's especially annoying for an article's creator, Jasper Deng, and could very well make them think Wikipedia is too difficult to be worth their time. What sort of website has workers that can delete things but make you ask someone else if you want it undeleted? /ƒETCHCOMMS/ 22:17, 1 December 2011 (UTC)[reply]
        • Re "make you ask someone else" - if an apprentice realised their deletion was unjustified, they would not send the hapless article creator to requests for undeletion. They would simply ask an admin on their talk page to undo the action. The admin would review the situation and do so if it was appropriate. The burden on article authors would not be increased, and the overhead would be quite low. It is an annoyance, but they shouldn't be making mistakes too often (if they are, they should really get their tool revoked). Dcoetzee 22:23, 1 December 2011 (UTC)[reply]
• Question How is this supposed to work? I thought that it was technically impossible to grant some admin rights but not others, and (unless I missed it) this proposal doesn't address the technical side of things at all. Nyttend (talk) 22:19, 28 November 2011 (UTC)[reply]
  • This can be easily remedied if there is consensus. New userrights groups can be created with ease by the devs. — This, that, and the other (talk) 22:40, 28 November 2011 (UTC)[reply]
  • Hi Nyttend, please see: Wikipedia:Tool_apprenticeship#What_is_needed_to_implement_it.3F. User:Petrb is a dev and has assured me this section is correct. Dcoetzee 03:38, 29 November 2011 (UTC)[reply]
• To those crying "bureaucracy, no!!": The cliff one has to scale to get admin tools is too big. It's like trying to become a black belt without any other belts, at a time when people with black belts are urgently needed for the military. True, some people will do it in one fell swoop, but no, most people will have to use an intervening level. Since this will be open to only a limited number of people at a time, there's no real "bureaucracy" here.Jasper Deng (talk) 23:09, 28 November 2011 (UTC)[reply]
  • Your metaphor is flawed in that anyone can "earn" other "belts" at any time—e.g., writing articles, participating at AfDs, being a civil and rational voice in discussions. The bureaucracy is in the implementation but also the concept, because it further complicates a very simple idea. /ƒETCHCOMMS/ 05:16, 29 November 2011 (UTC)[reply]
    • No-one decides to go that far (my point). If we were a simple website, we would have only one or two privileged user groups, instead of the four or five we have right now. And, we need to encourage adminship, not just have an open door to it. Wikipedia did not become the world's 5th-most-visited site without some seed articles to attract users to edit.Jasper Deng (talk) 05:24, 29 November 2011 (UTC)[reply]
      • Why do we need to encourage adminship, pray tell? If someone is ready to be an admin, RfA is available. If someone is not ready to be an admin, we should not push them to become an admin. /ƒETCHCOMMS/ 15:22, 29 November 2011 (UTC)[reply]
        • We have lots of experienced users that need encouragement to jump into RfA. RfA is not as easy as you seem to be implying here.Jasper Deng (talk) 18:08, 29 November 2011 (UTC)[reply]
  • That's your opinion, and I disagree. I think RfA is not difficult if a user puts their mind to it, and encouragement isn't necessary for qualified users who want to become admins. If someone's afraid of being publicly criticized, then being an admin is definitely not going to help. /ƒETCHCOMMS/ 22:21, 29 November 2011 (UTC)[reply]
• Support the trial. It may be worthwhile to see how it works, since there are pros and cons, both anticipated and unanticipated, which will be fully visible once we understand the mechanics of this solution. Pundit|utter 00:39, 29 November 2011 (UTC)[reply]
• Strongly oppose This would simply allow inexperienced, eager, power-hungry users to get buttons that they're sure to abuse. See comment below. HurricaneFan25 01:10, 29 November 2011 (UTC)[reply]

• Do you have no faith in the judgement of the bureaucrats who are to close the proposed requests? →Στc. 02:57, 29 November 2011 (UTC)[reply]
• Hi Hurricanefan25. I understand your concern about abuse. See the new section on probation. Besides the fact that tools would only be given to users with sufficient experience in the area in the first place (that is one of the listed requirement) following a 7-day consensus discussion, any abuse would lead to rapid revocation, and they wouldn't be approved again any time soon. Are there other measures you'd like to be seen taken to address this issue? Dcoetzee 05:11, 29 November 2011 (UTC)[reply]

• Support trial. I think the goal of this is basically being a proving ground for candidates to grow into becoming RfA candidates. There's two models that this kind of proposal could potentially take: the Police Community Support Officer model, where we create essentially junior admins on a semi-permanent basis, or there is the work experience model, where we give a potential adminship candidate a chance to prove him or herself, or potentially to rule themselves out from having to go through RfA as unsuitable. The only thing I think would be good would be if this could be tied into admin coaching. This way, a candidate for tool apprenticeship has an admin who is responsible for his or her use of the tools. As RfA reform goes, this is a nice, easy practical proposal that I think we actually can try and see if there's any merit to it. If it doesn't work out, the RfA reform crowd can go back to the drawing board and try again. —Tom Morris (talk) 01:17, 29 November 2011 (UTC)[reply]
  • Hi Tom, thanks for your support. I agree that coaching by admins would be great, and would strongly encourage it, but as a practical matter I don't think every apprentice would be able to find a coach/mentor, so I've avoided making this mandatory. Reviews at request time are a lightweight substitute. Dcoetzee 09:04, 29 November 2011 (UTC)[reply]
• Support I want to see how this works out. It could work. One thing that worries me is people mass opposing anyone that runs though it because they don't like the process, irregardless of the person. That would be sad, there's little doubt in my mind that it will happen. After all, the number of opposes for reconfirmation RfAs, just because they were reconfirmations. Sven Manguard Wha? 02:54, 29 November 2011 (UTC)[reply]
• Oppose: this will create a class of parallel pseudo-admins whose privileges and responsibilities are unclear. There may or may not be consensus that RFA is broken, but there certainly is no consensus that adminship itself needs to be greatly altered. One of the most important things about it is that the community has always had and still has a clear sense of what an admin is, who is one and who isn't, and what it means for adminship to be taken away. I don't see muddying that category as helpful. Furthermore, it is my experience as a long-term admin that the tools are inseparable from each other: for example, deletion and page protection are often part of the same process (whether protecting a title as deleted or protecting a just-undeleted page), and similarly, sorting out a complex conflict my involve both protection and blocking. The only tool I could see being separated out would be the userrights tool. Chick Bowen 03:43, 29 November 2011 (UTC)[reply]
  • Beside the point. That's for people who want to do that. There are also processes that require only one of the tools. You'd have much more time for dispute resolution if vandals and socks could be blocked by others. We are trying to generate consensus here.Jasper Deng (talk) 03:45, 29 November 2011 (UTC)[reply]
    • As I say, not in my experience. I did not realize how much the tools depended on each other until I had used them for a while. There is no way to know, if you haven't tried to address one of the various admin responsibilities, which tools you will need to do so. Chick Bowen 03:47, 29 November 2011 (UTC)[reply]
      • This would be for only one or two of the responsibilities, not all of them.Jasper Deng (talk) 03:49, 29 November 2011 (UTC)[reply]
        • Precisely, and that's why it's not a good idea. Just "one or two of the responsibilities" is not often feasible; usually, different administrative areas are linked together, e.g., someone creating hoax articles must be blocked and the articles deleted; or with a vandal, pages should be protected and/or deleted, and the user blocked. An admin isn't useful if he/she can only perform a certain task or two, and leave the rest of the job unfinished for someone else to clean up. /ƒETCHCOMMS/ 05:19, 29 November 2011 (UTC)[reply]
          • It would still have the effect of lowering admin workload, especially since the apprentices may work together on the same situation.Jasper Deng (talk) 05:28, 29 November 2011 (UTC)[reply]
  • No, that's simply inefficient and unnecessary. /ƒETCHCOMMS/ 15:23, 29 November 2011 (UTC)[reply]
  • Hi Chick Bowen, thanks for your feedback. I've given some thought before to the issue that some tasks require many tools (see "What about overspecialization?" under Wikipedia:Tool_apprenticeship#Responses_to_anticipated_objections). As Jasper noted, apprentices can collaborate, or can ask admins for help through the same channels as normal users. Although this incurs communication overhead, I think the work done by the apprentices would far outweigh this (whether this is the case is one question a process trial could help answer). I've endeavored to clarify that apprentices are not administrators, and are not entitled to act as representatives of the community. Dcoetzee 06:34, 29 November 2011 (UTC)[reply]
    • Actually, I am arguing that all admin tasks require multiple tools, because the admin needs experience with the full spectrum of the tools to know how to deal with the situations that arise. In this sense, the definition of adminship is the crux of my argument with you, and it doesn't matter how clearly you define these apprentices as non-admins, because you are still asserting that admin experience is not necessary in order to carry out specific admin functions, an assertion I strongly disagree with. Chick Bowen 20:49, 29 November 2011 (UTC)[reply]
      • This is an interesting argument, but one could argue similarly that experience with checkuser/oversight rights provides valuable experience for admins that informs how they deal with situations like handling socks, revision-deleting personal information, etc. More experience with more tools does help, but is not absolutely necessary, and our existing system recognizes that - the important thing is that they recognize when a situation requires help from others, and apprentices could be evaluated based in part on this. Dcoetzee 04:24, 30 November 2011 (UTC)[reply]
• Comment RFA is broken, because less and less users are willing to stick their neck out and participate in it, simple as that. However, tool apprenticeship is probably not the answer. The answer is the fix RFA by making it less confrontational so more users will be willing to apply for adminship the traditional way. However, fixing RFA requires a lot of editors who don't see it as broken to admit there is a problem, but some aren't willing to take that step yet despite the many flaws that are presented over and over again. — Moe ε 05:36, 29 November 2011 (UTC)[reply]
  • Hi Moe, thanks for your feedback. While I do think there's room for improvement in RfA, it faces many barriers to change. In light of that, I think tool apprenticeship will help users who are intimidated by RfA to develop confidence in their use of tools and related policy so that they can later feel confident applying, while simultaneously getting more work done on the project. Would like to know your thoughts on this. Dcoetzee 06:08, 29 November 2011 (UTC)[reply]
    • Replied at my talk page (to keep the conversation centralized). — Moe ε 07:14, 29 November 2011 (UTC)[reply]
    • I'm giving a conditional Support of the process per discussion at my talk page. This is pending any other problems that may occur, so I'll be keeping an eye out for future concerns. — Moe ε 08:13, 29 November 2011 (UTC)[reply]
      • I've already opposed this proposal, but if I'm to be persuaded to change my mind, I'd need to know what these 'barriers' are, and some thought provoking answers to my oppose vote. Kudpung กุดผึ้ง (talk) 16:52, 29 November 2011 (UTC)[reply]
• Comment Wouldn't this be an open invitation for a would-be rogue admin to gain the tools under lesser scrutiny, build up some trust and receive them permanently at RFA, and then go and block Jimbo and delete the main page (or whatever mischief he intended to do? Seems like this would make a would-be User:Wonderfool's path to adminship easier--of course they would wait until after the apprenticeship period to go rogue. 169.231.52.208 (talk) 07:43, 29 November 2011 (UTC)[reply]
  • I don't believe blocking Jimbo and deleting the Main Page are actual concerns of editors. If you block Jimbo and delete the Main Page, those can easily be fixed, and your administrator tools would be taken from you almost immediately. — Moe ε 08:16, 29 November 2011 (UTC)[reply]
  • Although experience as an apprentice would be one factor taken into account at RfA, it does not reduce a user's burden to meet other RfA requirements. Red flags pointing to potential rogue admins would carry just as much weight, and such a user would likely not be promoted to admin (or if they are, it's unlikely their evil plans would've been detected regardless). Users who go rogue during their apprenticeship would be stripped of tools almost immediately as a probation violation. Dcoetzee 08:22, 29 November 2011 (UTC)[reply]
• Support This will make administrative tasks less bureaucratic and it will also lighten the admins' workload. PaoloNapolitano 08:23, 29 November 2011 (UTC)[reply]
• Support one-week trial I'm quite sure that the bureaucrats don't have any lack of judgement; although I would propose that there should be a limit to # of actions per user per day (e.g. 15 deletions). HurricaneFan25 13:13, 29 November 2011 (UTC)[reply]
  • Hi Hurricanefan25, could you clarify what you mean by a "one-week trial"? Are you suggesting apprentices should receive tools for one week, rather than one month? Currently the request discussions are 7 days, so making the whole process trial that long would be difficult to fathom. I'd be happy to consider a limit on number of actions, but I don't think this is currently technically possible (except by voluntary compliance under threat of tool removal), and I think what an appropriate number is would depend very much on the task at hand, so it's better delegated to request discussions instead of spelling out in detail here. Dcoetzee 04:29, 30 November 2011 (UTC)[reply]
    • In regards to your first comment, I mean that the apprentices should only receive the tool for one week. HurricaneFan25 16:20, 30 November 2011 (UTC)[reply]
      • Sure. I felt like a longer trial would get more data, but one-week trials would encourage more feedback which would be great. I've made the modification. Dcoetzee 02:35, 1 December 2011 (UTC)[reply]
• Support a brief trial. We've got to do something differently.—S Marshall T/C 16:47, 29 November 2011 (UTC)[reply]
• Support. Nothing ventured, nothing gained. Ironholds (talk) 17:22, 29 November 2011 (UTC)[reply]
• Oppose per Chick Bowen. Ruslik_Zero 19:33, 29 November 2011 (UTC)[reply]
• Strong Oppose The current system is crappy, but works. This proposal would only add an extra layer of unneeded bureaucracy, create endless drama, and serve no beneficial purpose to the encyclopedia. With much respect to the proposers, this is a terrible idea. -FASTILY ^(TALK) 20:02, 29 November 2011 (UTC)[reply]
  • Hi Fastily, I appreciate your feedback. I would like to emphasize that one of the main goals of the proposal is to reduce discussion (and drama) around requests as compared to RfA by placing restrictions on apprentices. The benefit to the encyclopedia is, I think, obvious - the apprentices would accomplish work (like blocking vandals, speedy deleting new pages, handling protect requests) that otherwise would either not get done or take up time that an administrator could be spending doing something else. Dcoetzee 04:34, 30 November 2011 (UTC)[reply]
• Support. I have long argued for a process permitting routine use of the tools (blocking people who go around inserting penises into BLPs, clear cut CSDs etc) with something like RfA remaning to determine those who are deemed competent enough to make tough judgement calls (difficult blocks, contentious XfDs and so forth). I do recognise the risks and drawbacks of this, indeed vehemently disagree with the idea that someone should be allowed to make difficult blocks of close contentious XfDs based on a lightweight process. However, the fact that this appears likely to happen is a relatively small price to pay for what is otherwise a giant leap in the right direction, and I'm confident that after the trial the appropriate tweaks will be made to this one part of the solution. —WFC— 03:16, 30 November 2011 (UTC)[reply]
  • Hi WFC, thanks for your support. These are good points, and I definitely recognize in areas like non-admin closure that less experienced users are not always trusted with tough decisions, even where they have the technical ability to perform the action. To some extent I think probation will discourage risky actions, but to further decrease risk it might be profitable, at least for certain tasks like the ones you mention, to require that apprentices restrict their use to "obvious cases." In the long term, I think the best way to proceed here is to delegate to the various areas the responsibility of determining what they allow apprentices to do and not do. Dcoetzee 04:12, 30 November 2011 (UTC)[reply]
• Suggest (again) I might support this proposal if it was better understood how the process would work and how it might effect Wikipedia. The changed proposed is fairly massive. It is proposing a new breed of admin. I suggested weeks ago (near the top of this page), "You might want to consider a mock trial to work out and study how well requests for tools could be handled. Since no tools would actually be handed out everyone involved would be simply playing along like those paramedic training days with the volunteer corpses.", and would still like to see that sort of trial before a trial with live ammo. I think it would be beneficial to all concerned and possibly help alleviate a great many concerns. fredgandt 03:34, 30 November 2011 (UTC)[reply]
  • Hi Fred, I apologize that I didn't respond to your proposal the first time you mentioned it. Although demonstrating that discussions can be straightforward as I claim would be invaluable, as comments by others makes clear, I was concerned that a mock trial would attract few participants and carry little weight because the participants would be aware that nothing is really on the line. There might be ways to partially correct for this e.g. by suggesting that the discussions would "carry over" into the real trial - I'm open to ideas here. Dcoetzee 04:40, 30 November 2011 (UTC)[reply]
    • Acceptable. If the trial was to run as described but that no tools were handed out. The community then gets to evaluate the process and how they feel it went, whether their concerns mattered, if users who they felt shouldn't get tools were or not granted them etc. etc. and we can all get together for another round of discussion and (cough) voting to decide finally if those who were successful in bidding for tools get them. The trial then continues to see how the process deals with the use of the tools and any misuse of them, more discussion and (not) voting.... It may seem long winded but if something is worth doing, it's worth doing properly. I feel it is unlikely anyone would find this course disagreeable. Trial > More discussion > If agreed, tools get handed out > Trial > More discussion > Who knows? > Get some sleep. fredgandt 05:01, 30 November 2011 (UTC)[reply]
    • More simply. A chance to slam the brakes on just prior to tools being handed out would sway my vote (oops I mean erm bold text comment). fredgandt
      • Comment: Everybody is able to get the full sysop rights at the testwiki, the huggle testwiki and/or testwiki.org... So if you/anyone want to play admin to learn the tools, test it there. mabdul 13:13, 30 November 2011 (UTC)[reply]
        • Excuse me? Point that finger with care. fredgandt 15:51, 30 November 2011 (UTC)[reply]
        • @Mabdul: The purpose of apprenticeship is not primarily to learn how to technically operate the tools, but to learn how to responsibly use them according to policy while also getting real work done.
        • @Fred: At the moment I still favor a live trial because discussions will be taken more seriously, but I will definitely revisit your idea if there isn't support for a live trial right now. Dcoetzee 02:43, 1 December 2011 (UTC)[reply]
• Oppose *We do not have a shortage of admins. We have perhaps a shortage of careful admins, but I think that the degree of idiosyncrasy and carelessness among admin is considerably less than when I joined 5 years ago. We should continue the course of increasing the degree of selectivity. There are sufficient quasi-admin tasks for prospective admins already to judge the quality of candidates. DGG ( talk ) 05:11, 30 November 2011 (UTC)[reply]
  • We are losing quite a lot of active admins each year to retirement/voluntary desysopping.Jasper Deng (talk) 05:13, 30 November 2011 (UTC)[reply]
  • Hi DGG, thanks for your feedback. I want to note that I'm not advocating a less selective RfA process, and this process is in some ways more selective (it requires clear experience in the area the tool will be used in). The main difference is that administrators can perform tasks in a variety of areas, while apprentices are limited to a single area with regular reviews. In fact, the ability to create apprentices to fill out workloads might facilitate more selectivity in the choice of full administrators. Dcoetzee 06:29, 30 November 2011 (UTC)[reply]
• Support Opposers raise valid concerns, so probably a small scale trial would be best. FeydHuxtable (talk) 15:22, 30 November 2011 (UTC)[reply]
• Oppose No way is this an acceptable solution. If you can't gain the communities trust you shouldn'y have access to the toolset. Spartaz ^Humbug! 18:37, 30 November 2011 (UTC)[reply]

• What about people who don't even want the full toolset, so are never going to go the RfA route, but could make good use of one or two tools? Pesky (talk …stalk!) 21:57, 30 November 2011 (UTC)[reply]
• See Wikipedia:Tool_apprenticeship#trust. Dcoetzee 02:53, 1 December 2011 (UTC)[reply]

• Oppose per Jayron, Kudpung, DGG. If I trust someone with some of the tools, I trust him with all the tools. If RFA is broken, this is not a good way to fix it. Many admin tasks I do require a variety of tools, and not just a small subset, and not the same ones each time. Edison (talk) 19:59, 30 November 2011 (UTC)[reply]
  • See Wikipedia:Tool_apprenticeship#trust on the trust claim. Although some tasks do require a variety of tools, many tasks don't, and those are the tasks apprentices would contribute on. I also would not characterize this mainly as an RfA reform measure, but as a supplementary process that serves other purposes like getting users experience with using tools according to policy, and getting more work done on the project. Dcoetzee 02:31, 1 December 2011 (UTC)[reply]
• Oppose, per virtually all of the above opposers. My views on RfA reform have been very well advertised for quite a long time, and I'm a coordinator of a reform project myself. So as much as it pains me to oppose an attempt at change, this is simply not the type of reform that I feel is needed. Swarm ^X 22:38, 30 November 2011 (UTC)[reply]
  • Can you clarify your objections to this proposal in a little more detail? Thanks! Dcoetzee 02:31, 1 December 2011 (UTC)[reply]
• Comment there seems to be a lot of 'oppose, because, my idea is much better'. Well, hell, people have had better ideas for the past several years; none have made any difference whatsoever. We all have ideas about what is "best" - but to just oppose because 'this doesn't QUITE match my own ideal' isn't helping. So, can the opposers please try to indicate what would work, not just what wouldn't - I mean this in the best possible faith.  Chzz  ►  23:16, 30 November 2011 (UTC)[reply]
• Support. Clear start, clear end, clear parameters during the Trial and clear parameters for running the Trial. --Shearonink (talk) 23:30, 30 November 2011 (UTC)[reply]
• Support the trial. I see no terribly concerning issues with at least trying a new system for user tools. Tyrol5 [Talk] 23:33, 30 November 2011 (UTC)[reply]
• Oppose - Not really much to add; if I trust someone with a few of the tools, I trust them with them all. Going through a process to determine trust in them by the community as a whole seems preferable to me. ~~ Hi878 ^{(Come shout at me!)} 02:08, 1 December 2011 (UTC)[reply]
  • See Wikipedia:Tool_apprenticeship#trust. I also emphasize that this process does not replace RfA, which would still be the only way to permanently obtain the complete set of tools. Dcoetzee 02:31, 1 December 2011 (UTC)[reply]
• Support one week tool use instalments for 3 month trial Dcoetzee has bent over backward to work this proposal out to suit our opinions. Not only for that reason, I am choosing to support this but for that ethos. The proposal is to try something new (and daring) and see what comes of it. It is being so well considered I trust it to be run well. One important point though: Just because the tools will only be handed out for use in one week instalments, this should not mean the requests should be treated less officiously. I very rarely agree with bureaucracy, but where weaponry is concerned, I think more is better. I'd be interested now to know what admin are on-side to watch over the wannabes trainees. fredgandt 02:50, 1 December 2011 (UTC)[reply]
  • Hi Fred, I appreciate your support, I know this wasn't an easy decision. I agree that requests even for a short period should be taken seriously. Monitoring of apprentices during the trial would be relatively easy since there are only 10 at a time - I'm definitely going to contribute, and I would make sure before the trial begins that we line up a sufficient number. Dcoetzee 03:08, 1 December 2011 (UTC)[reply]
    • Huh! Well would you look at that? You're an administrator! I didn't realise. I feel better already. fredgandt 03:52, 1 December 2011 (UTC)[reply]
• support trial per Chzz above; many of the opposes seem to be "change is needed, but not this change." At the very least, what this will lead to is a "no, we actually gave that a go, not just armchair speculation, but it didn't work out and this is what we've learnt" at WP:PEREN and a way forward for the future. Honestly speaking, I was never very keen on the idea of unbundling (y'know, the whole "well why can't they just be trusted with the whole gamut), but I can see how it would benefit some (why else would it be so frequently proposed?) and am willing to give it a go. I guess part of it is that I see now that the concept is not so much "we would rather you not have those tools, only this one", as "would you prefer to only have what's relevant"-- not that big an ask, and it removes the Very Big Weight from the shoulders of our (declining in proportion to activity on this project) active admin corps, and from the bit itself. Still cynical, but nothing ventured, nothing gained. sonia♫ 05:57, 1 December 2011 (UTC)[reply]
  • I see it as a solution looking for the wrong problem(s). It's still not clear whether it is intended to address the diminishing pool of admins, the diminishing number of candidates, or the unpleasantness and flippant and unresearched voting that has become commonplace at RfA. In my opinion it does neither, and is simply a noble attempt to implement a stand-alone experiment for the perennial issue of unbundling of the tools. We should really be looking at ways to improve the climate of the existing system and encourage participants to vote objectively and with civility. Do that, and we'll have all the admins we need, and who can be trusted with all the tools. Kudpung กุดผึ้ง (talk) 05:31, 2 December 2011 (UTC)[reply]
    • I don't necessarily disagree. However, one could argue that the article feedback tool etc are likewise a solution looking for a problem. However, it is clear that the one thing Wikipedia doesn't need is stagnancy. That's what the AFT is for, at least to be a "release" for reader dissatisfaction at the quality of what is becoming more widely used by the day, and provide a little constructive criticism for the editors. That's what the new NPP system is for, to radically change the way patrollers approach their task, and see if this improves conditions in that role. That's what the GEP is for, to bring Wikipedia if not credibility as a resource, at least a reputation as a modern teaching aid. That's what the Athena skin is for, to rebrand the project for an increasingly large share of our audience. The one major flaw of the wiki model is that, while it does scale to a project this large, new things that aren't led from above don't get tried very often because consensus is hard to come by. The Foundation isn't going to reform RfA unilaterally. Thus while I'm cynical about this particular idea, I think that any steps the community can take toward not just going around in circles disagreeing with itself or factionalizing into groups whose actions actively disrupt each other's goals are absolutely fantastic. For me, this proposal will provide closure to an oft-floated idea if it fails, and open the way for more dialogue if it succeeds. Either is good for progress of some sort, and that works for me. (It's also far, far more achievable than the vaguely pretty goal of "let's make people nicer to each other", however much I'd love that to be the case.) sonia♫ 09:48, 2 December 2011 (UTC)[reply]
      • All proposals for change should have a clearly defined objective. This one doesn't - it's simply an experiment for the sake of experiment and doesn't address any specific issues. All it offers is a fast-track to adminship for wannabes who can't /won't get the tools the regular way and is a veiled attempt to reduce the standards that are about right. There are plenty of people who meet those standards, and the only way to get them to come forward is to impress upon the voters who only go to RfA to be vindictive and get away with it, to either clean up their act or stay away. And this proposal is not designed to address that, so what is it for? As someone else inferred here, any mistakes the sorcerer's apprentices make, will be written down and taken in evidence - without the accompaniment by Dukas or the help of Goethe's gentle magician. Kudpung กุดผึ้ง (talk) 12:45, 2 December 2011 (UTC)[reply]
        • Hi Kudpung, this is an excellent point that I think would help to address concerns by others, so I've added Wikipedia:Tool_apprenticeship#Objectives_and_comparison_to_RfA. Responding to your earlier points, I believe the system described here would have value even if we had a surplus of administrators. Please have a look and let me know if you have any feedback. Re mistakes, see my response to Mkativerata. Dcoetzee 02:01, 3 December 2011 (UTC)[reply]
• Oppose WP:CREEP, and a solution without a problem. So if you say RFA is broken, then fix that; don't try to go around the problem. --Rschen7754 06:53, 1 December 2011 (UTC)[reply]

• The problem with trying to reform RfA comes in many parts, one of which is the number of people who say "RfA isn't broken", one of which is the small group of people referring to our attempts to clean up RfA by tagging us as "RfA Deform", one of which is the fact that a loud-voiced group of people strenuously object to any attempt at enforcement (and frequently attack people who attempt even a reminder) of civility and NPA at RfA, and so on. The other point, again, is that there are probably quite a few people (including myself) who don't want the full adminship hat and will therefore never ask for it, but who could make good use of a small subset of tools. (Like delete/undelete). Pesky (talk …stalk!) 10:20, 1 December 2011 (UTC)[reply]
• Hi Rschen7754, thanks for your feedback. As noted in my support above, the main problems intended to be solved by this proposal are: 1. helping to complete a lot of work around the project that requires admin tools, like CAT:CSD, vandal patrol, protection requests, etc.; 2. allowing users to gain hands-on experience with responsible use of tools according to policy with continual feedback, permitting a clearer assessment at any later RfA and increasing their confidence to run. Dcoetzee 20:05, 1 December 2011 (UTC)[reply]

• So the solution to the backlogs is... adding another backlog? This sounds like a lot of overhead. Also, we allow users to gain a lot of hands-on experience already; RC patrol is not restricted to admins, for example. Sending an AIV report illustrates the judgment that is necessary to determine if a user should be blocked. --Rschen7754 21:53, 3 December 2011 (UTC)[reply]

• Question: One part of me if quite glad to see that there is still some community vetting in the form of a 7 day "mini-rfa" if i may call it that, rather then just shoving this under WP:PERM where just one editor decides. However, one of the main drawbacks of a regular RFA (In my point of view) is that the requirements to be promoted tend to increase more and more. Is there anything that prevents this from happening here as well? As some editors mention: "If i trust them with one tool i trust them with all". However, if i read that the other way around it would state "If i don't trust them with all tools, i also won't trust them with one". What ensures that the current RFA standards won't simply flow over this light version of that process? Excirial ^{(Contact me,Contribs)} 11:22, 1 December 2011 (UTC)[reply]
  • Hi Excirial. In addition to the various restrictions on apprentices, such as short trial length and probation, there will be effective moderation of discussion including removal of discussion irrelevant to the tool/task area under request. Encouraging conditional supports in place of opposes will let concerned users set their own terms. Also, because it's a consensus discussion and not a vote, the closing bureaucrat can exercise discretion and assign less weight to less reasonable concerns. Dcoetzee 19:42, 1 December 2011 (UTC)[reply]
    • To be honest i doubt it will be that simple seeing some of the RFA's. Still, i will give this a Support as a trial only provided that implementing this change doesn't require a large share of development time to implement. I can see quite a few caveats and i do wonder if this will work out in the long run, but a trial won't hurt, and by now it might actually be a lot better to start working on a trial-and-error basis rather then discussing what should be done another few years without result. Excirial ^{(Contact me,Contribs)} 20:32, 1 December 2011 (UTC)[reply]
      • Thanks for your support! The dev time to implement the basic groups is literally seconds. Automatic "timeout" of rights would require more effort, but that can wait since bureaucrats can implement it manually in the meantime. Dcoetzee 20:47, 1 December 2011 (UTC)[reply]
• Oppose for various reasons already outlined, including bureaucratic overhead, propensity for drama etc., but above all because the notion of an applicant (for want of a better word) having an "immediate need" as set out in the justification for this proposal. How can someone have an immediate need but have to wait for a process to determine whether they are suitable to be given delete or block rights? It makes no logical sense. The "immediate need" would have to be scrutinised, why then an Admin. not just deal with it immediately? Leaky Caldron 18:29, 1 December 2011 (UTC)[reply]
  • Hi Leaky caldron, thanks for your feedback. It's clear that my intention wasn't accurately conveyed here. This is not intended for one-time cases, or for urgent situations, but for users who have an ongoing need for a tool and can start using it right away after receiving it (see the Example section for a typical example). I've revised the proposal to clarify this. Please let me know if this makes more sense to you. Dcoetzee 19:50, 1 December 2011 (UTC)[reply]
    • Someone having an "immediate need" for some of the tools smacks of their wanting them to "win" some content dispute or edit war. Edison (talk) 20:53, 1 December 2011 (UTC)[reply]
      • I think "Immediate need" should be read as "Would have an immediate use for that tool in their current line of work". Think about long term new page patrollers who might do well with the ability to delete pages themselves, or vandalism patrols who are capable of deciding if a user should be blocked. I presume the immediate part mostly means that this isn't some form of permission that you can request but never really use, such as people who only patrol a handful of new pages once a month or so. Excirial ^{(Contact me,Contribs)} 21:07, 1 December 2011 (UTC)[reply]
        • Yes, Excirial has the intended interpretation. I've rewritten that point to say "can start using it right away" rather than "immediate need" try to make this clearer. I don't want people requesting tools based on speculation about things they might use it for in the future, but only for things they're definitely going to use it for right after they get it. I'm open to suggestions on how to make this clearer. Dcoetzee 22:17, 1 December 2011 (UTC)[reply]
• Support seems sensible - and along the lines of granting bot access without the ordeal of 'placing candles under the feet' that is RFA. Just keep the block button out of the tools set and we'll all breathe easy. --Joopercoopers (talk) 01:32, 2 December 2011 (UTC)[reply]
• Oppose We all know full well that these apprenticeships (including on a trial basis) will be gamed by editors who blast away making totally uncontroversial blocks, deletions and protections until they get the big prize. Of course, that's not to say RfA isn't gameable as well, but we shouldn't make the process of becoming an admin even more gameable than it already is. And also because any marginal benefit brought about by this proposal, even on a trial basis, is outweighed by the expense of community time in administering yet another layer of bureaucracy. --Mkativerata (talk) 07:10, 2 December 2011 (UTC)[reply]
  • No, users will have to be evaluated before getting an apprenticeship. Please read my comment above about bureaucracy.Jasper Deng (talk) 07:14, 2 December 2011 (UTC)[reply]
    • If you're going to spam every comment on this page, at least understand what is being said. I don't care that users will be evaluated before getting an apprenticeship, except to say that it's more red tape. My point is the apprenticeship will be meaningless as any sensibly cynical editor will game it to smooth the passage through their future RfA. And yes, I did see your intervention regarding bureaucracy above, and I am most unconvinced, thank you. --Mkativerata (talk) 07:18, 2 December 2011 (UTC)[reply]
      • RfA is RfA, not this. Our purpose is to make RfA less stressful. Apprenticeship!=free pass at RfA, because commenters at RfA will still scrutinize the actions to determine readiness for all tools. This is only training, not admin coaching. When we train someone to drive, the test is made easier but whether the test is passed or not is up to the assesser.Jasper Deng (talk) 07:23, 2 December 2011 (UTC)[reply]
        • Your first sentence continues to show you haven't read what I said. Your second and third sentences contradict each other. Your fourth sentence is irrelevant. Your fifth sentence is an absurd analogy. Why can't people come here, make a comment, and not have to keep coming back when their comments get misconstrued or just plain spammed? --Mkativerata (talk) 07:28, 2 December 2011 (UTC)[reply]
          • I perfectly understand your comment: gaming the system and bureaucracy will increase. Scrutinizing still will be done for apprentices, but it will be more likely to pass based on work as an apprentice, with less criticism of things like "mislabeled this CSD." If you don't want me to reply to your comments, don't make them. (and while you're at it, please don't make comments on my comments ("...is an absurd analogy."))Jasper Deng (talk) 07:32, 2 December 2011 (UTC)[reply]
            • There will still be RfA which is always partly a (un)popularity contest. This system will not deprive the wolf-pack of their favourite hunting ground when applications for the tools reach normal RfA stage. And if you believe it will, I'd like to hear how. Kudpung กุดผึ้ง (talk) 07:42, 2 December 2011 (UTC)[reply]
              • In fact if you believe in the wolf-pack theory (lets pretend for a moment that I do), this would only make things worse. Any errors during the trial would be blown out of proportion. And if the trialist did well, the wolves could say "you're just a badge collector who used the tools uncontroversially for a week or so to boost your RfA prospects". --Mkativerata (talk) 07:49, 2 December 2011 (UTC)[reply]
  • @Mkativerata: If I'm understanding your objection, the idea seems to be that voters at RfA will assign too much weight to success and failure at apprenticeship, allowing the unready to pass and unfairly rejecting those who make a few small errors while learning. While this is possible, at least at first, I think it far more likely that the voters at RfA will assign appropriate weight to apprenticeship experience in their decision, well aware of these possibilities (and I would be the first to chastise voters who do otherwise). Your argument would apply to anything a user does that could increase their chances of passing RfA, such as working on featured articles, mentoring newbies, tagging articles for speedy deletion, discussing policy etc. We haven't banned these activities for at least two reasons: 1. RfA voters weigh this experience appropriately; 2. it's important work to get done. The same applies here. Dcoetzee 01:49, 3 December 2011 (UTC)[reply]
• Oppose Last I checked, there were 1500+ admins; I've never found a case where action was needed where one wasn't available. The key element of administrators is judgement, not technical prowess in a particular area. Either an editor can be trusted not to use an admin capability in an area they weren't sufficiently familiar with to use wisely, or they're not ready to be an admin. Have we all forgotten WP:NOBIGDEAL? Gerardw (talk) 03:43, 2 December 2011 (UTC)[reply]
  • Hi Gerardw, thanks for your feedback. You're right that merely finding an admin is not hard - but at any instant there is a lot of administrative work waiting to be done around the project, and getting more of it done faster is a good thing. Re "technical prowess": this isn't about learning how to use a tool technically (which could be learned on Test Wiki) but about learning to use tools in compliance with policy, which is much more difficult. Re your final comment: while we do trust the judgement of admins to be careful, admins are not in fact given access to all tools (checkuser, oversight, bureaucrat), nor are they guaranteed to pass a request for these tools. Likewise, some apprentices who can capably use a single tool might not be prepared to pass a full RfA (or even if they are, they might feel more comfortable developing confidence with compliant use of the tools first). Dcoetzee 02:52, 3 December 2011 (UTC)[reply]
    • You are not a checkuser or oversighter because the community does not trust you with the tools. You're not a checkuser or oversighter because you haven't asked for the additional tools. You'll find out if the community 'trusts' you with them if and when you apply for them, and not before. Perhaps your proposal should be the paradigm for admins to have checkuser and oversighter on a trial basis. Kudpung กุดผึ้ง (talk) 15:15, 3 December 2011 (UTC)[reply]
      • I did not claim that the community doesn't trust them with these tools. I merely said that they are not given access to these tools, and are not guaranteed to pass a request for these tools, which is true. Dcoetzee 23:50, 3 December 2011 (UTC)[reply]
• Support trial for now. This should narrow the permissions gap. Marcus Qwertyus 13:33, 3 December 2011 (UTC)[reply]
• Strong oppose. Getting the sysop flag is not and should not be a big deal. We don't need 172 permissions. If the community trusts the user, he'll pass an RfA. If he wouldn't pass an RfA, we have no business devising a scheme for him to get the rights anyway. If the candidate's good and should have the tools, he should have all of them, thru a proper RfA. If not, he has no business having some. Snowolf ^{How can I help?} 21:26, 3 December 2011 (UTC)[reply]
  • Thanks for your feedback, Snowolf. Please see Wikipedia:Tool_apprenticeship#trust. Dcoetzee 23:50, 3 December 2011 (UTC)[reply]
    • I agree with that section but it doesn't address the issue of, If we don't trust a user enough to give them all the tools, why should we trust them with one tool when it's inefficient to do so? For example, consider a user who creates a page that is a copyvio and under a title that has already been deleted before. In this case, the user needs to be blocked, the title needs to be deleted, and it also should be salted. That's three different tools: blocking, deletion, and protection. Why are we giving someone the delete button and then making him/her have to find someone to push the protect button, and another person to hit the block button? Why can't we just stick with the simple and easy system of "you get all three buttons or you get none"? Furthermore, the comparisons in the "trust" section linked above are not applicable to administratorship; rollback exists because there is such a high level of vandalism and also because it is not difficult (regardless, I think our standards for that are too low because I constantly see users misusing it and driving away newbies!). Bureaucrats can hand out (and take away) admin rights, so it would be unreasonable to expect that anyone capable of adminship is capable of bureaucratship—yet no one is suggesting we divide up the crat abilities! /ƒETCHCOMMS/ 00:12, 4 December 2011 (UTC)[reply]
      • As for bureaucrats, we don't have a shortage of them, so we have no need for division of their tools.Jasper Deng (talk) 00:20, 4 December 2011 (UTC)[reply]
      • @Fetchcomms: Wikipedia:Tool_apprenticeship#overspecialization. Some tasks do require multiple tools to deal with, but apprentices would be focusing on tasks that don't (which are plentiful), and admins would still be around to work on those that do. I've removed bureaucrats from the response, since checkuser and oversight are better examples anyway - the point is these are tools that for one reason or another we don't give to all administrators automatically. Nevertheless administrators remain productive in tasks that don't require access to these tools, and by analogy apprentices can also be productive with their limited tool set. Dcoetzee 00:31, 4 December 2011 (UTC)[reply]
    • I've read the section. I don't agree with your reasoning however. It's a fallacy to compare rollback, a right that was granted years after everybody and their mother had thru tools such as Vandalproof, lupin's popups and various js that offered limited rollbacks, with the rights you propose to give to other users. Rollback was never admin-exclusive, the technical ability to do so thru mediawiki itself was. To me, if a user doesn't pass an RfA for any reason, he should be blocking users or protecting pages. Sysop is no more of a big deal then any of the single user rights. It's no big deal, let's stop treating it like it is. If a user fails an RfA, he has no business getting the tools, if he wants to block user, no harm in a RfA. I fail to understand what's wrong with RfA that needs to be fixed in this way... Snowolf ^{How can I help?} 05:41, 4 December 2011 (UTC)[reply]
      • The way RfA works makes adminship quite a big deal.Jasper Deng (talk) 05:57, 4 December 2011 (UTC)[reply]
        • Adminship is no big deal, as any sysop knows. Most of the time it's even more trouble than it's worth going through RfA for. Those troubles will be encountered by anyone who is given the tools through whatever process. Getting through RfA is the only big deal - like getting through boot camp with a bullying Sergent Major. Nevertheless, it is human internet nature for many people to regard any level of moderatorship on any run-of-the-mill web forum as a big deal - again, only until they actually get the tools. — Preceding unsigned comment added by Kudpung (talk • contribs) 06:57, 4 December 2011 (UTC)[reply]
          • Adminship is being regarded as a big deal, which is what RfA reflects. Wikipedia, at least the English-language project, is not a "run-of-the-mill web forum", and adminship has greater significance than moderating a forum. (I should know; I've modded a few in my time.) That Wikipedia is so widely used that hoaxes started here can perpetuate throughout the web means that we have increasingly started to take ourselves, as curators and creators of content, and thus the admin position, more seriously. This proposal limits the damage that an individual who has not stood for the full gamut can do, by restricting the number of buttons that can be pushed (no inadvertent editing of the MediaWiki space or viewing of compromising deleted content, for example), and also through removing the virtually "for life" nature of adminship in favour of a speedy removal process, both of which should relieve some of the community-created pressure. In exchange we get more efficiency since the gnomes who maintain an area or two are able to do more independently without the need to go off and create content or report vandalism or whatever is currently needed at RfA. sonia♫ 09:07, 4 December 2011 (UTC)[reply]
• Support, per User:OlEnglish: "if it turns out to be a kind of paradigm shift in Wikipedia administration then great, if it crashes and burns, then that's great too." Change is good. --Conti|✉ 10:31, 4 December 2011 (UTC)[reply]
• Oppose - As well intentioned as this proposal is, I suspect that introducing a two-tiered system of trustworthy users will, with time, only evolve into another barrier which can only even further reduce the relative number of willing and successful candidates at RfA. If a user is truly (1) in good standing with the community, (2) has an immediate and ongoing need for administrative tools, and (3) is active and has sufficient experience in a relevant area, then they would generally be justified in requesting adminiship. If we cannot adequately facilitate such legitimate requests, then the underlying problems need to be confronted and resolved.   — C M B J   21:23, 4 December 2011 (UTC)[reply]