Wikipedia:Non-administrator Arbitrators RfC

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

This request for comment has been open for more than a week, it has received widespread participation, and the voting phase for 2015 Arbitration Committee Elections has begun. As a result, it has been requested that this discussion be closed as soon as possible to clarify to the community what rights and privileges will be granted to arbitrator-elects, so that they are able to make an informed decision in the election.

The community has formed consensuses on the following issues that I will now summarize:

  • There is a strong consensus against granting the administrator right automatically to non-administrators upon appointment to the Arbitration Committee, on the basis that the roles of administrator and arbitrator are fundamentally different, and that being an arbitrator does not necessarily require administrator access. Additionally, nothing in current policy precludes a non-administrator arbitrator from applying for adminship at WP:RFA at any time. Dissenting opinions include that adminship should be “no big deal” and that if a user can be trusted to be an arbitrator, they should also be trusted to be an administrator. There was also some conditional support for allowing admin access exclusively for ArbCom-related business.
  • As a result of the foregoing consensus, questions over whether originally non-admin arbitrators should retain administrator access after ending their term and whether use of the admin toolset should remain exclusive to ArbCom business become moot. Supporters for retaining admin access argued that the level of the trust is approximately the same, while opponents contended that all administrators must pass an RFA. Additionally, there was a notable concern that restricting use of the admin toolset to ArbCom business only would be difficult to enforce. An overwhelming majority of editors opposed retaining adminship after ArbCom, while a closer majority of editors supported restricting the use of admin tools to ArbCom business only.
  • There is a consensus against granting edit filter manager rights automatically to non-administrators upon appointment to the Arbitration Committee, on the basis that automatic assignment is not necessary, and that if the rights become necessary, they can be requested.
  • There is a rough consensus supporting the idea for a new "arbitrator" user right group on the basis that it would simplify the process of assigning the necessary user rights. However, additional discussion is needed to determine what rights exactly should be included in a new "arbitrator" access level. At the moment, this is not clear. There is also a significant minority opinion that no additional rights are needed beyond what we already have available to arbitrators.
  • There is a consensus to grant CheckUsers and oversighters the ability to view-only private abuse filters, on the basis that it would be useful to both groups. However, dissenting editors opine that this isn’t necessary because administrators already have this right, and the chance that a non-administrator would genuinely need this right included is small. Additionally, there was some conditional support to grant the right only to oversighters, not CheckUsers.

The two passing proposals regarding user rights require intervention from the Wikimedia Foundation. The proposal for a new arbitrator right requires additional discussion to determine what rights specifically to include in the new group. I recommend starting a new RfC in the near future to determine this.

Respectfully submitted, Mz7 (talk) 20:52, 23 November 2015 (UTC)[reply]


A handful of editors have raised the question as to whether non-administrators who are elected to the arbitration committee should be granted the administrator right. (1, 2) Successful candidates are granted the checkuser and oversight permissions in order to assist with their duties as an arbitrator. It is outside the scope of the arbitration election commission role to decide if a non-administrator appointed to the arbitration committee should be granted the administrator right and the community does not have an established policy. Given the significant number of non-administrator candidates this year, the community should discuss if non-administrators should or should not be granted administrative rights if appointed. Also, if granted the administrator right, whether or not they may retain it after leaving the arbitration committee.

For ease of reference, the permissions of the administrator, checkuser, and oversight groups are included below:

