User:Tóraí/Moderators

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.

This page in a nutshell: A 12-month trial of a new Moderator user group is proposed. Moderators would be co-equals to Administrator but with a toolset focused on content-related tasks. The suggested benefit is that the Moderator user group may be more inviting for some users to join than the current Administrator user group. The proposal does not relate to reform of RfA and Moderators would still need to go through RfA. Because they would have already met the requirements of RfA, Moderators would be free to swap to the Administrator user group at any time.

The Moderator user group is a proposed user group with access to a sub-set of Administrator tools focused on content development. It is proposed that Moderators would be coequals to Administrators, capable of performing Administrator-related functions (e.g. closing XfDs). Administrator tools that relate to user and/or site management would not included as part of the Moderator tool set.

It is envisioned that Moderators would assist in addressing the administrative backlog, XfDs, etc. as well as the general backlog. Moderators could also complete ad hoc tasks for which trusted editors currently rely on administrators to conduct on their behalf (e.g. deleting files in copyright violation, making changes to protected templates, etc.).

Whilst Moderators would need to go through the same selection process as Administrators (mainly because of access to the 'delete' tool), the Moderator user group may be a more inviting for some editors to join compared to the current Administrator user group. This may in turn broaden the number of users with access to the core administrator tools and so assist in addressing the most significant backlogs.

Because the same process and standard would be used to select members for both groups (Administrators and Moderators), a user in either group would be able to self-nominate to switch between either at any time.

This proposal is to create the Moderator user group for a trial period of 12 months.

Rationale[edit]

The purpose of proposing this user group is to increase the number of users with access to a core Administrator toolset. One commonly called-for approach to do that is to reform RfA so as to make the process and criteria for becoming an Administrator easier or less daunting. This proposal approaches the question from the other side and takes the approach of increasing the number of applicants for RfA who already meet the current criteria (while not standing in the way of other other proposals to reform RfA).

The Moderator user group is proposed specifically as a way to increase access to the core administrative tools amongst editors who already meet the criteria for RfA but who are not attracted to the role of Administrator. Even if this results in just 1 in 10 extra applicants for adminship, that would translate to a 10% increase in the number of users with access to administrator tools.

Because they would have already passed RfA, a Moderator would be entitled to opt to 'activiate' the full admin toolset at any time without going through RfA again.

Selection and criteria[edit]

Requests to join the Moderators user group would be through a standard RfA, using the same process and under the same criteria as requests for adminship. Largely, this is because the Wikimedia Foundation will not allow a user group access to the 'delete' and 'undelete' tools under reduced criteria.^{[Note 1]}

Since a member of the Moderator user group would already have met the criteria to become be an Administrator, a Moderator may join the Administrator user group by asking a Bureaucrat to move them into that user group. Likewise, an Administrator may ask a Bureaucrat to move them into the Moderator user group. The decision to move a Moderator into the Administrator user group, or vice versa, would be at the discretion of each Bureaucrat.

Rights[edit]

The Moderator user-group would include all of the rights of autoconfirmed users, rollbackers, auto patrolled users, and reviewers, plus a subset of rights from Wikipedia:Administrators:^{[Note 2]}

