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.
 * Access must be revoked on off-boarding, no exceptions (unless the user is a steward or Board member).
 * 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 MirahezeBot 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 MirahezeBot 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.
 * Access must be revoked on off-boarding, no exceptions.

LDAP

 * An LDAP account should be made for a new MediaWiki Administrators or Site Reliability Engineer.
 * 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 MediaWiki Administrators or Site Reliability Engineers being on-boarded should be given adminship to Grafana.
 * Access must be revoked on off-boarding, no exceptions.

Graylog

 * New MediaWiki Administrators or Site Reliability Engineers must receive access to Graylog. MediaWiki Administrators: grant Reader role only, you should share access to the MediaWiki related streams in Graylog. Site Reliability Engineer: grant Admin role.
 * Access must be revoked on off-boarding, no exceptions.

Matomo

 * The user may be given access to Matomo, our analytics platform. There are separate groups for MediaWiki Administrators and Site Reliability Engineers.
 * 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 acl*security group so they can function effectively in the worst case scenario of a security issue.
 * On off-boarding, this group must be revoked. If the user thinks they have an important reason to keep access, please discuss with your colleagues.

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, unless the user intends to keep managing social media and is trustworthy enough. Use your judgement.

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, unless the user intends to keep managing social media and is trustworthy enough. Use your judgement.

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.
 * Access must be revoked on off-boarding, 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.