Stewards/Handbook

This handbook is designed to document the duties of Stewards and how to perform them in accordance with policies and guidelines.

Global account management

Locking and hiding

Stewards have access to the Special:CentralAuth interface, which allows accounts to be globally locked. Global locks prevent accounts from logging in across all wikis. Locked accounts can also be hidden, meaning that they will not appear on Special:GlobalUsers, or suppressed, meaning that the username will be removed from view in all edits and logs. Hiding and suppression of accounts must comply with the suppression policy.

Alternatively, Special:MultiLock can be used to (un)lock or (un)hide multiple global accounts at once.

Renaming

Global accounts may be renamed at Special:GlobalRenameUser. This should only be done upon request by the user. There is also a queue, Special:GlobalRenameQueue, that contains global rename requests which need to be processed.

Note that global renames may take a while to complete. If a global rename reports as "failed" or takes more than a couple hours, contact a system administrator.

User rights management

Global rights and groups

Stewards have complete access to customize the rights assigned to global groups as well as users' membership in such groups. Global group membership can be assigned and removed at Special:GlobalUserRights. Permissions assigned to global groups can be viewed and edited at Special:GlobalGroupPermissions.

Also, global groups can be configured to only apply on a specific set of wikis. These "wiki sets" can be created and modified at Special:WikiSets.

Local groups

Stewards also have complete access to configure membership in local groups on all wikis. For transparency purposes, these changes must be made on Meta.

To access a user's rights management page, go to Special:UserRights and enter the following:

username@languageproject

• username is the username of the user.
• language is the two-letter language code of the project, if any ("en" for English projects).
• project is the project code.
  • For the statewide wiki, this is "wickedgov". For TechWiki, this is "techwiki".
  • For municipality wikis, use the municipality name without any spaces (for example, LambWiki uses "sterling").

Note that if you are configuring Meta group membership, you should only enter the username and leave out the "@" sign and everything after it.

Global blocks

Stewards may globally block accounts and IP addresses at Special:GlobalBlock. Unlike global locks, these actions may be locally overridden by administrators.

Note that global blocks always disable talk page access on all wikis where they are active.

By default, global blocks have no effect on Meta. If abuse on Meta has occurred or is expected, it may be a good idea to check the "Also block the given user locally on this wiki" box.

CheckUser

Stewards primarily have access to the CheckUser tool on Login Wiki. This can be used to get IP addresses and user agents for accounts newer than 90 days old. Reasonable suspicion of sockpuppetry or other disruptive behavior is required before a check can be conducted.

If necessary to prevent abuse, Stewards are also permitted to temporarily flag themselves as checkusers on other wikis (see #User rights management above).

Administrative actions

Stewards have administrator-level access on all WickedGov projects. On wikis where they do not have local administrator access, Stewards should only use administrative rights in uncontroversial cases, such as for technical maintenance or combating spam or vandalism.

Guidelines for processing requests

Permissions

General considerations

• Do not change user rights (especially administrator and bureaucrat) if there are local users who can process the request.

Administrator

• A prospective administrator should post a request for adminship on a local centralized noticeboard.
• If there is no significant participation in the request, but no objection either, Stewards may grant access for a trial period of 3 months–1 year. After the trial period, this process may be repeated, and access may be granted indefinitely.
• If there is significant participation (at least a few !votes) and a clear consensus in favor, grant access indefinitely.
• If there is no clear consensus, the request should be denied.

Bureaucrat

• Small wikis do not require bureaucrats.
• A prospective bureaucrat should post a request for bureaucratship on a local centralized noticeboard.
• The user should already be a permanent administrator.
• The community should be large enough to require bureaucrats—consider the number of administrators and bots on the wiki.
• There should be significant participation in the RfB (at least a few !votes) and a clear consensus.

Interface administrator

• The user should already be an administrator.
• Ensure that the user has enabled two-factor authentication (this can be checked at Special:VerifyOATHForUser).
• If there is no significant participation in the request, but no objection either, Stewards may grant access for a period of 3 months–1 year. After the period, this process may be repeated, and temporary access may be renewed.
• If there is significant participation (at least a few !votes) and a clear consensus in favor, grant access indefinitely, unless access is only required for a specific task. In that case, grant temporary access for the necessary duration.
• If there is no clear consensus, the request should be denied.

Bot

• A prospective bot operator should gain community approval first through a request on a centralized noticeboard; the request should generally remain open for at least 7 days. The request should detail the expected bot task(s), duration, and frequency.
• No support !votes are required, but any objections should be thoroughly discussed.
• If you are unsure whether the bot will run properly, consider asking for trial edits before flagging the bot.

Checkuser

• Read the CheckUser policy carefully.
• Ensure that the candidate's username appears on the identification noticeboard.
• The user should already be an administrator or ArbCom member.
• Ensure that the user has enabled two-factor authentication (this can be checked at Special:VerifyOATHForUser).
• Each community with local checkusers must have at least two checkusers; do not grant access if a user would be the only checkuser on the wiki.
• Small wikis do not require checkusers—consider the size of the community and the number of local checks that currently need to be performed by Stewards.
• There should be thorough participation in the RfCU (numerous !votes) and a clear consensus.

Suppressor

• Read the suppression policy carefully.
• Ensure that the candidate's username appears on the identification noticeboard.
• The user should already be an administrator or ArbCom member.
• Ensure that the user has enabled two-factor authentication (this can be checked at Special:VerifyOATHForUser).
• Each community with local suppressors must have at least two suppressors; do not grant access if a user would be the only suppressor on the wiki.
• Small wikis do not require suppressors—consider the size of the community and the number of local suppressions that currently need to be performed by Stewards.
• There should be thorough participation in the RfOS (numerous !votes) and a clear consensus.

Other permissions

• These permissions include account creator, transwiki/XML importer, translation administrator, and any sub-sysop permission.
• The candidate should make a request on the local wiki; the request should generally remain open for at least 7 days.
• No support !votes are required, but any objections should be thoroughly discussed.