Tech:On-Off Boarding

This page groups together all documentation over on and off boarding volunteers with a level of escalated permissions (shell is the main one here right now). The page is written in the tense of on-boarding and any changes where necessary in the case of offboarding will be written below it.

Shell
This section is generic to all shell requests.

Email

 * Add them to relevant email aliases for their relevant function. As a base line, all shell users should be in tech.
 * Add a mail account for the user
 * On off-boarding, remove them from all the aliases they no longer need. By-standers in tech are generally fine but it's best to inform tech@ first.

IRC

 * Access to #miraheze-staff should be given.
 * On off-boarding, this should be revoked.
 * Elevation of rights in #miraheze and #miraheze-offtopic may also be given or alternatively just +V in the channel. Channel Operators should be added to the relevant config in ZppixBot for channel management.
 * On off-boarding, +V may be taken away. Ops access can stay if the user is trustworthy. If ops access is removed, revoke ZppixBot channel management access.

GitHub

 * The user should be added to the relevant team in the GitHub account (usually mw-admins) which then provides sufficient access to push commits to the repositories they need to fulfil their role.
 * On off-boarding, this access must be revoked.

LDAP

 * An LDAP account should be made for a new system administrator
 * On off-boarding, the LDAP account would not necessarily need to be deleted as long as the user doesn't have access to anything private or to execute anything

Grafana

 * New system administrators being on-boarded should be given adminship to Grafana.
 * This must be revoked on off-boarding.

Matomo

 * The user may be given access to Matomo, our analytics platform.
 * On off-boarding, this should be revoked by default, although there may be legitimate reasons to keep access.

Monitoring

 * If the user wants monitoring alerts via email, add them to icinga and then add them to a monitoring group.
 * On off-boarding, remove both contact and the addition to group definitions for the user.

Status Page

 * System administrators may also be added to http://status.miraheze.wiki/, which is done via hund.io
 * Access should be revoked on off-boarding

Phabricator

 * Add the user to the Security group so they can function effectively in the worst case scenario of a security issue.
 * On off-boarding, use judgement on whether to remove them from the group or not. If they're useful or will be staying around, they can stay otherwise it's best to remove them.

Wiki

 * For MediaWiki system administrators, the global system administrator group may be useful - it is however not a strict requirement.
 * On off-boarding, any access to global groups or technical wikis must be revoked if it was for the purpose of being a volunteer with shell or privileged access.

Twitter

 * If a new system administrator wishes they may request access to the @miraheze Twitter account. This access can only be given by Southparkfan
 * Access to the Twitter account should be revoked on off-boarding

Facebook
If a new system administrator wishes they may request access to the @miraheze Facebook page.
 * Access to the Facebook page should be revoked on off-boarding

Site Reliability Engineering
The above applies, this section covers things which are specific to operations only.

OVH and RamNode

 * Basic access to the two accounts for ticketing purposes and the 'operations back door' should be granted. This should be so any operations member can fulfil their duties on their own.
 * On off-boarding, this access must be revoked with no exceptions.

Private Git

 * Site Reliability Engineers and Puppet Users should be talked through how private git works and how to access and commit things to it. This is granted through root on puppet2 and no specific access is necessary besides puppet2 root.