User groups/en-gb

From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page User groups and the translation is 7% complete.
This page is about user groups and rights on MediaWiki, for the simple and flexible affiliation structure please see Wikimedia User Groups

The following is a list of user groups in Wikimedia Foundation projects. It is arranged in approximate descending order of permissions. Note that the order does not directly correlate with power in the proper sense of the word, but rather refers to technical access in the MediaWiki software. Please note that while the technical capabilities are the same on all Foundation projects, the definitions and roles of certain groups differ from wiki to wiki.

Local groups

Here's a list of user groups, from the highest access level to the lowest.

Global user groups

Global bot

Global bots have bot access on all wikis where global bots are enabled (see the list of wikis). Global bots are subject to the standard bot policy, which limits these bots to specific tasks.

Global rollback

Users with global rollback can revert a series of edits by one user with one click on any wiki, primarily intended for vandalism and nonsense. Users must be demonstrably active in crosswiki counter-vandalism for access.

See:

Global sysop

Global sysops are users with sysop access on multiple small wikis, mainly for the purpose of fighting vandalism in the absence of local administrators. They are appointed after a lengthy discussion on Steward requests/Global permissions.

See:

VRT permissions agents

VRT permissions agents are users who have access to the permissions queues of the Wikimedia VRTS. The global group is used primarily for identification purposes, and the only user right it contains is the ability to activate two factor authentication.

Staff

The Staff group is assigned to some paid employees of the Wikimedia Foundation. This group has special access primarily for technical or legal purposes.

Background

The Wikimedia Foundation continuously evaluates who is a member of the staff user group to minimise the proliferation of this highly specialised tool. Staff group membership is constantly re-evaluated, especially if a more limited tool is available that suits a staff member’s needs, if it is expected that someone will not need staff privileges for a certain period of time, or if something untoward emerges during a risk assessment. These re-evaluations are part of good security practices.

Previously, it was relatively arbitrary who did and did not have staff rights, based on asking the staff member responsible for those rights. The process was subsequently formalised to prevent abuse or improper use of staff rights. Obtaining staff rights requires a second-level approval (meaning that a new employee in a department requires a director-level approval and a new manager requires a C-level approval), a formal written use case kept on file and reviewed regularly to determine whether the use case is still met by granting staff rights, a short training session explaining what is appropriate and inappropriate use, and a (written) acknowledgement of the rights and responsibilities associated with staff rights.

There used to be little protection against abuse. Nowadays, there are a number of controls built into the system. On the English-language Wikipedia, for instance, the Arbitration Committee reviews all logged actions and discusses questionable actions with Jan (as the WMF employee responsible for approving rights allocations) to ensure they are within policy. On other wikis where there is no similar subcommittee, the Trust and Safety (T&S) team audits and reviews employee actions. In some cases, this has led to disciplinary action against employees. These are not toothless protections.

Assignment

Staff rights are managed by the Global Head of Trust and Safety and the second-level Wikimedia Foundation manager of the person requesting staff rights.

Wikimedia stewards and staff will add or remove permissions (former link) from the staff global user group and they also add or remove user accounts from the staff global user group based on the requests of the Global Head of Trust and Safety or their designee. There is no requirement that community consensus be demonstrated or that the above requirements (including sign-offs) are proved.

Rationale and responsibility of advanced permissions assignment for Wikimedia Foundation staff are currently recorded in a locked Google spreadsheet. A mirror of that page can be found at WMF Advanced Permissions.

Permissions

The following chart lists the user rights available in the staff user group and an explanation of why these rights are necessary for staff to have.

User right Purpose
autoconfirmed ...
autopatrol ...
bigdelete At times, the T&S or technical team need the ability to delete pages with a high number of revisions for technical reasons, or for legal compliance reasons.
browsearchive ...
centralauth-merge ...
centralauth-unmerge ...
centralnotice-admin ...
checkuser The T&S team uses this right for legal compliance (subpoena, etc.) and safety reasons (investigations of threats)
checkuser-log The T&S team uses this right for legal compliance (subpoena, etc.) and safety reasons (investigations of threats)
delete The T&S team uses this right for legal compliance and copyright purposes.
deletedhistory The T&S team uses this right for legal compliance and copyright purposes.
deletedtext The T&S team uses this right for legal compliance and copyright purposes.
deletelogentry The T&S team uses this right for legal compliance purposes.
deleterevision The T&S team uses this right for legal compliance and copyright purposes.
edit ...
editinterface The T&S team uses this right for legal compliance and copyright purposes (i.e., to change the copyright notices, etc.). Other staff members use it to support the development of other projects and technical initiatives.
editusercss This was done for a couple of reasons.

First, we have had times when we saw a user insert some code in their own user.js and user.css files that really shouldn't be there, and then propagate that code out to the wikis by adding a transclusion from their own user files to, for instance, Mediawiki:Common.js of a smaller wiki, and thereby add google tracking code, for instance. This allows staff to easily (and in a logged fashion) remove such code.

Second, in order to include a script for those users who hold staff rights which colors red the interface buttons for things that they really shouldn't touch without a REALLY good reason (i.e., the execute checkuser button). You can see that script in my own user.js file. This is a reminder for new staff who didn't come from the community that these are specialized rights, and not everyone has access to them, and serves as a mental "speedbump" against using them.

editusercssjs
edituserjs
globalblock ...
globalblock-exempt ...
globalblock-whitelist ...
globalunblock ...
hiderevision ...
hideuser ...
import ...
importupload ...
ipblock-exempt ...
moodbar-admin ...
move ...
move-rootuserpages ...
move-subpages ...
movefile ...
noratelimit ...
nuke ...
override-antispoof ...
oversight ...
prefstats ...
protect ...
purge ...
reupload ...
reupload-shared ...
superprotect ...
suppressionlog ...
suppressredirect ...
suppressrevision ...
tboverride ...
tboverride-account ...
transcode-reset ...
transcode-status ...
uboverride ...
unblockself ...
undelete ...
unwatchedpages ...
upload ...
upload_by_url ...

Steward

Stewards have complete access to the wiki interface, and perform technical implementation of community consensus, deal with emergencies, and intervene against crosswiki vandalism. Stewards are elected annually with participation from all wikis.

See also