Wikipedia:Moderators/Proposal/2013

This is a failed proposal.

Consensus for its implementation was not established within a reasonable period of time. If you want to revive discussion, please use the talk page or initiate a thread at the village pump.

See also the straw poll and discussion of this proposal.

Before commenting, please read the proposal below thoroughly.

Proposal

Proposal: A new user-right package (aka user group) designed primarily to allow those entrusted with adminship the option to continue to help with content-related admin tasks (for which there is often a backlog), even if they wish to no longer carry the rest of the sysop package of user-rights. – For example, to allow for implementing the close of content-related discussions like: RM; DRV; AfD / CfD / FfD / TfD / MfD / etc.; various talk page and noticeboard RfCs; and so on. In addition, assessing CSD, and PROD, and edit-protected requests, and other such content-related tasks which would be related to the tools granted in this user-rights package. But which does not include all the user-rights in the sysop group. User-rights which do not deal with content issues, and in particular user-rights which are related to the assessing of user behaviour are specifically not included.

While non-admins do help with some of this, our current policy/guideline regarding non-admin closures is essentially: "if you don't have the tools to implement a close, you shouldn't be closing the discussion". And also that non-admins shouldn't close "close" or "contentious" discussions. (This latter point is sometimes complained about by some experienced editors – who feel that they should be able to close such discussions – however, it has been repeatedly upheld in discussion.)

So this user-right package would be helpful/useful by allowing the editor the opportunity to retain the tools to implement the close of such discussions, while still allowing them to request removal of the rest of the tools of adminship.

In broad terms, this means that those with this user-right package should have the ability to: delete/undelete pages (and related abilities); move most pages (and related abilities); deal with files; and edit protected pages.

What this user group may include in the future – Only those tools which are directly related to the intended usage explained above.

What this user group should NEVER include: Any tools which directly deal with the assessing of editor behaviour. In particular: protect or block-related tools. Semi-related to this, no tools which grant user-rights to editors. I also did not include a couple rarely used deletion tools. If the moderator needs such things done, they can simply re-request adminship back, or just find another admin.

Rollbacker and autopatrolled are specific separate user-right groups. Reviewer is a user-right package which essentially deals with marking certain edits as patrolled/reviewed/viewable. All of these (and other such) tools are handed out by admins through the WP:RFPERM process, and there is no need for a closer to directly have these abilities. Though the editor is of course welcome to request such tools (through the standard processes), with the standard rules and restrictions applicable as normal.

To be clear, though this user-right group does not grant the user all of the tools in the administrator user-rights package, moderator still falls under all the adminship-related Wikipedia policies and guidelines, and so would be subject to all the rules and restrictions of adminship, without the title or all the tools.

Granting and removal

Granting and removal of moderator is done by Bureaucrats at the Bureaucrat's noticeboard, in the same way removal of adminship is requested there.

This package may be requested by any former admin who is eligible for restoration of adminship. And so of course, any current administrator may request that a bureaucrat remove their adminship tools (thus making them a "former admin"), and subsequently grant this user-right group instead.

The request may obviously coincide with a request for one or more admin-granted tools, such as rollback.

And just like adminship, anyone with this user-right package may request its removal. Removal of moderator falls under the same rules as administrator. And so, just like adminship, as long as removal of moderator was not "under a cloud", it may be restored by any bureaucrat per the normal rules.

And if someone does decide to go from admin to this group package while "under a cloud", they can only re-gain adminship through the normal RfA process. And of course, anyone doing this while under a cloud may still have this package removed, just as adminship can be removed. (In other words, switching to this package should in no way be considered a way to avoid or bypass anything, including sanction.)

Again, to be clear, this all falls under all the various currently-existing policies and processes, and should not be considered any sort of exception to them.

So why would anyone want to request this?

Several reasons.

Believe it or not, such a user-right group has actually been requested repeatedly for a very long time.

For one thing, there are Wikipedians (like Wikignomes) who are happy to help with content, but really don't want anything to do with the block/protect tools, or being expected to deal with behavioural issues. For them, this would be a perfect fit.

Forcing an admin to carry tools related to assessing editor behaviour, when they may merely want to help out on the content side of things, just seems wrong. some editors just don't want to carry such tools or to have any of the potential responsibilities that go with it.

Forcing people to accept certain tools which they do not want simply because we think they can be trusted with them is simply wrong in my opinion.

