Tech:Appointment and revocation policy

This policy concerns the procedure for appointing a new system administrator. Tech:Access policy details how a prospective system administrator requests access. Quoted from that page: "Granting shell access (aka access to a server, or multiple servers) to someone needs to be done with extreme caution. With more people having shell access to (critical) servers, the chances of suffering from human mistakes and compromised shell accounts do increase".

Appointment
Once an access request is made, any system administrator should feel free to ask the prospective sysadmin relevant questions: whether they are about hypothetical situations they may encounter, what tasks they plan on focusing on, what the role means for them, etc.

While not necessary, it is encouraged that all sysadmins take part in the discussion and comment. Once an access request has elapsed an appropriate period of time (a few days to a week), the Engineering Managers will discuss the request together and make a joint decision taking into account all comments received, relevant experience and community engagement. Depending on the request, either the Engineering Manager for MediaWiki (sysadmin global group, mw-admin access level) or the Engineering Manager for Infrastructure will close the Phabricator task with the decision. The Director of Site Reliability Engineering will retain the right to overrule the Engineering Managers' decision in exceptional circumstances.

Re-appointment after inactivity
See Tech:Inactivity policy

Removal
In the unfortunate circumstance that a sysadmin falls under the standards of a system administrator, violates policies deliberately, acts inappropriately, etc. the removal procedure may be initiated. It is to be noted that removal is the last resort, and that before considering removal, attempts to rectify the situation by communicating with the user in question should be made.

If a sysadmin believes that one of their colleagues falls under the aforementioned, they may contact their Engineering Manager and explain their situation and their thoughts on the matter. If the Engineering Manager in question disagrees and declines to forward the request to the DSRE for consideration, the system administrator may directly contact the Director of Site Reliability Engineering (DSRE) themselves, but this should only be in exceptional circumstances and should be avoided.

The Engineering Manager for the relevant team may propose that a system administrator is removed to the SRE Management Team either after having received a report from a team member or of their own accord. The Director of Site Reliability Engineering (DSRE) as well as the two Engineering Managers will weigh the arguments and may consult the whole Site Reliability Engineering team on whether they believe the user in question should be removed.

For inactivity
See Tech:Inactivity policy

Suspension
In exceptional circumstances, where waiting for the removal process to take place is not practical or possible, a user may be temporarily suspended and have their all access removed by the Director of Site Reliability Engineering (DSRE) or one of the Engineering Managers (EMs). This would be followed by the regular removal procedure, and access would be added back if it is ultimately decided against removal.

In ultimate emergencies, such as compromised accounts, any member with the relevant permissions may temporarily remove another sysadmin from the compromised account in question.

New Access
This applies to people, who do not have shell access yet. After you have articulated a valid reason for requesting shell access, and followed the instructions below, your request will be dealt with as described above.
 * Ensure you have an account on GitHub and Phabricator (which requires a Miraheze account).
 * Login into Phabricator, and fill in this form (do not forget to replace "[USERNAME]" with your username!). The form should contain the following information:
 * Miraheze Username
 * GitHub Username
 * Preferred shell username
 * A freshly generated 4096 bit RSA or ed25519 keypair, protected with a secure password.
 * Obviously you should only give us the public key, keep the private key private.
 * This key should not be used for non-Miraheze servers!
 * Description of the access you need. If you need sudo rights, please do not forget to include that as well.
 * The reason why you need shell access.
 * A verification that your Miraheze, GitHub and Phabricator accounts are owned by you. This can be accomplished by a) pasting the public key of your keypair on your Miraheze Meta userpage (or another page in your user namespace) and b) creating a GitHub repository with a file containing the public key (or committing your public key to an already existing repository).

Expanding Current Access
If you already have a shell account, and want to get extra privileges (or requesting access to more servers) after this process has been completed then you need to:
 * Login to Phabricator and make a new request by using this form including in the request:
 * Why you need extra access and what benefit this would provide to either Miraheze or yourself (in respect to productivity);
 * What access you specifically need (log viewing, service interaction, ability to deploy changes).