Wikipedia:Moderators/Proposal

This page is about the 2016 proposal. For the 2013 proposal, see Wikipedia:Moderators/Proposal/2013.

See also the straw poll and ongoing discussion of this proposal.

Proposal

Proposal: A new user-right package (aka user group) designed primarily to allow editors the option to help with content-related admin tasks (for which there is often a backlog), if they wish to not have the rest of the sysop package of user-rights. – For example, to allow for implementing the close of certain 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, as far as I know, it has been repeatedly upheld in community 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, without requiring them to carry all 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 "mass-action" tools (mass message / mass delete etc.)

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 also be subject to all the rules and restrictions which are also expected of adminship.

Granting and removal

See also: Wikipedia:Administrator § Review and removal of adminship

Granting of moderator is done by Bureaucrats as a result of a successful request for the tools (RfM), similar to how adminship is requested there. (Note: Per past requests, this has been said to be a requirement by the WMF - that the granting be similar to how adminship tools are granted.)

The editor may also request one or more admin-granted tools (such as rollback) as part of their RfM.

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.

Though of course, anyone doing this while under a cloud may still have this package removed, just as adminship can be removed, though restoration would likely require a community request. (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 editor 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.

Even though we may think they can be trusted with all of them, we shouldn't be "forcing" people to accept certain tools which they feel uncomfortable with, and/or clearly do not want, in order to receive tools with which they could clearly help with the encyclopedia project.

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 20:31, 8 July 2016 (UTC)

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 a fairly neutral term
• It's easily abbreviated to "mod" (compare to administrator/admin)
• As far as I know 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, by my count, there are currently 81 (plus two more to add and remove certain user-rights) in the administrator user group.

Besides the deletion tools, there are only a few 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.

So out of 81 user-rights listed for administrator, the 22 user-rights below appear to meet the criteria established above.

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 went through the same trust-assessing process that current admins do.

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

Editing protected pages

• editsemiprotected - Edit pages protected as "Require autoconfirmed or confirmed access"
• extendedconfirmed - Edit pages protected as "Require extended confirmed access"

• editprotected - Edit pages protected as "Require administrator access"
• templateeditor - Edit protected templates

Handle deletions

• 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
• movestable – Move pages under pending changes
• move-rootuserpages – Move root user pages

• movefile – Move files
• move-subpages – Move pages with their subpages
• suppressredirect – Not create redirects from source pages when moving pages
• mergehistory - Merge the history of pages
• tboverride - Override the title or username blacklist
• titleblacklistlog - View title blacklist log

Handle files

• upload – Upload files
• reupload – Overwrite existing files

• reupload-shared – Override files on the shared media repository locally

Note: Indented items are currently available to most users, but may be needed for technical reasons