The current administrator tool group includes a LOT of tools. And arbitrarily keeping trusted individuals from certain other tools because they refuse to carry "the whole admin package" seems foolish (counter-productive) on our part as a volunteer project.

And with that in mind, the tools in this package were not arbitrarily selected, they were particularly chosen due to their interdependent usage for various content-related tasks and responsibilities.

We have a tradition on Wikipedia that people contribute at whatever level they are comfortable with.

This is merely an extension of that tradition.

And wouldn't it be great if this helped nudge a few former admins back into activity? : )

In closing

Thank you for bearing with this and reading this all. I welcome your thoughts on this proposal on the discussion page.

Again, thank you. And if anything seems unclear, please ask, I'm more than happy to clarify. I look forward to everyone's thoughts on this. – jc37 04:47, 21 December 2012 (UTC)[reply]

Moderator user-rights group

Moderator as a name

Part of the problem with picking a name for this is that for others' purposes elsewhere (bureaucracies/websites/governments/etc.), content and behaviour is usually lumped together. So most terms are going to have been used for both at some place or other.

So, after a lot of thinking and researching names/titles, I'm calling the recipient of this user-right package a moderator.

(The technical name of this user-right package (user group) as listed in Special:ListGroupRights would be moderator-admin.)

Moderator has a couple things going for it:

It's a universally known term online as someone who deals with discussions/text/"substance".
It's fairly neutral term
It's easily abbreviated to "mod" (compare to administrator/admin)
AFAIK it should translate fairly easily

If anyone has a better name, I'm all ears. But for now, that name seems to be understandable for the primary intent of this group: Someone who can respond to and implement editorial requests concerning content, and who assesses consensus in content-related discussions and has the ability to subsequently implement that consensus.

(I did not call it "closer" because many non-admins close discussions, including clerks, CUs, and so on.)

Interdependency

The tools in this package were specifically selected due to their interdependency in application and usage.

Per Special:ListGroupRights, there are currently 52 (plus two more to add and remove certain user-rights) in the administrator user group.

Besides the deletion tools, there are only 5 tools in this package which aren't already given to autoconfirmed, and we shouldn't give those to someone who couldn't view deleted material.

I reduced 54 user-rights to 16 and added editprotected (which isn't in the administrator user group due to admin having protect).

And note: to not have the ability to delete and to see deleted, would leave the editor with this user-right package without the ability to perform the majority of the tasks noted at the top: XfD, RM, CSD, editprotected, etc. You can't close an XfD without the deletion tools to implement. That's been the standard for a long time. Someone may need to edit protected pages in order to adjust hatnotes and links to a now moved or deleted page, or they may need to adjust a categorisation due to a renamed or a merged category, and so on.

The goal here is to not add to admin's work, but to give the moderator that ability to assess consensus, to handle content-related issues, without needing to run to an admin, because the moderator, in these situations, will be as trusted as an admin to perform them. Why? Because the mod (as a former admin) went through the same trust-assessing process that current admins did.

What I didn't add were (of course) block and protect, but there's a lot more in the admin package than that. +sysop (which is what the admin package actually is) is pretty much a dumping ground for most new tools made. And what's left (mostly) deal with the ability of an individual to edit, and assessing an individual's edits, rather than handling content. Besides what I've already noted, I left out editing the mediawiki namespace (which is broader than just content), and user-rights dealing with offsite things like importing. (I only added the user-right dealing with commons to grant the ability to implement that type of close at FFD, and other image/file-related things.)

So with all that in mind, this is designed to be a rather clear definition of what types of work the moderator will do. One thing we don't want is a confusion about what a mod is able to do now (or in the future).

So this is about as "condensed" a package as we should do. The idea was to make the tools as useful as possible with as small a package as possible.

List of user-rights included in the user group

Edit protected pages

autoconfirmed – Edit semi-protected pages
editprotected – Edit protected pages (without cascading protection).

Handle deletion

delete – Delete pages
undelete – Undelete a page

deleterevision – Delete and undelete specific revisions of pages

deletedhistory – View deleted history entries, without their associated text
deletedtext – View deleted text and changes between deleted revisions
browsearchive – Search deleted pages

Handle moves

move – Move pages
movefile – Move files
movestable – Move pages under pending changes
move-subpages – Move pages with their subpages
move-rootuserpages – Move root user pages
suppressredirect – Not create redirects from source pages when moving pages

Handle files

upload – Upload files
reupload – Overwrite existing files
reupload-shared – Override files on the shared media repository locally