Knowledge talk:Tool apprenticeship/Archive 1

521:

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 :)

1048:

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.

1180:

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.

1224:

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.

2493:

edits to the proposal to address concerns, and/or refactor this discussion page or discourage irrelevant discussion. I will trust and accept the closer's judgement. If the proposal is accepted there is still some planning to do, to recruit supporting volunteers and set up resources, so the trial wouldn't start for a little while. If the proposal is rejected I'm likely to consider a more incremental and targeted proposal in a single area in need of more administrative support, and refine it within that subcommunity before requesting the community's feedback on it.

825: 1162:

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. —

31: 805:

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).

781:

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.

2519:

becoming an RfA requirement, all of which are more difficult to understand and evaluate in an abstract setting). The benefit of a more targeted proposal would be that its effects would be more contained and predictable, and that it would be a more incremental change. I would not pursue something that is only a slight modification of what has already been proposed, after the substantial effort everyone has invested in this discussion already.

1970:: The problem with the system at the momment is that you either get all the tools through a request for adminship or none of them (except for things like rollback). For example, a user might know everything there is to know about blocking users but might not be resonsable enough to be able to delete pages. This would act as a halfway house and the extra monitering of users makes sure that if they do abuse the tool, it is easy to take away. 540:

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.

1201:

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.

1134:

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). —

1903:

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.

714:

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.

127:

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.

1152:

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.

470:

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.

661:@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 1648:

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

1038:

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).

2440:

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

2151:

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

1937:

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

1756:

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

1037:

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

972:

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

938:

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.

884:

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

780:

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

469:

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

394:

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

2503:

I would caution against turning this into a European referendum, constantly brought back until the community gives the "right answer". If this fails, you should spend some time absorbing that a significant portion of the community wants no splitting of the admin bits, and not just come in trying to

2451:

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

2340:

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

1647:

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

1470:

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.

1223:

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

1200:

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

804:

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

784:

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

612:

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

485:

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

2166:

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

1204:

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

1051:

I know I'll probably be criticised for opposing this system, as I advocated such a system in the past, but time on Knowledge 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,

1043:

I'm that certain users show exemplary knowledge of certain areas of Knowledge'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

873:

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

642:

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

274:

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

126:

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

2286:- 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? 1887:

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,

1774:

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

1446:

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

1179:

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

695:

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

386:

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

345:

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

2492:

I'm out of town from tomorrow evening 17 Dec until 9 Jan on an international trip and may have limited connectivity. Since the RfC closure and advertising of this proposal on sitenotice are likely to occur during this interval, I just wanted to say that anyone here should feel free to make minor

1735:

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

520:

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

2518:

Based on a thorough review of the above opinions, people who object do so for different reasons. There are some who oppose any assignment of partial administrative rights, and others who have entirely different concerns (e.g. issues of abuse, evaluation, undoing mistakes, and the possibility of

1902:

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

1161:

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

1151:

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

1133:

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

713:

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

539:

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

98:

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

1047:

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

987:

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

589:

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

2024:

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

411:

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.

312:

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

569:

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

1938:

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.

2278:

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.

2069:, 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. — 2463:

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.

250:

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

1001:

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. —

2360:

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

1098:

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

570:

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.

1079:

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.

266:

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

2352:

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

324:. 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 2429:

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).

1052:

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. —

2147:

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.

1997:

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:

647:

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

1916:

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. —

371:

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.

1113:

2089:

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.

1864:

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.

1450:

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

1454:

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

2260:

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;

2303:

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

917:

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. —

2143:

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"

210:

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

590:

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. —

2170:

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.

2356:

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

1084:

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

1806:

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.

2456:

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

2418:

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:

2125:

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;

1120:

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

939:

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. —

1709:"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 1369:

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

205:

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

444:

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.

196:

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

2348:

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

665:

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

1561:

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. ~~

878:

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.

214:

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

1044:

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.

495:

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

1666:

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.

395:

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.

2212: 549:

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

851: 775: 798: 486:

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!

638:

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

2265:"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 1850:

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.

1217: 954: 933: 2268:"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. 1017: 2298:

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

2094: 1942: 1932: 1026: 973:(nominating/tagging pages, participating in discussions) and thus well-prepared to assume the deletion tool, while having little preparation for blocking. Or vice-versa. -- 963: 2112: 2140:

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"

1769: 1239:

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

605: 2474:

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.

2409: 2379: 2084: 1751: 1655:

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.

218:

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.

1685:

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. →

2174:

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.

1844: 718: 299:

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:

157: 131: 1109:

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.

1205:

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. —

761: 708: 690: 239:

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

1784:

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?

1103:

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

892: 564: 451: 416: 406: 350: 2245: 2219: 1330:

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

1248: 438:

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

982: 910: 901: 809: 136:

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.

2523: 2513: 1064: 996: 874:

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.

2441:

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.

