Imagining a sysadmin team

[Owen Taylor <otaylor redhat com>]

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
that we 

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.

Thanks,
						Owen

===

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
feature later.

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:

Authority

 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
 person?

Access

 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
   something like:

   - 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
     gnome.org machines.

   - 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
     find.)

4. Create an initial membership for the team.

5. Let the team take it from there.