![]() | This page in a nutshell: A new Moderator user group is proposed that would be co-equals to the current Administrator user group but with a focus on content-related tasks. The proposal is that the Moderator group would be trialled for 12 months. The greatest suggested benefit is that the Moderator user group would be more inviting to some users to join than the current Administrator user group. The dangers of such a trial are suggested to be negligible. The proposal does not relate to any other reform of AfD. |
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 for which they have access to the necessary tools (e.g. closing XfDs). Administrator tools that relate to user and/or site management are not included as part of the Moderator tool set.
It is envisioned that Moderators would assist in addressing the administrative backlog, XfDs and the backlog generally. Moderators could also perform ad hoc work for which trusted non-admins currently rely on administrators to perform functions 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 increase the number of users with access to the administrative tools required to work on 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 stage.
This proposal is to create the Moderator user group for a trial period of 12 months.
Selection and criteria
editRequests to join the Moderators user group will be through 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 will 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, will be at the discretion of each Bureaucrat.
Rights
editThe Moderator user-group will 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 ) |
||
Block a user from sending e-mail (blockemail ) |
||
Block other users from editing (block ) |
||
Bypass IP blocks, auto-blocks and range blocks (ipblock-exempt ) |
||
Bypass automatic blocks of proxies (proxyunbannable ) |
||
Change protection levels and edit protected pages (protect ) |
||
Configure how the latest accepted revision is selected and displayed (stablesettings ) |
||
Delete and undelete specific revisions of pages (deleterevision ) |
||
Delete pages (delete ) |
||
Disable global blocks locally (globalblock-whitelist ) |
||
Edit other users' CSS files (editusercss ) |
||
Edit other users' JavaScript files (edituserjs ) |
||
Edit the user interface (editinterface ) |
||
Import pages from other wikis (import ) |
||
Manage central notices (centralnotice-admin ) |
||
Mark rolled-back edits as bot edits (markbotedits ) |
||
Mass delete pages (nuke ) |
||
Move files (movefile ) |
||
Move pages with their subpages (move-subpages ) |
||
Not be affected by rate limits (noratelimit ) |
||
Not create redirects from source pages when moving pages (suppressredirect ) |
||
Override files on the shared media repository locally (reupload-shared ) |
||
Override the spoofing checks (override-antispoof ) |
||
Override the title blacklist (tboverride ) |
||
Revert all changes by a given abuse filter (abusefilter-revert ) |
||
Search deleted pages (browsearchive ) |
||
Unblock themselves (unblockself ) |
||
Undelete a page (undelete ) |
||
Upload files from a URL (upload_by_url ) |
||
Use higher limits in API queries (apihighlimits ) |
||
View a list of unwatched pages (unwatchedpages ) |
||
View abuse filters marked as private (abusefilter-view-private ) |
||
View deleted history entries, without their associated text (deletedhistory ) |
||
View deleted text and changes between deleted revisions (deletedtext ) |
||
markashelpful-admin (markashelpful-admin ) |
User group management
editAs a trusted users (and in order to widen access to these content-related tools), a moderators will also be able to add and remove users from the following 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
editThe risks associated with the creation of this user group for a 12 month trial period is 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. The risk associated with this is still small however, since the most important tools for the project would still be in the possession of former (or would-be) Administrators "defecting" to become Moderators.
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 users with access to the core Administrator tool set and thus benefit the project. A 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, 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
editThis proposal does not offer a "fix" for AfD. However, neither would the proposal stand in the way of reform of AfD. Whether AfD were reformed or not, Moderators would go through the same selection process and meet the same criteria as Administrators. For this reasons, 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 not 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 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.