Right	Administrators	Moderators
Alter visibility on the feedback dashboard (`moodbar-admin`)	Y	N
Block a user from sending e-mail (`blockemail`)	Y	N
Block other users from editing (`block`)	Y	N
Bypass IP blocks, auto-blocks and range blocks (`ipblock-exempt`)	Y	N
Bypass automatic blocks of proxies (`proxyunbannable`)	Y	N
Change protection levels and edit protected pages (`protect`)	Y	Y
Configure how the latest accepted revision is selected and displayed (`stablesettings`)	Y	N
Delete and undelete specific revisions of pages (`deleterevision`)	Y	?
Delete pages (`delete`)	Y	Y
Disable global blocks locally (`globalblock-whitelist`)	Y	N
Edit other users' CSS files (`editusercss`)	Y	N
Edit other users' JavaScript files (`edituserjs`)	Y	N
Edit the user interface (`editinterface`)	Y	N
Import pages from other wikis (`import`)	Y	N
Manage central notices (`centralnotice-admin`)	Y	N
Mark rolled-back edits as bot edits (`markbotedits`)	Y	N
Mass delete pages (`nuke`)	Y	N
Move files (`movefile`)	Y	Y
Move pages with their subpages (`move-subpages`)	Y	Y
Not be affected by rate limits (`noratelimit`)	Y	N
Not create redirects from source pages when moving pages (`suppressredirect`)	Y	Y
Override files on the shared media repository locally (`reupload-shared`)	Y	N
Override the spoofing checks (`override-antispoof`)	Y	N
Override the title blacklist (`tboverride`)	Y	N
Revert all changes by a given abuse filter (`abusefilter-revert`)	Y	N
Search deleted pages (`browsearchive`)	Y	?
Unblock themselves (`unblockself`)	Y	N
Undelete a page (`undelete`)	Y	Y
Upload files from a URL (`upload_by_url`)	Y	N
Use higher limits in API queries (`apihighlimits`)	Y	N
View a list of unwatched pages (`unwatchedpages`)	Y	Y
View abuse filters marked as private (`abusefilter-view-private`)	Y	N
View deleted history entries, without their associated text (`deletedhistory`)	Y	?
View deleted text and changes between deleted revisions (`deletedtext`)	Y	?
markashelpful-admin (`markashelpful-admin`)	Y	N

User group management[edit]

As trusted users (and in order to widen access to these content-related tools), a moderators would also be able to add and remove users from the following user groups (which is a sub-set of the groups Administrators can manage):

Add groups: Autopatrolled, File movers, Reviewers, Rollbackers
Remove groups: Autopatrolled, File movers, Reviewers, Rollbackers

Dangers and benefits[edit]

The risks associated with the creation of this user group for a 12-month trial period are very small. Since access to the user group would be granted through the same process and criteria as Administrators, no user would be granted access to these tools that would not meet the process and criteria already set. One possible danger is that the Moderator user group could canabalise the Administrator user group. However, this is not anticipated and, even if it did occur, the risk associated with it would be small since "defecting" Administrators would still have access to core administrative tools.

The major proposed benefit is that the Moderator user group would be more inviting to some users than the current Administrator user group (for reasons of perception, interest, or other subjective reasons). This may lead to an increased number of trusted users with access to the core Administrator tool set and thus benefit the project. The 12-month trial period is proposed to test this hypothesis. A less measurable hypothesis is that the creation of a Moderator user group like this would go some way to make adminship less of "big deal" by creating a user group that are coequals of Administrators but who choose to remain focused on content development (i.e. are more "editor-like" in focus, tasks and powers).

If, after one year, or during the course of the trial, the community decided not to continue with the Moderator user group, Moderators could simply be given the option to join the Administrator user group or relinquish their rights.

What this proposal is not[edit]

This proposal does not offer a "fix" for RfA. However, neither would the proposal stand in the way of reform of RfA. Whether RfA were reformed or not, Moderators would go through the same selection process and meet the same criteria as Administrators. For this reason, the proposed Moderator group should not be considered an "admin-lite" user group or an admin training ground. Moderators and Administrators would be coequals, with Moderators simply choosing to focus on content-related tasks.

This proposal is not a silver bullet. In fact, it doesn't purport to make any big changes or reforms. The creation of a Moderator user group like this may only make a small difference to day-to-day operations, or even none at all, but — possibly — the difference it will make will be meaningful.

Notes[edit]

^ The following statement is from Philippe of 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)
^ I'm not sure whether to include rights to do with deletion/undeletion/etc. of specific revisions since these may relate closely to user/site management. Please comment on this question.

[1] The following statement is from Philippe of 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)

[2] I'm not sure whether to include rights to do with deletion/undeletion/etc. of specific revisions since these may relate closely to user/site management. Please comment on this question.

[Note 1]

[Note 2]