The administrator group provides the following permissions:
  • Add and remove arbitrary tags on individual revisions and log entries (changetags)
  • Add or remove campus volunteers to courses (ep-campus)
  • Add or remove instructors to courses (ep-instructor)
  • Add or remove online volunteers to courses (ep-online)
  • Add or remove yourself as campus volunteer from terms (ep-becampus)
  • Add or remove yourself as instructor from courses (ep-beinstructor)
  • Add or remove yourself as online volunteer from terms (ep-beonline)
  • Add or remove yourself as reviewer from articles (ep-bereviewer)
  • Block a user from sending email (blockemail)
  • Block other users from editing (block)
  • Bulk delete courses (ep-bulkdelcourses)
  • Bulk delete institutions (ep-bulkdelorgs)
  • Bypass IP blocks, auto-blocks and range blocks (ipblock-exempt)
  • Change protection levels and edit cascade-protected pages (protect)
  • Configure how the latest accepted revision is selected and displayed (stablesettings)
  • Create accounts with names similar to existing usernames (override-antispoof)
  • Create and delete tags from the database (managechangetags)
  • Create new user accounts (createaccount)
  • Delete Flow topics and posts (flow-delete)
  • Delete and undelete specific log entries (shared by administrator, oversight) (deletelogentry)
  • Delete and undelete specific revisions of pages (shared by administrator, oversight) (deleterevision)
  • Delete pages (delete)
  • Disable global blocks locally (globalblock-whitelist)
  • Disassociate articles from students (ep-remarticle)
  • Edit Flow posts by other users (flow-edit-post)
  • Edit other users' CSS files (editusercss)
  • Edit other users' JavaScript files (edituserjs)
  • Edit pages protected as "Allow only administrators" (editprotected)
  • Edit pages protected as "Allow only autoconfirmed users" (editsemiprotected)
  • Edit protected templates (templateeditor)
  • Edit the user interface (editinterface)
  • Enroll in Education Program courses (ep-enroll)
  • Enroll users as student (ep-addstudent)
  • Force a public user list to become hidden (gather-hidelist)
  • Have one's own edits automatically marked as patrolled (autopatrol)
  • Have one's own revisions automatically marked as "accepted" (autoreview)
  • Import pages from other wikis (import)
  • Manage Education Program courses (ep-course)
  • Manage Education Program institutions (ep-org)
  • Manipulate JsonConfig via API (jsonconfig-flush)
  • Mark Flow topics as resolved (flow-lock)
  • Mark others' edits as patrolled (patrol)
  • Mark revisions as being "accepted" (review)
  • Mark rolled-back edits as bot edits (markbotedits)
  • Mass delete pages (nuke)
  • Merge the history of pages (mergehistory)
  • Move category pages (move-categorypages)
  • Move files (movefile)
  • Move pages (move)
  • Move pages under pending changes (movestable)
  • Move pages with their subpages (move-subpages)
  • Move root user pages (move-rootuserpages)
  • Not be affected by IP-based rate limits (autoconfirmed)
  • 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 title or username blacklist (tboverride)
  • Overwrite existing files (reupload)
  • Perform CAPTCHA-triggering actions without having to go through the CAPTCHA (skipcaptcha)
  • Quickly rollback the edits of the last user who edited a particular page (rollback)
  • Remove reviewers from articles (ep-remreviewer)
  • Remove students from courses (ep-remstudent)
  • Reset failed or transcoded videos so they are inserted into the job queue again (transcode-reset)
  • Revert all changes by a given abuse filter (abusefilter-revert)
  • Search deleted pages (shared by administrator, checkuser, oversight) (browsearchive)
  • See Education Program enrollment tokens (ep-token)
  • Send a message to multiple users at once (massmessage)
  • Unblock oneself (unblockself)
  • Undelete a page (undelete)
  • Upload files (upload)
  • Use higher limits in API queries (apihighlimits)
  • View information about the current transcode activity (transcode-status)
  • View a list of unwatched pages (unwatchedpages)
  • View abuse filters marked as private (abusefilter-view-private)
  • View deleted history entries, without their associated text (shared by administrator, checkuser, oversight) (deletedhistory)
  • View deleted text and changes between deleted revisions (shared by administrator, checkuser, oversight) (deletedtext)
  • View detailed abuse log entries (abusefilter-log-detail)
  • View the spam blacklist log (spamblacklistlog)
  • View title blacklist log (titleblacklistlog)
  • unused permission (proxyunbannable)
  • Add groups: Edit filter managers, Account creators, Autopatrolled, Confirmed users, File movers, Pending changes reviewers, Rollbackers, Template editors, Mass message senders, IP block exemptions, Course online volunteers, Course campus volunteers, Course instructors and Course coordinators
  • Remove groups: Rollbackers, Account creators, Edit filter managers, Autopatrolled, Confirmed users, Pending changes reviewers, File movers, Template editors, Mass message senders, IP block exemptions, Course online volunteers, Course campus volunteers, Course instructors and Course coordinators
The checkuser group provides the following permissions:
  • Check the IP addresses and other information of user accounts; see Wikipedia:CheckUser. (checkuser)
  • Search deleted pages (shared by administrator, checkuser, oversight) (browsearchive)
  • View deleted history entries, without their associated text (shared by administrator, checkuser, oversight) (deletedhistory)
  • View deleted text and changes between deleted revisions (shared by administrator, checkuser, oversight) (deletedtext)
  • View the checkuser log (checkuser-log)
The oversight group provides the following permissions:
  • Block a username, hiding it from the public (hideuser)
  • Delete and undelete specific log entries (shared by administrator, oversight) (deletelogentry)
  • Delete and undelete specific revisions of pages (shared by administrator, oversight) (deleterevision)
  • Hide entries in the abuse log (abusefilter-hide-log)
  • Hide from administrators and restore elements of individual page revisions (suppressrevision)
  • Search deleted pages (shared by administrator, checkuser, oversight) (browsearchive)
  • Suppress Flow revisions (flow-suppress)
  • View deleted history entries, without their associated text (shared by administrator, checkuser, oversight)(deletedhistory)
  • View deleted text and changes between deleted revisions (shared by administrator, checkuser, oversight) (deletedtext)
  • View hidden abuse log entries (abusefilter-hidden-log)
  • View private logs (suppressionlog)