Title here
Summary here
Tech:Inactivity policy
{{ {{Outdated}} }}
System administrators are responsible for making sure that things run smoothly, and that the different issues and tasks on Phorge are completed in a timely and effective manner (see Tech:Volunteers and Tech:Organization for details). While we are all volunteers here and all have real life responsibilities, activity is nevertheless important for any sysadmin, and a prolonged period of inactivity may provoke security concerns. The purpose of this policy is to ensure that people are aware whenever a sysadmin knows that they will be inactive, as well as to have a criteria for when someone is inactive and do not notify their absence.
Notification
The Engineering Managers are responsible for their teams and for keeping track of the activity of their team members. In case a sysadmin must be completely or for the most part inactive for a period of time, the following should be done depending on the period in question:
Less than 2 weeks: If the planned inactivity is less than two weeks, it will not be necessary for a sysadmin to send an email to notify their Engineering Manager (EM). If there are tasks assigned to the person that must be completed during this week; however, they should contact their EM so that they can figure out who can take over the tasks
Between 2 weeks and 2 months: If a sysadmin plans to be inactive for more than two weeks, they should notify their EM (and preferably their team as well) via email and let them know the estimated period of absence and the reason (i.e. health issues, real life duties (exam week, college, work), etc.). If it’s a health issue, you are not obliged to disclose the nature of your health issue and simply stating that it is a health issue with no further details will suffice. The EM may choose to decline a request if no reason has been given for the absence, or if there have been multiple long absences during the year. Afterwards, the EM will coordinate with the other team members to fill in the “gap” caused by the absence. It may be useful to also indicate the absence by creating a Phorge calendar event.
More than 2 months: If a sysadmin plans to be inactive for more than three months, it is highly recommended that they (temporarily) step down, per the 5th clause of the Code of Conduct. If for whatever reason, they feel like they do not need to step down, they should contact their EM and ask them if they can take the longer break without stepping down. The EM may decline this and ask the sysadmin in question to step down.
Holiday periods
The requirements above are relaxed during general holiday periods such as Christmas, New Year’s, Easter, the Summer Holiday period and any other holidays. However, due to the fact that everyone will inevitably be unavailable at some point during these periods, each team should coordinate in order to organise who will be available during which week. Sysadmins during these periods of times should create Phorge calendar events for this signalling the time period during which they will be unavailable.
Assessment of activity
If a sysadmin has not notified their EM that they will be unavailable (outside holiday periods), their activity will be reviewed and evaluated by their EM. It would not be practical to require precise statistics or numbers (i.e. “x SAL entries per month”), so instead some general criteria will be provided that EMs should use. The following should be assessed:
- Server access - Have they been regularly accessing servers to perform different tasks, run commands/scripts, check logs? (may be via Tech:SAL or other public means)
- GitHub commits - Have they been actively contributing to any Miraheze GitHub repository?
- Phorge - Have they actively been taking part in discussions on Phorge, leaving comments, and more importantly, actually resolving tasks?
- IRC/Discord - Have they been actively communicating on IRC and/or Discord in a technical context?
- On-wiki - While not directly relevant to sysadmin work, helping out users with technical issues may be considered (primarily for MW Engineers)
It is to be noted that when evaluating this criteria, more weight will naturally be given to the first three aspects, as one does not have to be a sysadmin to communicate via IRC/Discord or to help users on wiki. The criteria aims to evaluate how people are using their sysadmin permissions.
The criteria is evaluated based on exactly one month from the date it is being made (i.e. if someone evaluates a user on the 1st of February, activity from 1 January to 1 February is taken into account)
The person evaluating the user will make a conclusion based on the factors above, and either consider a user to be “active” or “inactive” (semi-active would rather be categorised as “active”). If an EM finds that a user is inactive (without having notified them beforehand) they should contact the person in question and let them know of their findings and ask them to take steps to the effect of being more active.
Removal for inactivity
If a person has been found to be inactive based on the criteria above more than once and has been told about this, and has seemingly made no efforts to improve their activity, the EM can begin the removal procedure. The Engineering Manager (EM) should forward their findings to the SRE Management Team (comprised of the two EMs) which will make the final determination whether a person should be removed. In practice, it is unlikely that a person will not be removed if they have been warned about their inactivity in the past and have done nothing to rectify that (including failing to formally notify their EM of periods when they will be absent).
Re-appointment
If a user resigns due to the fact that they know they will be inactive, they may be re-added more easily than if they were applying for the first time. This however, does not apply to sysadmins who are removed for inactivity; they must follow the same procedure as a “new” sysadmin.
If a former sysadmin wishes to come back after having resigned for being inactive, they should follow the requesting access steps again,. However, instead of the procedure detailed in the Tech:Appointment and revocation policy, they may be quickly re-added with the common accord of the SRE Management Team.