Steward handbook - Meta-Wiki

Steward handbook - Meta-Wiki
Jump to content
From Meta, a Wikimedia project coordination wiki
Translate this page
Other languages:
Bahasa Indonesia
Esperanto
Tiếng Việt
Türkçe
azərbaycanca
dansk
italiano
kabuverdianu
magyar
occitan
português
português do Brasil
čeština
Ελληνικά
беларуская (тарашкевіца)
македонски
русский
العربية
تۆرکجه
مصرى
नेपाली
ગુજરાતી
မြန်မာဘာသာ
中文
閩南語 / Bân-lâm-gí
ꠍꠤꠟꠐꠤ
한국어
Stewards
Steward handbook
Shortcut
SH
This page documents
steward
tools, and provides guidelines and suggestions about their use. See also
CheckUser
oversight
, and
steward
policies. For discussion of steward activity, see the
Stewards' noticeboard
Stewards
About stewards
Elections
History
Requests
CheckUser information
Global blocks & locks
Global rights
Local bot rights
Local rights
Account renaming
Miscellaneous requests
URL blacklisting
Title/username blacklisting
For stewards
Help
Policies
Bugs
Mailing list
#wikimedia-stewards
connect
Noticeboards
Access policy noticeboard
Stewards' noticeboard
User groups and rights adjustment
Single wikis
Screenshot of
Special:UserRights
Stewards can use
Special:UserRights
on Meta to adjust users' access on any
Wikimedia project
by checking or unchecking specific
groups
. Each group is assigned a set of rights
in the MediaWiki configuration
, listed by
Special:ListGroupRights
on each wiki.
Enter the user name.
The format must be “
Username
database_prefix
” (for users on other wikis) or “
Username
” (for users on Meta-Wiki).
The first letter of the name must be uppercase (unless the wiki allows case-sensitive first letters in names).
The database prefix consists of the language code for wikis with subdomains (replacing hyphens with underscores), followed by the project's prefix shown below.
Click “Edit user groups”. A new box will appear showing you what groups the user is already in, and which other groups are available.
Reassign the groups.
To assign a new group, check the appropriate group.
To remove a group, uncheck the appropriate group.
If the assignment is for a finite period time, choose an appropriate duration from the drop down menu.
Click “Save user groups”.
Database prefixes
The prefixes for the main projects are shown below. For others, see the
full list
. Note that hyphens (
) should be replaced with underscores (
), so for example
cbk_zamwiki
is the DB name for
cbk-zam.wikipedia.org
Project
Prefix
Multilingual wikis
Wikimedia Commons
commonswiki
Wikimedia Foundation Governance
foundationwiki
Wikifunctions
wikifunctionswiki
Wikimedia Incubator
incubatorwiki
MediaWiki
mediawikiwiki
Multilingual Wikisource
sourceswiki
Test Wikipedia
testwiki
Test Wikipedia 2
test2wiki
Test Wikidata
testwikidatawiki
Wikidata
wikidatawiki
Wikispecies
specieswiki
Wikis with subdomains
Wikibooks
code
wikibooks
Wikinews
code
wikinews
Wikipedia
code
wiki
Wikiquote
code
wikiquote
Wikisource
code
wikisource
Wikiversity
code
wikiversity
Wikivoyage
code
wikivoyage
Wiktionary
code
wiktionary
Examples
English Wikipedia
Billy@enwiki
French Wikiversity
Billy@frwikiversity
Classical Chinese Wikipedia
Billy@zh_classicalwiki
Multilingual Wikisource
Billy@sourceswiki
Rights
The following groups can be manipulated (among others on some wikis):
Non-restricted groups:
Bots
Administrators
Bureaucrats
Account creators
Importers
Transwiki importers
IP block exemptions
Flood flag
Confirmed users
Autopatrollers
Restricted groups:
CheckUsers
– subject to
CheckUser policy
and
Access to nonpublic personal data policy
. See
below
for details.
Oversighters
– subject to
Oversight policy
and
Access to nonpublic personal data policy
. See
below
for details.
Very restricted groups:
Stewards
– Do not manipulate the steward flag on any wiki except Meta, and only then after a steward election or when a steward has resigned.
WMF Office IT
– Do not manipulate this flag on any user unless the
Wikimedia Foundation
asks you to do so.
WMF Trust and Safety
– Same as above.
Encoding problems
Many browsers have difficulty manipulating user names in non-Latin characters. There are two ways to get around this problem:
Enter the URL-encoded name through the URL.
First, get the URL-encoded name:
Copy it from the address bar of your browser while viewing their user page;
or, type "
{{urlencode:{{PAGENAME}}}}
" on the user's page, preview, and copy the text.
Go to
Special:Userrights
, and in the address bar add "?user=" followed by the URL-encoded name. For example,
Enter the user id (for example, "#55@frwiki" for user #55 on the French Wikipedia). There are a few ways to determine the user ID:
Use the "Page information" link from their user page (which works even when the user page doesn't exist). Another way of getting to this page is by going to
Special:PageInfo
and typing the username as the target (e.g. User:Example).
Use the
API
with a
query like this
If the user has edited on that wiki, you can find the ID by exporting that revision (if it is the latest) or exporting the whole history and locating that revision. Once located, look for the number inside "

" under "

" (make sure you're not getting the revision ID under "

").
Ask a
system administrator
in
#wikimedia-tech
connect
Globally and wiki sets
Screenshot of
Special:GlobalGroupPermissions
(group selection).
Screenshot of
Special:GlobalGroupPermissions
(rights list).
Global accounts
have the same name and password reserved on all public Wikimedia wikis (except previously existing unattached local accounts). These global accounts can be assigned global groups, which give the user certain rights on all wikis (within a specific wikiset) where their global account can log in.
Note that a
right
is a specific access (like "editinterface"), and cannot be given to a user directly; a
group
is an abstract grouping of rights (like "steward").
Managing groups
Stewards can create, edit, or delete a global group using
Special:GlobalGroupPermissions
. The scope of each group can be global (all public wikis), or defined for a specific
set of wikis
Edit:
In the "Existing groups" box, click "View and edit permissions" for the group you want to edit.
A list of possible rights will appear (see also
mw:Help:User rights
). Check the rights the group are to have and uncheck those they are not to have.
If the group needs access on specific wikis (instead of globally), select the set of wikis in the drop down menu above the list of rights (see
Managing sets of wikis
).
Enter the reason for the change in the textbox below.
Click "Save changes to group permissions". The changes will be applied immediately.
Create:
Enter the group name in the "Create a new group" textbox.
Click "Assign permissions".
Check at least one right, and if applicable select the scope (see step 2 onward
how to edit
above).
Create necessary MediaWiki pages (see
:mw:Manual:User rights
).
Delete:
Uncheck all its rights (see
how to edit
above).
The group can be recreated later, and all former members will regain the same rights.
Managing group membership
Screenshot of
Special:GlobalGroupMembership
with example content.
Stewards can edit global accounts' membership using
Special:GlobalGroupMembership
. Placing a global account in global groups will give them all the rights assigned to that group on all public wikis.
Enter the global account's user name in the textbox.
Select a wiki where they have a local account from the drop-down menu.
Click "Edit user groups". A "Edit user groups" box will appear below.
Check the global groups to assign. (Even if they are similarly named, global and local groups are not necessarily identical!)
Enter the reason for the change in the textbox.
Click "Save User Groups".
Managing sets of wikis (for global groups)
Stewards can define "wiki sets" using
Special:WikiSets
, lists of wikis where global groups can be given access (instead of globally). It's not necessary to create a set of all wikis: that is the default for global groups if no set is selected.
If you're creating a new set, click "Create a new set". Otherwise, click "view/edit" beside the name of the existing set to edit.
Enter the set's name in the "name" box. This is for the convenience of stewards, and can be changed any time.
Select the appropriate type in the "type" box (opt-in or opt-out).
Enter the
database prefixes
, one per line, in the "wiki" box.
Enter the summary or reason for your change, which will appear in the
global rights log
Managing global accounts
Screenshot of the
CentralAuth
interface for managing global accounts
Error message when trying to log in with a locked account
Stewards can access unification information about a particular global account, unattach local accounts from the global account, delete the global account (restoring all local accounts), and
lock out access
to the account using
Special:CentralAuth
(see
logs
).
Bug:
Special:CentralAuth
can only hide the global account (see
bug 14476
). An option to hide local accounts when using the CentralAuth can be enabled with the gadget in
Special:Preferences#mw-prefsection-gadgets
Global account renaming
Global accounts can be renamed (see
the help page
). If a user would like a new username, they should use the following process:
Check availability of the new name with a tool such as
CentralAuth
. If there are existing accounts with that name that have contributions, especially across multiple projects, the user is encouraged to select a different name, as usurping users with significant contributions is not likely.
Request a username change on
SRUC
Note that global renames should be done in accordance with the
global rename policy
Global account deletion
Stewards can, via
Special:CentralAuth
, delete global accounts. This should only be done when there is a compelling reason. Requests such as "I don't want it" are not sufficient to warrant a deletion.
Requests to delete the global accounts of vandals should not be performed at all, as this would interfere with the ability to lock the account in case of a spread of the abuse.
Users should be warned that preferences (including passwords and email addresses) will be reset to their pre-merge values and that they will lose any global group membership which they previously had. Local accounts will not be otherwise affected and cannot be deleted.
Some bot owners may request a deletion of the global account if it interferes with proper functioning of the bot. Of course, non-unified bots are not eligible for the "global bot" flag, and if the bot login password has changed during the time it was unified, that password will be reset to the pre-unification password.
Warning:
Once a global account is deleted, it cannot be reversed by stewards (see also
bug T25243
).
Unmerging local accounts from the global account
If a local project wishes to rename a vandal account, unmerge only that project from the vandal's global account, even if it's the only project in the global account. If there is a valid reason to not want the global account to be visible after the rename, the global account should be hidden instead of deleted, as deleting it would simply open that account name to recreation.
Global access restriction
IP address blocks
Error shown to globally blocked users when they try to edit.
Stewards can block IP addresses and
CIDR ranges
(up to /16 in size for IPv4, up to /32 for IPv6) on all public Wikimedia wikis using
Special:GlobalBlock
, and remove a global block using
Special:GlobalUnblock
(see guidelines at
Global blocking
). Current global blocks are listed on
Special:GlobalBlockList
and logged on
Special:Log/gblblock
Globally blocked IPs cannot edit any page on any wiki except MetaWiki (which allows users to appeal on Meta). When a global block conflicts with a local block, the strongest block will apply; for example, a global anonymous-only block will be overridden by a local full block.
Local administrators can unblock a globally blocked address on single wikis using
Special:GlobalBlockWhitelist
on those wikis, and customize the error message using
MediaWiki:Globalblocking-blocked
Global account lock (& hide)
See "
Managing global accounts
" above.
Global abuse filter
Since July 2013, stewards can create abuse filters on MetaWiki (
Special:AbuseFilter
) and then mark them as global; however, these global filters only apply to some wikis. See "
Global AbuseFilter
" for the current status of this tool. See
here
for some proposed guidelines during this phase of Global AbuseFilter deployment.
Guidelines for processing requests
User access
Check the
Steward requests/Permissions
page regularly
Check that the procedure on that page has been followed and that the request does not violate any policies or guidelines (see the following sections for details).
If the request is valid, fulfill it using
Special:Userrights
(see
above
for instructions).
Mark the request as fulfilled (this is most often done with {{
done
}}) or rejected ({{
not done
}}) as appropriate.
You can optionally tell the user, preferably on their own wiki, that he is now an admin and/or bureaucrat and invite him to join the admin channel by using
Template:Invite
Leave the request on
Steward requests/Permissions
to allow follow-up comments and questions. It will be moved into the archive by a bot.
General advice
Checking facts: If a user claims they already have a certain right, you can verify this by checking
Special:Listusers
on the local project. If the steward has any doubts about the request, they should discuss with one or more regular users of the local project.
Promoting very new users: There is no approved policy regarding the promotion of very new users for projects with no local community. New users should generally not be given rights until they have spent more time editing projects. However, stewards might grant new users temporary rights until a community has time to build up, at which point it can hold a vote to confirm the user's status.
Administrator and bureaucrat rights
If the wiki has a community, the community should have approved the user's request, generally on a
local request page
. The user should wait at least a week—perhaps two if the community is very small—before placing their request on Meta.
If the wiki has no community, or if it has too few active users to hold a meaningful discussion of the issue, it is probably advisable to grant temporary rather than permanent rights. Three months is a common period for temporary rights.
Be sure the community does not already have a local bureaucrat. Stewards should only grant administrator and bureaucrat requests on wikis with no local bureaucrats. The only exception to this is if all local bureaucrats have been inactive for a period of time.
CheckUser rights
Read the
CheckUser policy
carefully. Pay particular attention to the
Access section
, which specifies several important rules regarding the bestowal of this status. The use of this tool can have legal implications, so knowing and following the policy is of the utmost importance. Breach of the rules in this policy may result in removal of steward rights.
Send
this e-mail
to the user to request that they sign the
Confidentiality agreement for nonpublic information
with the Wikimedia Foundation, record on the
request page
that the mail has been sent.
If the user claims to have already signed the confidentiality agreement with the Foundation, check the
Access to nonpublic personal data policy noticeboard
or ask for confirmation of this fact from the
Trust and Safety
team.
Grant rights only after receiving confirmation from the Wikimedia Foundation that the confidentiality agreement has been signed.
After granting access, list the user in the appropriate section on
CheckUser
Ask the user to subscribe to
checkuser-l
, and
notify the listadmins
that the user has been approved.
Oversight rights
Read the policy at
Oversight policy
carefully. Pay particular attention to the
Access section
, which specifies several important rules regarding the bestowal of this status. The use of this tool can have legal implications, so knowing and following the policy is of the utmost importance. Breach of the rules in this policy may result in removal of steward rights.
On the English Wikipedia, only the Arbitration Committee can approve a request for this status.
Send
this e-mail
to the user to request that they sign the
Confidentiality agreement for nonpublic information
with the Wikimedia Foundation, record on the
request page
that the mail has been sent.
If the user claims to have already signed the confidentiality agreement with the Foundation, check the
Access to nonpublic personal data policy noticeboard
or ask for confirmation of this fact from the
Trust and Safety team
Grant rights only after receiving confirmation from the Wikimedia Foundation that the confidentiality agreement has been signed.
After granting access, list the user at
Oversight policy/User list
Removal of access
If a user requests that their own rights be removed, it is generally put on hold for some time (usually 24 hours) to allow the user to change their mind if they wish to do so.
If a user requests that another user's rights be removed, be sure that the action complies with the local wiki's policy on removal of rights. This will often involve sifting through a lengthy debate on a local request page to confirm the validity of the procedure.
After removing a user's checkuser or oversight rights, do not forget to remove them from the corresponding lists.
Temporary rights
The precise duration is a matter of discretion; three months and six months appear to be the most common.
CheckUser information
See
Steward requests/Checkuser
If local checkusers exist in a project, checks should generally be handled by those. In emergencies or for multi-project checkuser checks as in the case of cross-wiki vandalism stewards may perform local checks. Stewards should remove checkuser access on the projects upon completion of the checks and notify the local checkusers or checkuser email list.
(from the official
CheckUser policy page
Stewards may checkuser on loginwiki as a form of long-requested "cross-wiki checkusering" (
link
).
Note: The German Wikipedia requests that absolutely
all
CheckUser queries must be announced on
de:Wikipedia:Checkuser/Anfragen
(please ask the local users with access if you need help with formulation, or with precisely
what
should be published).
Other steward tasks
Ideally, one or several stewards should be 'on duty' in the
#wikimedia-stewards
connect
IRC channel
at any given time. Users of small wikis are encouraged to use this channel to report emergencies, but it has also been used for conversation about and among stewards, and for discussion of routine matters.
We have a
VRT queue
, ideally at least one steward should review and sort the incoming queue at least once a day.
Email templates
To be sent to users with access to private data:
Notification that signing confidentiality agreement is required
Communication with other stewards
Mailing list
: There is a private stewards
mailing list
, for discussions of policy and private requests. Please be advised that some mail services might mark some mail as "Spam". For instance, when using Gmail, it may be useful to setup a filter, instructing the service to avoid marking mails that are addressed "To: stewards-l@lists.wikimedia.org", checking the box "Never send it to Spam".
IRC
: The public
#wikimedia-stewards
connect
channel
is a place to ask for help, announce emergencies, or discuss ongoing events with stewards and others.
stewardbot
will flag stewards' attention in the channel if you say
@steward
for routine requests and
!steward
for urgent requests.
Meta
: High-level discussion about policy and other wikis takes place on the
Stewards’ noticeboard
and
Babel
Tools and bug reports
See also
Admin tools development
and
Phabricator for stewards
Tools
Main page:
Small Wiki Monitoring Team/Tools
user or wiki activity
CrossActivity
: one user's edit/sysop/bureaucrat activity on all wikis.
Stewardry
: sysops/bureaucrats/checkusers/oversighters on a wiki by date of last activity (log and edits).
Steward activity statistics
: times of the last log actions per steward.
dead link
User contributions
: contributions and block status on all wikis for the given user name.
Event Streams
: Filter and get notified above events across all wikis in real time.
other
CrossBlock
: block status of given IP, CIDR range, or user on all wikis with links to prefilled block/unblock forms.
gUserSearch
: search and filter global accounts by exact, partial, or regex match.
SULutil
and
Stalktoy
: information about a given global account, and information and unification status for each local account with that name.
SULWatcher - Reports
: reports and logs of
SULWatcher's
monitoring of account unifications.
Steward requests
: overview of open steward requests.
JavaScript
StewardScript
: adds shortcuts to the Meta interface for quicker stewarding.
hideuser
: allows quickly crosswiki local-hiding of globally locked & hidden accounts; available on the
gadgets
tab of
Special:Preferences
IRC
StewardBot
: a
Python
script which accepts commands from authorized stewards on IRC and performs utility operations related to steward activities.
Retrieved from "
Category
Stewards
Steward handbook
Add topic