User:Jc37/Proposals/Moderator

See the poll and ongoing discussion of this proposal. Before commenting, please read the proposal below thoroughly. Also note the Wikimedia Foundation's statement.

Note: Ok, this is likely to be lengthy (though I'll try to be as brief as possible).

However, due to what is being proposed, the commenters really should clearly understand the proposal. I believe it would be reckless to merely tl;dr this.

== RfC ==

• A Request for Comment on a proposal to create a new user group with an abbreviated set of administrator user-rights, granted through the standard RfX process. Please read the full proposal thoroughly before commenting. I welcome everyone's thoughts on this. - jc37 22:07, 24 June 2012 (UTC)

Proposal

Proposal: A new user-right package (aka user group) designed primarily to help with content-related admin tasks for which there is often a backlog. - 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.

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 granting an editor the tools to implement the close of such discussions.

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.

Though note, if the editor with this user-right package closes a non-content-related discussion (such as an RFC/U), then that closure would be treated as a non-admin close.

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: block or protect. Semi-related to this, no tools which grant user-rights to editors. I also did not include a couple rarely used deletion tools simply because it's probably best to just go find an admin for those situations.

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.

The only user group that should be considered subsumed by this proposal is file mover. (Which should be deprecated.) In researching user-rights and their de facto uses, I believe that a file mover should be able to see deleted contributions and edit protected pages. While it may not be true in every case, it looks like there are cases where a non-admin with file mover moves a file, then an admin needs to come in and resolve the rest. Since moving the file is basically only one extra button, it's probably better if the one wanting the file moved went to an admin in the first place. Or in other words, allowing for being proactive about problems/issues before they become problems/issues.

I also should note for those of you who have wanted editprotected unbundled into a separate user-right: From all that I have learned so far, the ability to edit protected pages is another user-right which really seems to be interdependent on other user-rights in practice. And also it apparently has a larger possibility for disruption than I had previously understood (Sorry: WP:BEANS.) So it is definitely not a user-right that should be given out in the way rollbacker or the other admin-granted user-rights are.

RfX process

I've been in discussions regarding these types of proposals related to user-rights and adminship and RfA for many years now. And usually, trying to discuss the process for granting the user-right group while simultaneously discussing whether the user-right group should be created, typically sinks the proposal due to train-wreck-style confusion.

However, in this case, due to the inclusion of user-rights which have great potential for disruption (and because viewing deleted history can have copy-vio and/or privacy issues), it's important to clarify how this user-right group would be granted (and removed).

Just so it's understood, IANAL, and my comments in regards to this are merely based upon my understanding of others in past discussions and what I have read and, of course, my own experience.

This user-right group would be granted through the same process as adminship (RfA) and bureaucratship (RfB). A community-wide discussion, closed by a bureaucrat, who, if determining the request successful (that there is community consensus), "pushes the button" as it were.

Before you scream about how "RfA is broken", consider this:

The current administrator tool group includes a LOT of tools. While this package does not include block or protect.

From a social perspective, block is often seen as the most concerning to individual editors. (Though from a content contributor's perspective, delete is often seen that way.) (And I personally think that the ability to discern consensus is at least of equal importance to either of those.)

So in this case, the RfA discussion can stay focused on the editor's understanding of how to determine consensus in discussions, various content-related policies and guidelines, and also on the trust requisite with only the particular tools they would be receiving.

However, the ability to view deleted information likely being of the greatest concern for the project as a whole (and from what I understand, also a concern of the WMF). The rest, while having the normal potential for great disruption that adminship tools do, are no where near this. To be clear, the current standard for adminship: community trust, as expressed through an RfX discussion; would be equally as required for this user-rights package (user group) as it is for adminship in regards to the tools and responsibilities granted.

So to be clear, though this user-right group would not grant the editor all of the tools in the administrator user-rights package, the editor still would fall under all the adminship-related Wikipedia policies and guidelines.

So in other words, the editor would be subject to all the rules and restrictions of adminship, without the title or all the tools.

So why would anyone want to request this?

If they can get all the adminship tools by going through an RfA, why would anyone want to request this?

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

Variations of: admin-lite; a two-tier adminship; split adminship; probationary adminship; non-blocking adminship; "someone to help with the backlogs"; and so on. (Note: I've come to understand that due to various reasons it would be best if the administrator user-right group is not "split", but rather that we merely unbundle some tools and create a new additional user-right group.)

This proposal is long enough, so I'll spare everyone explanations of the various past proposals listed above. Just search through the archives at WT:RFA and the various village pumps for such discussions (and links to discussions).

So why would anyone want to request this?

Several reasons.

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.

Imagine it's like forcing a conscientious objector or a pacifist to carry a gun. They don't want it, they don't want it, they don't want it. They have little problem with the requirement to go through the full process to get the other tools that may be necessary for them to help out, but please don't ask them to carry a gun. "But you don't have to ever take it out of your holster"', some might say. It doesn't matter. They just don't want to carry it 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.

And arbitrarily keeping trusted individuals from certain other tools because they refuse to accept "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.

It also provides an opportunity for those who wish to receive adminship in a two-step process. They may start out by requesting this smaller group of content-related tools and responsibilities to learn, and then may request the "rest of the tools" later, if they wish.

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

This is merely an extension of that tradition.

Removal

In addition, this user-right package (user group) may be removed by consensus of the community. (Through a consensual process similar to how the community decides whether to ban an editor, though in this case, to be closed by a bureaucrat.)

Unlike adminship, removal of which is in practice rare and difficult, it would likely be much easier for the community to determine whether it should be removed due to ongoing issues and concerns, as this user-group has fewer (and particularly more focused) tools and responsibilities. And also, there would presumably be less of a "retribution factor", as this editor does not directly assess others' behaviour as a part of their responsibilities or tools related to this user-right package.

Note: just like adminship, anyone with this user-right package may request their removal. And if removal was not "under a cloud", may request their immediate return by any bureaucrat per the normal rules.

Also, any admin may request that a bureaucrat remove their adminship and immediately "replace" them with this user-right group instead, though again, the "under a cloud" rules apply here as well.

And if someone does 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 by Arbcomm, etc. (In other words, switching to this package should in no way be considered a way to avoid or bypass anything.)

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.

In closing

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

And in response to one suggestion there, I do not oppose the suggested one year trial period.

And in case you might be interested, here's a link to my opinion concerning the current state of RfA.

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 16:51, 23 June 2012 (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 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 admininstrator 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 (if that's what we call this user group) 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 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

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

Statement from the Wikimedia Foundation

Hi everyone. Today, Maggie and I spoke with Kelly Kay, the Deputy General Counsel (whom Geoff tasked with making this decision, since he's out of the office and didn't want to make you wait for his return). We laid out the considerations and the statement originally made by Mike and confirmed by Geoff. As we see it, the primary concern that led to Mike's position was that access to admin rights and permissions, including that those who had access to deleted article-related permissions needed to be administrators, because administrators go through a rigorous community selection process.

In this case, as it has been proposed to us, the process for becoming a "moderator" is exactly the same as that for becoming an administrator. As a result, Kelly is able to approve this plan on the condition that the selection processes for moderators remain exactly the same as that for administrators- using the same criteria, operating on the same page. If the selection criteria or processes should drift from that used for the selection of administrators, we would need to reconsider the position. All of this, of course, is provisional upon the plan reaching consensus here in the typical fashion. This will not be imposed by the Foundation - we're simply saying that we will not block it, should it get to that point. Sincerely, Philippe Beaudette, Wikimedia Foundation (talk) 23:41, 26 June 2012 (UTC)