Wikipedia talk:WikiProject on Adminship/a la carte

Review deleted[edit]

Where would you put the admin rights to review deleted article histories and content, etc? Georgewilliamherbert 19:04, 7 August 2006 (UTC)[reply]

That's part of the "undelete" permission. —Simetrical (talk • contribs) 03:28, 8 August 2006 (UTC)[reply]

Bad idea[edit]

This is a terrible idea. The whole of admins is that they are just like any other editor, except that they are considered trustworthy enough to use some of the more powerful tools on the site, and sensible enough to make up their own minds about how to use them. The very low rate of de-adminning is a testament to how well this works. Creating specialized cadres of restricted, less-trusted, admins would be a step backwards. -- The Anome 19:08, 7 August 2006 (UTC)[reply]

But it's not just a matter of trust. It's a matter of good-faith opinions that may differ from our policy, and a matter of policy knowledge. I can give you a lengthy list of adminship candidates opposed just within the last month on the basis of lack of knowledge or experience in areas where they didn't say they would use their admin tools. These would-be admins lack the tools they could use to help the project because of the structure of the current admin system. —Simetrical (talk • contribs) 03:28, 8 August 2006 (UTC)[reply]

It's a bad idea. Multiple classes of admin privs invite confusion. The average editor is a bit unclear on exactly what privs the (single) admin class has now; complicating the situation can only make community participation in RfA less well informed. The clever/unclever name-of-class mini-issue obscures the basic truth that some admin functions are more "powerful" or "dangerous" than others. Thus this scheme does not split admins horizontally but ranks them vertically, in effect creating a deeper hierarchy. I might be willing to entertain one such new rank, either below or above the existing admin rank -- but I'm not sure that's a solution, either.

Part of the method of the current adminship paradigm is that each admin does indeed have broad scope. This fosters project-wide involvement and admins who share the Big Picture. The reductio ad absurdum is to suggest that an editor be promoted to poke-adminship who has demonstrated ability and temperament to manage contentious Pokemon-related issues -- and nothing else.

We don't need more admins with blinders on; that's part of the problem. We need admins with broad appreciation for community values and project needs. For that matter, the current crisis in adminship is not because we're not promoting candidates who might do well in some area. That is never a problem. Failed candidates often whine and weep but it's really no big deal and many a fine editor is unsuitable for adminship. I oppose any change that will permit even more generally unsuitable candidates from weaseling their way into the admin ranks.

No, the problem is that far too many candidates are being promoted who are likely to do poorly. The current system rewards those who support candidates while any opposition invites a shitstorm of contention from supporters. This model holds all the way down to some threshold, under which negative comments snowball into a shitstorm of increasingly nasty opposes. This tends to alienate the unsuccessful candidate -- who, even if unsuitable as admin, generally does not deserve this venom. But this is an inevitable expression of psychodynamic equilibrium: RfA regulars may promote reflexively seeking brown-nose points; to appear balanced, even within their own minds, they must bash the occasional candidate very hard indeed. The root of the problem is the positive return on support comments.

I'm deaf to demands for more admins based on excessive task backlog. It certainly will not help to promote new classes of admins who are forbidden to work off any of this backlog outside of their narrow specialties.

If we want to "fix" RfA and adminship in general, then we need to think about how to keep admins from screwing up once promoted. We need to suppress the candidacies of editors who excel only in a narrow range of tasks and hence are popular among a small, vocal group of fellow editors. Such people may lack potential to grow. We need to foster the candidacies of admins who see the big picture and are temperamentally suitable for the job. We do need admins of all kinds but each needs to be permitted scope in which to grow. Otherwise, we foreshadow a divided bureaucrat class and eventually a Board that consists of editors with narrow interests. Not good. John Reid 08:12, 13 September 2006 (UTC)[reply]

Support[edit]

This is definitely the right move, it would make it easier to admin people who are not 'right' for all roles. There are certainly admins who are great in one area, but frankly make me nervous in others.

A few tweaks:

"enforcer" needs unblock rights
"copyright" should be renamed, those skills come up in defamation and office actions etc.
there should be a class just for editing the front page (and maybe similar high profile pages). It's not the same as editing style sheets etc, which are essentially technical qualifications.
I don't see anything about moving complicated pages, renaming categories etc.

Ta. Stevage 21:22, 7 August 2006 (UTC)[reply]

Unblock rights are part of the "block" privilege.
Not sure what you're suggesting here. The oversight group exists for defamation cases.
Editing the front page is an extremely low-maintenance job that could really be left to sysops only.
Renaming/moving stuff is part of the "deletion" group, which was intended to cover (non-copyright-related-)CSD, XFD, and so on, which includes move requests. A better name might be good, but I couldn't think of good names for any of the groups except antivandal ("copyright" and "tech" sound like they're affiliated with the Foundation, "enforcer" conjures an image of a big hulking thug with a baseball bat, and "deletion" includes non-deletion stuff). —Simetrical (talk • contribs) 03:28, 8 August 2006 (UTC)[reply]

Editing the Main Page is equivalent to editing a protected page outside the MediaWiki namespace, so it would be technically difficult to separate the two functions. That namespace is edit-protected to all those who have the "editinterface" permission enabled (sysops by default). Tito xd^(?!?) 21:45, 8 August 2006 (UTC)[reply]
I'm aware that anyone with the protect right can edit the main page. However, under this division of labor, some people will be prohibited from using their rights in particular instances. This is necessary to ensure that, for instance, someone who wants to help out at AFD doesn't get shafted because of lax copyright views: copyright issues would be handled by a different group, since they require different qualifications. —Simetrical (talk • contribs) 00:44, 10 August 2006 (UTC)[reply]

Protected pages[edit]

It would be nice for the purpose of this proposal if we had a standalone permission for being able to *edit* protected pages without being able to change the protection status on them. This would help clear backlogs on editing protected pages, without really giving any admin responsibilities. - Stephanie Daugherty (Triona) - Talk - Comment - 09:36, 10 August 2006 (UTC)[reply]

It would be cool if an admin A could give a non-admin user U the right to edit fully protected page P (delegation of trust for a specific page). Each user would then have a set of protected pages that she/he is allowed to edit (defaults to the empty set for non-admin users). This would be somewhat like the inverse of blocking, but specifically per page. Admins could observe how U behaves in editing P and remove the right if needed. --Ligulem 11:07, 10 August 2006 (UTC)[reply]

Work queues?[edit]

One way to limit some of these permission groups is to limit them to "work queues" wherever practical: For example, the AFD queue would replace or supplement the current AFD process. A "Special" page would be created to work with this queue. The Special page would automatically maintain the AFD discussion pages, and actual opening, discussion, and closure of AFD's would take place through the AFD interface. This would require specialized code for AFD, but it would shorten the process signifigantly, and it would allow us to restrict deletion rights to AFDs being closed.

I think this gets a little out of scope of the proposal at hand, but it does complement it nicely, in that permissions would not be free-ranging, but rather only usable in the circumstances for which they were granted. - Stephanie Daugherty (Triona) - Talk - Comment - 09:51, 10 August 2006 (UTC)[reply]