Imagining a sysadmin team
- From: Owen Taylor <otaylor redhat com>
- To: foundation-list gnome org
- Subject: Imagining a sysadmin team
- Date: Wed, 01 Oct 2003 18:26:27 -0400
Here's a document that I floated to the board and the gnome-sysadmin
mailing list a while ago. It explores formalizing the current ways
The two concerns that were brought up at that time were:
- Doing stuff in the open; there should be public plans for
projects underway and future improvements.
- Distribution; should we be spreading the gnome servers out
more and taking advantage of a wider range of resources
available to GNOME participants?
I'd generally see these as issues that the sysadmin team would
tackle rather than things that should be decided in advance.
Anyways, I'd welcome feedback on the following.
The current ad-hoc methods of maintaining the gnome.org infrastructure
have definite downsides. Primarily, they tend to exclude people who
are mainly interesting in contributing to the sysadmin effort in favor
of those who help out in other ways and thus gain trust in the GNOME
community. A related problem is that the people who do work on the
gnome.org infrastructure have significant responsibilities elsewhere
and seldom have time to do all the needed tasks.
Another problem is that people tend to move in and out of sysadmin
duties in a very unstructured manner; someone has time to work on a
task, eventually gets the necessary privileges, implements the
feature, then goes on to other things, not necessarily leaving behind
enough documentation for someone else to maintain and extend the
These problems will become even more noticeable if we want to extend
the gnome.org infrastructure to handle user needs as well as developer
needs; in general, the gnome.org infrastructure is currently almost
exclusively a developer infrastructure -- user interaction is only
in peripheral ways such as buzilla or web pages with information about
releases and downloading software. But there have been discussions about
adding services such as weather feeds to gnome.org.
We can identify various characteristics needed by a sysadmin team:
The sysadmin team needs the authority to make decisions and implement
them without being second guessed. This is essential to both
efficient operation and maintaining the interest of those involved.
Accountability and Responsibility.
The flip side of authority is responsibility for the actions and
decisions that are taken. Being able to track this allows
There are two parts of this; first, tracking actions to those who
made them: this is largely the function of a culture and policy of
documentation, through infrastructure (keeping config files in CVS,
for example) can help as well.
Second, there is some need to keep track of real world contact
information for the sysadmin team. If somebody made a change that
broke things, and isn't checking their email, do we have a phone
number? Is there some connection from the online identity to a real
Some tasks require physical access... we need to make sure that when
such tasks need doing, the sysadmin team can get someone to do them.
(The resources for this might be sysadmin team members with
physical access, or they might be people that the sysadmin team can
get to do stuff on their behalf who aren't actually formally team
members, such as members of the Red Hat IS staff.)
So, how do go about establishing such a team:
1. Choose a team lead: someone needs to be in charge of keeping the
process moving along, of making the final decisions, and
communicating with the GNOME foundation board.
I'd imagine this person would be appointed by the board with
consensus from the people currently working on sysadmin.
2. Establish policies for joining the sysadmin team and minimum and
maximum team sizes. I'd imagine that the policies would be
- Has sponsorship by 2 GNOME board members or existing sysadmin
team members. (Some bootstrap questions here, but we can
reasonably identify a set of people doing sysadmin currently that
could sponsor the initial sysadmin team.)
- Promises to stay involved for a year, or to formally withdraw
when that is no longer possible.
- Provides a GPG key for email communication that we verify using
one or more independent channels.
3. Establish necessary initial infrastructure for the team.
- Login access and admin privileges for team members on the
- A place for documentation; an automatic checkout from a the admin
repository on cvs.gnome.org to a team-only web page would be
best. (Requires a way of having a team-only visible web page... a
simple password protected website with a known password should be
4. Create an initial membership for the team.
5. Let the team take it from there.
] [Thread Prev