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[edit | edit source]
This section is generic to all shell requests.
Email[edit | edit source]
- Add them to relevant email aliases for their relevant function. As a base line, all shell users should be in staff.
- On off-boarding, remove them from all the aliases they no longer need. By-standers in staff are generally fine but it's best to inform staff@ first.
IRC[edit | edit source]
- 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[edit | edit source]
- 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.
Grafana[edit | edit source]
- New system administrators being on-boarded should be given adminship to Grafana.
- This must be revoked on off-boarding.
Matomo[edit | edit source]
- 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[edit | edit source]
- 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.
Phabricator[edit | edit source]
- 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[edit | edit source]
- 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.
Site Reliability Engineering[edit | edit source]
The above applies, this section covers things which are specific to operations only.
Backupsy / RamNode[edit | edit source]
- 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[edit | edit source]
- Site Reliability Engineering should be talked through how private git works and how to access and commit things to it. This is granted through root on puppet1 and no specific access is necessary besides puppet1 root.