1779: 1659: 735: 582: 544: 2206: 1907: 1859: 1464: 1228: 1184: 1174: 1156: 1146: 1128: 785:

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?

504: 490: 221:

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

2481: 2029: 1882: 1811: 1801: 1678: 625: 1829: 1634: 1595: 1581: 1556: 1609: 1443:

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:

120: 1897: 1757:

closing RfAs, while on many other projects they just execute the community's decision. I believe that some discretionary decision scope is sensible.

1541: 1704: 2290: 1730: 2497: 1614:

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. ~~

1519:

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.

2315:

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

2191: 2334: 1234: 887:

Additionally, my proposal dispenses with people getting "full sysop powers" altogether, except if they happen to eventually acquire them all.

533: 2271:"move-subpages", "suppressredirect" - because I very often help people manage userspace pages, and constantly have to ask admins to tidy up 1775:

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.

1508: 275:

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.

71: 66: 1713:- that they'll assign the right - then, I'm not sure about that; presently, those rights can only be assigned by bureaucrats, not admins. 479: 428:

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

2255: 2059: 1837: 1830: 286: 2018: 1600:

Also it seems to me that your requirements are higher than recommended requirements for rfa (5000 edits, sysop on other wikis, etc.)

1437: 897:

Added some responses to this to the page. I do realise the importance of directly addressing objections to prior similar proposals.

306:

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

1479: 613:

edminship without a vote, just by approval of the mentors. But I don't believe that this idea could go through in the community :)

2197:

Just out of curiosity, has anyone ever made a serious proposal to rename Administrator to Janitor, or perhaps some other term? --

1392: 755: 684: 151: 114: 88: 1088:

Having a user right dedicated solely to blocking that user can do nothing more, which would effectively limit their usefulness

1979: 959:

Thanks for the feedback - see the new section "Does this supplant or supplement RfA?", which I think addresses your concerns.

863:. Not only does that entry openly contradict itself ("Can't be done! Already done!"), but the reasoning is easily refutable: 696:

towards full status. Using your metaphor, to become a surgeon you still need to get your education in all areas of medicine.

1484: 833: 666: 2372: 2077: 2042:

How would that be decided? Who would make the decision? Would there be a certain opportunity for any others to object?

1925: 1744: 1010: 947: 926: 598: 47: 17: 2341:

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,

1022:

Yes, I agree that retaining the current RfA process at least for now is important for ensuring a smooth transition.

740:

The obvious answer is to do what we already have with OS and CU - have lists of specialists, and a list of GPs. :o)

1348:

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

559: 401: 338: 281: 84:

Please leave your comments below. Objections, approval, or suggestions for changes or extensions are all welcome.

2120: 232:

Finding admin to get a job done is at present very simple. It could be a great deal more difficult to find the

2274:

Add groups: Confirmed - to make it easier when I help new users, and they need to upload a file or move a page

669:

operating on my neck than I would be about the idea of my local GP (general / family practitioner) doing it!

434:

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

2487: 2388:

Re. key - sorry if the analogy wasn't great, but...on my shed, it's trivially simple and cheap to change the

2366: 2071: 1919: 1738: 1586:

My proposal misses many things that's why I said feel free to insert more / regroup it. It's just a skeleton

1004: 941: 920: 592: 2158:

So - if that is unrealistic / unlikely to happen, then perhaps some trial-system of temporary/partial SysOp

2001:

edits? Of course, exceptions could be made...but I'm mostly thinking of avoiding lots of NOTNOW candidates.

1311: 93: 2345:

if they are up to mischief. They aren't likely to willingly give it up: nor are admins who bend the rules.

1629: 1576: 1536: 365:

I don't want my police to be a rag-tag disperate group of wannabes with truncheons looking to acquire guns.

2037:

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

1352: 816: 749: 678: 515: 145: 108: 2293:, WRT "If we trust a user enough to give them one tool, we trust them enough to give them all of them." 1377: 229:

vandalism could only be cleaned up by some particular kind of admin, we could kiss this project goodbye.

461: 38: 1697: 1447:

needed, and common requested sets are expected to develop organically without technical intervention.

824: 1334: 1293: 1958:

the general idea. As it becomes more specific I may have questions or comments about specifics.

447:

I hope this addresses your concerns, but please let me know if you have other feedback. Thanks!

174:

Assuming that current admins would remain as they are we have a mildly hypocritical situation: "

1984: 741: 670: 137: 100: 1489:

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

258:

Summary: Some tools could be dished out in this fashion without causing too much trouble but

1992:

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

1124:

These are reasonable concerns and if I'm missing something still please explain. Thank you!

2213:

Knowledge:Village_pump_(proposals)/Archive_61#Rename_.22administrators.22_to_.22janitors.22

2137:. If it were much easier to remove, we wouldn't be so super-cautious about handing it out. 1547:

Actually I think that different requirements could be for certain permissions, see my post

1073:

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

847: 554: 396: 333: 276: 723:

Well, admins often have narrow specializations, too, but it is just up to their choice :)

