Formalizing the Sysadmin Team
(by OwenTaylor)
The Challenge
We've ended up in a situation where we have a severe sysadmin shortage. We haven't added anybody new to the team in a while, and the people who have been doing work over the last few years have largely stopped doing so, either gradually or abruptly.
The biggest problem that we've always had with the maintaining an active sysadmin team is the need for trust. If somebody shows up and wants to help out with a GNOME coding project, then it's easy to build up trust over time. Suggest a project, have the person send patches, review the patches, if the patches are good, eventually give them direct commit access. However, for sysadmin work, we get a lot of people who want to help out, but it's very hard for someone to contribute without being given a "dangerous" level of access to the GNOME systems.
The second problem is related: the people who have an existing high level of trust in the GNOME community generally have other responsibilities and interests, even if they have some sysadmin skills. And they generally aren't sysadmin experts with a lot of background in areas like networking, server configuration, and configuration management. So, the tendency is for people to get involved to help in a crisis, then to drift off.
The proposal
One idea I have is that it might be worthwhile to formalize the sysadmin team, the same way we formalize the release team or membership team. By that, I mean more or less: have a public identification of the team members with a more-or-less fixed size. Pick a team leader. Specify responsibilities for the team members and team leader.
The responsibility of team members would be to spend some time each week on routine work (handling the ticket queue), to attend weekly IRC meetings, to volunteer for infrastructure development projects as needed.
The responsibility of the team leader, in addition of that a team member would be to make to formulate an agenda for the weekly meeting, to provide a monthly status to the board with statistics on how routine tickets are being handled, and a progress report on what development projects are under way.
How would formalization help? Well, it would give more visibility into how sysadmin work is staffed; right now we have people with sysadmin privileges that drift off and stop doing stuff but never actually say that they are stopping doing work. If members explicitly resigned and were replaced, that would force new blood to be brought in. It would also give a bit more prestige to the sysadmin role. And by introducing the team lead role, it would make responsibility more clear and reporting more feasible.
It doesn't really have an answer to the question of trust: how do we find candidates to fill vacancies on the team? I think you'd basically have to have an application process. Candidates would need to give information about their experience with sysadmin, have a demonstrated commitment to GNOME by work on bug-triaging/translations/coding/whatever and be people known to the community. (maybe just by hanging out on #sysadmin for a few months.) The team leader, in consultation withthe rest of the team, would have the responsibility for encouraging people to apply and collecting data about applicants.
The short term
Assuming that people like the above idea, how would we get there? A possible plan of action is: pick an interim team lead and team members and a weekly meeting time. The interim team would have with two responsibilities. First, to catch up the request queue. Second, to determine the lead and team for the next year.