8: 2241: 2202: 1388:

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

994: 2504:

peel off enough !votes to secure a narrow victory. I hope you are enjoying your trip.--

791: 2509: 2452:

with a right that obviously requires it, such as undeletion, which can be monitored.

2108: 1975: 906:

After further thought I have struck the idea of eliminating RfA at the present time.

165: 1409:

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

2349: 2100: 2066: 1764: 1673: 1625: 1572: 1532: 978: 730: 703: 620: 577: 528: 362:

If tools could be aquired by anyone at any time they could feel a little disposable

1840:

and an example entry. I'd like to get your feedback on it if possible. Thank you!

1275: 1265: 1950: 1893: 1855: 1605: 1591: 1552: 1433: 1244: 860: 843: 500: 475: 1307:

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

99:

journeyman or master in the same trade, and I think this might be a good idea.

46:

If you wish to start a new discussion or revive an old one, please do so on the

2402: 2327: 2237: 2198: 2184: 2167:

single action they take. Net result of that could be 6 new admins before Xmas.

2052: 2025:

requirements make a lot of sense, since different areas use different metrics.

2011: 1964: 1875: 1794: 1723: 1477: 989: 1692: 1069:

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

867:

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

2520: 2494: 2478: 2216: 2091: 2026: 1939: 1904: 1841: 1808: 1776: 1656: 1461: 1225: 1181: 1153: 1125: 1023: 960: 907: 898: 889: 806: 786: 715: 541: 487: 448: 413: 347: 179: 128: 85: 79: 2103:

style operation but with bureaucrats making the dessions instead of admins.

376:

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

185:

Admins come and go. If no more can be made then admins only go (retirement,

2505: 2434:

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

2312:

to do what; unbundling does have a lot of potential for instruction-creep.

2104: 1971: 2477:

Thanks again and please let me know if your concerns have been addressed.

1758: 1667: 1615: 1562: 1522: 974: 724: 697: 614: 571: 522: 1889: 1851: 1601: 1587: 1548: 1512: 1429: 1240: 1208: 1165: 1137: 1055: 496: 471: 2364:

Many of the points you mention are certinaly worth keeping in mind. —

2395: 2320: 2308:

I can imagine difficulty in telling who-does-what, and indeed who is

2236:

would certainly change the tone of most noticeboard discussions... --

2177: 2045: 2004: 1959: 1868: 1787: 1716: 1472: 175: 1687: 189:

life reasons, drama etc.). It is possible that we could end up with

988:

included apprenticing existing admins for each of their tools? --

2389: 553:

like those paramedic training days with the volunteer corpses.

2296:-this is pretty key, I believe. The refutation overleaf says, 2282:

One particularly problematic user right is, (deletedtext) -

1836:

Hey all, I'm planning to RfC this pretty soon so I prepared

1401:

View deleted history entries, without their associated text

634:

There are quite a lot of people (myself included) who just

2423:

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

776:

Most sensitive tools are also the most likely to be needed

2445:

One particularly problematic user right is, (deletedtext)

193:

admins. With no admins, who decides who gets what tools?

1428:

maybe you could insert your ideas or regroup it, thanks

1383:

Not create redirects from source pages when moving pages

2284:

View deleted text and changes between deleted revisions

2129:

My view of "The trouble with RfA", in brief: Adminship

1404:

View deleted text and changes between deleted revisions

200:have use of some tools. Who would fix it and how? 1460:Does this make sense? Thanks for your feedback. 313:experienced in tool apprenticeship discussions. 303:With no admins, who decides who gets what tools? 1340:Delete and undelete specific revisions of pages 1507:Has sysop access on 1 or more wiki (including 842:. That's all I have to say on this subject. 2162:a way forward. A hell of a lot of us think 2099:I think it would be good to have this as a 1831:Knowledge:Requests for tool apprenticeship 387:them. Deletion is not an urgent matter. 817:Knowledge:PEREN#Hierarchical_structures 14: 2065:I can see this being like an entry at 255:the guardianship of the encyclopaedia. 44:Do not edit the contents of this page. 1235:Question (permission list in details) 243:would be time consuming and wasteful. 2468:they cannot rectify their own errors 262:. However, I think this idea should 25: 2291:Responses to anticipated objections 23: 2232:Wow. Dominators and Dominatrixes? 1361:Edit other users' JavaScript files 24: 18:Knowledge talk:Tool apprenticeship 2537: 2215:, which was unanimously opposed. 2135:because it's so hard to remove it 2152:here to build an Encyclopaedia. 823: 29: 652:they want to, at a later stage. 1966:09:10, 17 November 2011 (UTC) 1424:IMHO no need to give to anyone 1373:and match level A requirements 13: 1: 2524:10:00, 28 December 2011 (UTC) 2514:09:46, 28 December 2011 (UTC) 2498:07:05, 17 December 2011 (UTC) 2482:17:15, 17 November 2011 (UTC) 2410:09:41, 17 November 2011 (UTC) 2380:09:14, 17 November 2011 (UTC) 2335:08:21, 17 November 2011 (UTC) 2192:08:21, 17 November 2011 (UTC) 2155:</gets off soapbox...: --> 2095:17:19, 17 November 2011 (UTC) 2085:11:10, 17 November 2011 (UTC) 2060:10:50, 17 November 2011 (UTC) 2030:17:19, 17 November 2011 (UTC) 2019:10:50, 17 November 2011 (UTC) 1943:05:25, 27 November 2011 (UTC) 1933:01:50, 27 November 2011 (UTC) 1908:23:33, 26 November 2011 (UTC) 1898:11:10, 26 November 2011 (UTC) 1883:11:07, 26 November 2011 (UTC) 1860:10:52, 26 November 2011 (UTC) 1845:02:14, 26 November 2011 (UTC) 1838:a mock-up of the request page 1812:07:01, 25 November 2011 (UTC) 1802:20:10, 24 November 2011 (UTC) 1780:17:38, 23 November 2011 (UTC) 1770:16:22, 23 November 2011 (UTC) 1752:09:31, 23 November 2011 (UTC) 1731:08:22, 23 November 2011 (UTC) 1705:02:54, 23 November 2011 (UTC) 1679:19:10, 20 November 2011 (UTC) 1660:17:59, 20 November 2011 (UTC) 1635:12:13, 24 November 2011 (UTC) 1610:14:20, 20 November 2011 (UTC) 1596:14:15, 20 November 2011 (UTC) 1582:14:00, 20 November 2011 (UTC) 1557:13:22, 20 November 2011 (UTC) 1542:12:53, 20 November 2011 (UTC) 1480:04:34, 25 November 2011 (UTC) 1465:17:54, 20 November 2011 (UTC) 1438:12:25, 20 November 2011 (UTC) 1284:no conflicts or edit warring 1282:account old at least 80 days 1272:account old at least 60 days 1249:12:15, 20 November 2011 (UTC) 1229:18:17, 20 November 2011 (UTC) 1218:01:03, 19 November 2011 (UTC) 1185:17:37, 18 November 2011 (UTC) 1175:10:58, 18 November 2011 (UTC) 1157:09:43, 18 November 2011 (UTC) 1147:02:49, 18 November 2011 (UTC) 1129:16:41, 17 November 2011 (UTC) 1065:11:03, 17 November 2011 (UTC) 1027:16:26, 17 November 2011 (UTC) 1018:08:59, 17 November 2011 (UTC) 997:08:10, 17 November 2011 (UTC) 983:01:56, 17 November 2011 (UTC) 964:16:26, 17 November 2011 (UTC) 955:01:31, 17 November 2011 (UTC) 934:01:10, 17 November 2011 (UTC) 911:16:26, 17 November 2011 (UTC) 902:20:06, 16 November 2011 (UTC) 893:19:28, 16 November 2011 (UTC) 885:is novel, is critical here). 859:I am of course familiar with 852:17:20, 16 November 2011 (UTC) 810:19:42, 16 November 2011 (UTC) 799:14:32, 16 November 2011 (UTC) 762:22:26, 19 November 2011 (UTC) 736:15:38, 19 November 2011 (UTC) 719:15:24, 19 November 2011 (UTC) 709:14:54, 19 November 2011 (UTC) 691:09:36, 19 November 2011 (UTC) 626:01:10, 19 November 2011 (UTC) 606:02:03, 19 November 2011 (UTC) 583:00:31, 19 November 2011 (UTC) 565:22:58, 18 November 2011 (UTC) 545:22:50, 18 November 2011 (UTC) 534:22:26, 18 November 2011 (UTC) 505:10:24, 18 November 2011 (UTC) 491:09:27, 18 November 2011 (UTC) 480:20:15, 17 November 2011 (UTC) 452:17:35, 17 November 2011 (UTC) 417:18:58, 17 November 2011 (UTC) 407:17:59, 17 November 2011 (UTC) 351:18:58, 17 November 2011 (UTC) 287:13:23, 17 November 2011 (UTC) 158:18:20, 17 November 2011 (UTC) 132:18:01, 17 November 2011 (UTC) 121:17:39, 17 November 2011 (UTC) 89:11:59, 16 November 2011 (UTC) 2246:06:54, 8 December 2011 (UTC) 2220:06:17, 8 December 2011 (UTC) 2207:03:34, 8 December 2011 (UTC) 2113:17:30, 7 December 2011 (UTC) 1980:17:28, 7 December 2011 (UTC) 7: 1485:Changes, including criteria 1358:Edit other users' CSS files 346:full sysop package around. 10: 2542: 1280:2500 non automated edits 1270:2000 non automated edits 2000:<mainspace? any?: --> 1503:Optional, but prefered: 1302:other users from editing 320:Potentially disastrous, 2121:Some comments from Chzz 1364:Edit the user interface 322:blind leading the blind 2256:More specific comments 1999:, at least <xx: --> 1262:Divided to two levels 2488:Out of town for a bit 1652:section of proposal). 1253:Here is my proposal: 42:of past discussions. 328:administrators with 236:to get things done. 1736:responsibility". — 667:my ace neurosurgeon 643:be sneezed at just 516:Comment from Pundit 234:right kind of admin 2211:All the time. See 1499:Got admin coaching 462:Support from Petrb 94:Pesky's comment(s) 2408: 2376: 2333: 2190: 2081: 2058: 2017: 1929: 1888:not just admins. 1881: 1800: 1748: 1729: 1633: 1580: 1540: 1418:Mass delete pages 1085:comfort/expertise 1014: 951: 930: 839: 796: 602: 271:would be) later. 77: 76: 54: 53: 48:current talk page 2533: 2407: 2405: 2399: 2393: 2378: 2374: 2369: 2332: 2330: 2324: 2318: 2299: 2189: 2187: 2181: 2175: 2083: 2079: 2074: 2057: 2055: 2049: 2043: 2038: 2016: 2014: 2008: 2002: 1993: 1931: 1927: 1922: 1880: 1878: 1872: 1866: 1799: 1797: 1791: 1785: 1767: 1761: 1750: 1746: 1741: 1728: 1726: 1720: 1714: 1703: 1700: 1695: 1690: 1676: 1670: 1624: 1621: 1618: 1571: 1568: 1565: 1531: 1528: 1525: 1216: 1211: 1173: 1168: 1145: 1140: 1063: 1058: 1016: 1012: 1007: 992: 953: 949: 944: 932: 928: 923: 830: 827: 792: 789: 752: 746: 733: 727: 706: 700: 681: 675: 623: 617: 604: 600: 595: 580: 574: 531: 525: 330:have-a-go-heroes 225:individuals. If 148: 142: 111: 105: 63: 56: 55: 33: 32: 26: 2541: 2540: 2536: 2535: 2534: 2532: 2531: 2530: 2490: 2403: 2397: 2394: 2371: 2365: 2353:responsibility. 2328: 2322: 2319: 2297: 2258: 2185: 2179: 2176: 2123: 2076: 2070: 2053: 2047: 2044: 2036: 2012: 2006: 2003: 1991: 1987: 1953: 1924: 1918: 1876: 1870: 1867: 1834: 1795: 1789: 1786: 1765: 1759: 1743: 1737: 1724: 1718: 1715: 1698: 1693: 1688: 1686: 1674: 1668: 1619: 1616: 1566: 1563: 1526: 1523: 1509:test-adminiship 1487: 1398:Undelete a page 1395: 1380: 1355: 1337: 1314: 1296: 1278: 1268: 1237: 1209: 1206: 1166: 1163: 1138: 1135: 1056: 1053: 1009: 1003: 990: 946: 940: 925: 919: 795: 787: 778: 750: 742: 731: 725: 704: 698: 679: 671: 621: 615: 597: 591: 578: 572: 529: 523: 518: 464: 198:no users at all 168: 146: 138: 109: 101: 96: 82: 59: 30: 22: 21: 20: 12: 11: 5: 2539: 2529: 2528: 2527: 2526: 2489: 2486: 2485: 2484: 2475: 2472: 2471: 2470: 2461: 2460: 2459: 2449: 2448: 2447: 2438: 2437: 2436: 2427: 2426: 2425: 2415: 2414: 2413: 2412: 2383: 2382: 2362: 2358: 2354: 2346: 2306: 2305: 2276: 2275: 2272: 2269: 2266: 2257: 2254: 2253: 2252: 2251: 2250: 2249: 2248: 2225: 2224: 2223: 2222: 2122: 2119: 2118: 2117: 2116: 2115: 2097: 2040: 2039: 2033: 2032: 1995: 1994: 1986: 1985:More questions 1983: 1952: 1949: 1948: 1947: 1946: 1945: 1914: 1913: 1912: 1911: 1910: 1862: 1833: 1828: 1827: 1826: 1825: 1824: 1823: 1822: 1821: 1820: 1819: 1818: 1817: 1816: 1815: 1814: 1682: 1681: 1663: 1662: 1653: 1645: 1644: 1643: 1642: 1641: 1640: 1639: 1638: 1637: 1520: 1517: 1516: 1501: 1500: 1497: 1496:25 log entries 1494: 1486: 1483: 1468: 1467: 1458: 1457: 1456: 1452: 1448: 1426: 1425: 1421: 1420: 1411: 1410: 1406: 1405: 1402: 1399: 1394: 1391: 1390: 1389: 1385: 1384: 1379: 1376: 1375: 1374: 1371: 1366: 1365: 1362: 1359: 1354: 1351: 1350: 1349: 1345: 1344: 1341: 1336: 1333: 1332: 1331: 1327: 1326: 1323:edit protected 1313: 1312:Protection set 1310: 1309: 1308: 1304: 1303: 1295: 1292: 1283: 1281: 1277: 1274: 1271: 1267: 1264: 1236: 1233: 1232: 1231: 1198: 1197: 1196: 1195: 1194: 1193: 1192: 1191: 1190: 1189: 1188: 1187: 1122: 1118: 1117: 1116: 1107: 1106: 1105: 1096:overall number 1092: 1091: 1090: 1077: 1076: 1075: 1049: 1045: 1040: 1039: 1035: 1034: 1033: 1032: 1031: 1030: 1029: 970: 969: 968: 967: 966: 936: 915: 914: 913: 904: 882: 881: 880: 871: 870: 869: 821: 820: 813: 812: 793: 777: 774: 773: 772: 771: 770: 769: 768: 767: 766: 765: 764: 711: 656: 655: 654: 653: 629: 628: 609: 608: 587: 586: 585: 567: 517: 514: 512: 510: 509: 508: 507: 463: 460: 459: 458: 457: 456: 455: 454: 445: 442: 441: 440: 432: 431: 430: 425: 424: 423: 422: 421: 420: 419: 384: 383: 382: 369: 368: 367: 359: 358: 357: 356: 355: 354: 353: 310: 309: 308: 292: 291: 290: 289: 256: 248: 247: 246: 245: 244: 230: 219: 212: 203: 202: 201: 167: 164: 163: 162: 161: 160: 95: 92: 81: 78: 75: 74: 69: 64: 52: 51: 34: 15: 9: 6: 4: 3: 2: 2538: 2525: 2522: 2517: 2516: 2515: 2511: 2507: 2502: 2501: 2500: 2499: 2496: 2483: 2480: 2476: 2473: 2469: 2466: 2465: 2462: 2458: 2454: 2453: 2450: 2446: 2443: 2442: 2439: 2435: 2432: 2431: 2428: 2424: 2421: 2420: 2417: 2416: 2411: 2406: 2401: 2400: 2391: 2387: 2386: 2385: 2384: 2381: 2377: 2368: 2363: 2359: 2355: 2351: 2347: 2344: 2339: 2338: 2337: 2336: 2331: 2326: 2325: 2316: 2313: 2311: 2302: 2301: 2300: 2294: 2292: 2287: 2285: 2280: 2273: 2270: 2267: 2264: 2263: 2262: 2247: 2243: 2239: 2235: 2231: 2230: 2229: 2228: 2227: 2226: 2221: 2218: 2214: 2210: 2209: 2208: 2204: 2200: 2196: 2195: 2194: 2193: 2188: 2183: 2182: 2172: 2168: 2165: 2161: 2156: 2153: 2149: 2145: 2141: 2138: 2136: 2132: 2127: 2114: 2110: 2106: 2102: 2098: 2096: 2093: 2088: 2087: 2086: 2082: 2073: 2068: 2064: 2063: 2062: 2061: 2056: 2051: 2050: 2035: 2034: 2031: 2028: 2023: 2022: 2021: 2020: 2015: 2010: 2009: 1989: 1988: 1982: 1981: 1977: 1973: 1969: 1965: 1963: 1962: 1957: 1944: 1941: 1936: 1935: 1934: 1930: 1921: 1915: 1909: 1906: 1901: 1900: 1899: 1895: 1891: 1886: 1885: 1884: 1879: 1874: 1873: 1863: 1861: 1857: 1853: 1849: 1848: 1847: 1846: 1843: 1839: 1832: 1813: 1810: 1805: 1804: 1803: 1798: 1793: 1792: 1783: 1782: 1781: 1778: 1773: 1772: 1771: 1768: 1762: 1755: 1754: 1753: 1749: 1740: 1734: 1733: 1732: 1727: 1722: 1721: 1712: 1708: 1707: 1706: 1701: 1696: 1691: 1684: 1683: 1680: 1677: 1671: 1665: 1664: 1661: 1658: 1654: 1651: 1646: 1636: 1631: 1627: 1622: 1613: 1612: 1611: 1607: 1603: 1599: 1598: 1597: 1593: 1589: 1585: 1584: 1583: 1578: 1574: 1569: 1560: 1559: 1558: 1554: 1550: 1546: 1545: 1544: 1543: 1538: 1534: 1529: 1514: 1510: 1506: 1505: 1504: 1498: 1495: 1492: 1491: 1490: 1482: 1481: 1478: 1476: 1475: 1466: 1463: 1459: 1453: 1449: 1445: 1444: 1442: 1441: 1440: 1439: 1435: 1431: 1423: 1422: 1419: 1416: 1415: 1414: 1408: 1407: 1403: 1400: 1397: 1396: 1387: 1386: 1382: 1381: 1372: 1368: 1367: 1363: 1360: 1357: 1356: 1353:Interface set 1347: 1346: 1342: 1339: 1338: 1329: 1328: 1324: 1320: 1316: 1315: 1306: 1305: 1301: 1298: 1297: 1291: 1289: 1285: 1273: 1263: 1260: 1258: 1254: 1251: 1250: 1246: 1242: 1230: 1227: 1222: 1221: 1220: 1219: 1214: 1212: 1202: 1186: 1183: 1178: 1177: 1176: 1171: 1169: 1160: 1159: 1158: 1155: 1150: 1149: 1148: 1143: 1141: 1132: 1131: 1130: 1127: 1123: 1119: 1115: 1111: 1110: 1108: 1104: 1101: 1100: 1097: 1093: 1089: 1086: 1082: 1081: 1078: 1074: 1071: 1070: 1068: 1067: 1066: 1061: 1059: 1050: 1046: 1042: 1041: 1036: 1028: 1025: 1021: 1020: 1019: 1015: 1006: 1000: 999: 998: 995: 993: 986: 985: 984: 980: 976: 971: 965: 962: 958: 957: 956: 952: 943: 937: 935: 931: 922: 916: 912: 909: 905: 903: 900: 896: 895: 894: 891: 888: 883: 879: 876: 875: 872: 868: 865: 864: 862: 858: 857: 856: 855: 854: 853: 849: 845: 840: 838: 837: 835: 828: 826: 818: 815: 814: 811: 808: 803: 802: 801: 800: 797: 790: 782: 763: 759: 758: 753: 747: 745: 739: 738: 737: 734: 728: 722: 721: 720: 717: 712: 710: 707: 701: 694: 693: 692: 688: 687: 682: 676: 674: 668: 664: 660: 659: 658: 657: 651: 646: 641: 637: 633: 632: 631: 630: 627: 624: 618: 611: 610: 607: 603: 594: 588: 584: 581: 575: 568: 566: 563: 562: 558: 557: 552: 551:playing along 548: 547: 546: 543: 538: 537: 536: 535: 532: 526: 513: 506: 502: 498: 494: 493: 492: 489: 484: 483: 482: 481: 477: 473: 468: 453: 450: 446: 443: 439: 436: 435: 433: 429: 426: 418: 415: 410: 409: 408: 405: 404: 400: 399: 393: 392: 391: 390: 389: 388: 385: 381: 377: 374: 373: 370: 366: 363: 360: 352: 349: 344: 343: 342: 341: 337: 336: 331: 327: 323: 319: 318: 317: 316: 315: 314: 311: 307: 304: 301: 300: 298: 297: 296: 295: 294: 293: 288: 285: 284: 280: 279: 273: 272: 270: 265: 261: 257: 254: 249: 242: 238: 237: 235: 231: 228: 224: 220: 217: 216:pseudo admins 213: 209: 204: 199: 195: 194: 192: 188: 184: 183: 181: 180:Nouveau riche 177: 173: 170: 169: 159: 155: 154: 149: 143: 141: 135: 134: 133: 130: 125: 124: 123: 122: 118: 117: 112: 106: 104: 91: 90: 87: 73: 70: 68: 65: 62: 58: 57: 49: 45: 41: 40: 35: 28: 27: 19: 2491: 2467: 2455: 2444: 2433: 2422: 2396: 2342: 2321: 2317: 2314: 2309: 2307: 2295: 2288: 2283: 2281: 2277: 2259: 2233: 2178: 2173: 2169: 2163: 2159: 2157: 2154: 2150: 2146: 2142: 2139: 2134: 2133:a big deal, 2130: 2128: 2124: 2046: 2041: 2005: 1996: 1990:Requirement 1967: 1960: 1955: 1954: 1869: 1835: 1788: 1717: 1710: 1649: 1518: 1502: 1488: 1473: 1469: 1427: 1417: 1412: 1393:Undelete set 1378:Redirect set 1343:Delete pages 1322: 1318: 1299: 1287: 1286: 1279: 1269: 1261: 1257:Requirements 1256: 1255: 1252: 1238: 1207: 1203: 1199: 1164: 1136: 1112: 1102: 1095: 1087: 1083: 1072: 1054: 886: 877: 866: 841: 832: 831: 829: 822: 783: 779: 756: 743: 685: 672: 662: 649: 644: 639: 635: 560: 555: 550: 519: 511: 466: 465: 437: 427: 402: 397: 379: 375: 364: 361: 339: 334: 329: 325: 321: 305: 302: 282: 277: 268: 263: 259: 252: 240: 233: 226: 222: 215: 207: 197: 190: 186: 171: 152: 139: 115: 102: 97: 83: 60: 43: 37: 1711:technically 1455:requesting. 1321:levels and 1288:Permissions 380:individuals 36:This is an 2367:This, that 2343:especially 2072:This, that 1920:This, that 1739:This, that 1493:5000 edits 1335:Delete set 1319:protection 1005:This, that 942:This, that 921:This, that 844:Beeblebrox 636:don't want 593:This, that 178:" verses " 2390:(pad)lock 2373:the other 2350:WP:REFUND 2238:Guy Macon 2199:Guy Macon 2101:WP:RFPERM 2078:the other 2067:WP:RFPERM 1926:the other 1745:the other 1513:incubator 1294:Block set 1213:• 11:03am 1142:• 12:49pm 1121:increase. 1114:necessary 1011:the other 948:the other 927:the other 599:the other 253:seriously 176:Old money 166:Responses 72:Archive 3 67:Archive 2 61:Archive 1 2521:Dcoetzee 2495:Dcoetzee 2479:Dcoetzee 2289:Re. the 2217:Dcoetzee 2092:Dcoetzee 2027:Dcoetzee 1940:Dcoetzee 1905:Dcoetzee 1842:Dcoetzee 1809:Dcoetzee 1777:Dcoetzee 1657:Dcoetzee 1630:contribs 1577:contribs 1537:contribs 1462:Dcoetzee 1413:Others: 1226:Dcoetzee 1182:Dcoetzee 1170:• 8:58pm 1154:Dcoetzee 1126:Dcoetzee 1060:• 9:03pm 1024:Dcoetzee 961:Dcoetzee 908:Dcoetzee 899:Dcoetzee 890:Dcoetzee 861:WP:PEREN 807:Dcoetzee 716:Dcoetzee 542:Dcoetzee 488:Dcoetzee 449:Dcoetzee 414:Dcoetzee 348:Dcoetzee 269:rollback 241:leg-work 211:cutlery? 172:Comments 129:Dcoetzee 86:Dcoetzee 2506:Wehwalt 2361:hurt... 2357:moment. 2310:allowed 2105:Oddbodz 1972:Oddbodz 1968:Support 1956:Support 1951:Support 1650:replies 1317:Change 663:because 645:because 467:Support 326:replace 260:not all 208:special 39:archive 2375:(talk) 2370:, and 2080:(talk) 2075:, and 1928:(talk) 1923:, and 1760:Pundit 1747:(talk) 1742:, and 1669:Pundit 1628:on my 1626:report 1575:on my 1573:report 1535:on my 1533:report 1013:(talk) 1008:, and 975:RL0919 950:(talk) 945:, and 929:(talk) 924:, and 757:stalk! 726:Pundit 699:Pundit 686:stalk! 640:myself 616:Pundit 601:(talk) 596:, and 573:Pundit 524:Pundit 378:select 223:select 153:stalk! 116:stalk! 2398:Chzz 2323:Chzz 2180:Chzz 2048:Chzz 2007:Chzz 1890:Petrb 1871:Chzz 1852:Petrb 1790:Chzz 1766:utter 1719:Chzz 1675:utter 1623:~~ → 1602:Petrb 1588:Petrb 1570:~~ → 1549:Petrb 1530:~~ → 1430:Petrb 1325:pages 1300:Block 1241:Petrb 1210:James 1167:James 1139:James 1057:James 788:Monty 744:Pesky 732:utter 705:utter 673:Pesky 622:utter 579:utter 530:utter 497:Petrb 472:Petrb 140:Pesky 103:Pesky 80:Start 16:< 2510:talk 2457:key. 2304:key. 2242:talk 2234:That 2203:talk 2164:some 2109:talk 1976:talk 1961:Pine 1894:talk 1856:talk 1606:talk 1592:talk 1553:talk 1474:Pine 1451:not. 1434:talk 1370:harm 1245:talk 1094:The 979:talk 848:talk 834:Plip 751:talk 680:talk 501:talk 476:talk 264:only 187:real 147:talk 110:talk 1998:--> 1620:123 1617:Ebe 1567:123 1564:Ebe 1527:123 1524:Ebe 1511:on 794:845 227:all 182:". 2512:) 2404:► 2392:. 2329:► 2244:) 2205:) 2186:► 2160:is 2131:is 2111:) 2054:► 2013:► 1978:) 1896:) 1877:► 1858:) 1796:► 1725:► 1608:) 1594:) 1555:) 1521:~~ 1436:) 1290:: 1259:: 1247:) 981:) 850:) 819:. 760:) 689:) 650:if 503:) 478:) 332:. 191:no 156:) 119:) 2508:( 2240:( 2201:( 2107:( 1974:( 1892:( 1854:( 1763:| 1702:. 1699:c 1694:τ 1689:Σ 1672:| 1632:. 1604:( 1590:( 1579:. 1551:( 1539:. 1515:) 1432:( 1276:B 1266:A 1243:( 1215:• 1172:• 1144:• 1062:• 991:œ 977:( 846:( 836:! 754:… 748:( 729:| 702:| 683:… 677:( 619:| 576:| 561:g 556:f 527:| 499:( 474:( 403:g 398:f 340:g 335:f 283:g 278:f 150:… 144:( 113:… 107:( 50:.

Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.

Knowledge

talk:Tool apprenticeship/Archive 1 - Knowledge

Index