We need a bigger staff!

Jan 7 02:25 UTC 1995

One of the chronic problems with getting things done here is staff time. 
Now our staff does heroic things as is, but we need more people.  How can
we go about getting more people interested, or informed of the need for
help so that we don't have to rely so heavily on our current staff?

response 2 of 52:

Jan 7 03:42 UTC 1995

can someone enumerate what skills would be helpful?

response 4 of 52:

Jan 7 05:05 UTC 1995

   Heh heh-hahahahahahahahahahahahahahahahahahahaha...........

   (me thinks we got ourselves another vict--I mean, I think we
have another potential staff person).

   Unforunately, Marcus is right.  Case in point, the ROM we got
for the Sun-3.  When I installed it, I had to keep in mind the 5PM
deadline for getting the system back together enough to start the
boot process, else Grex would have to be down until we could get
back in there, or the start of the next business day, about 16 hours
away.

   So getting access to the system when we want/need to is going to
make one hell of a difference.  There have been plenty of times that
I've had an hour or three to spend on Grex, but couldn't becuase it
wasn't during the hours that CE was open.

   Having said that, we still need more staff here.  One of the
things we can and should have done a while ago, was to come up with
a list of the things that perodically need to be done, and a coorosponding
set of tools to do them.  This is an area that we didn't have to worry
about so much back in the Olden Days, but with all the activity here
now, we need to do that.  THere was once a point in time where we delted
accounts that wern't used in the current year and could be deleted. ;-)

response 6 of 52:

Jan 7 17:36 UTC 1995

plus, there's still that sysadmin101 that STeve's been working on.
I think that'll help a lot.

response 8 of 52:

Jan 7 20:00 UTC 1995

Cool, STeve.  Thanks for preparing that (I'd wondered what became of that
idea).

response 10 of 52:

Jan 7 22:22 UTC 1995

I would like to get a better understanding of how staffing occurred, and
occurs, on Grex. I would appreciate it if the current staff would
offer their observations on the following questions:

1. How did the current staff develop? Is it essentially the same unix
   experts that got together to create Grex? 

2. Why isn't the process that created Grex and its current staff still
   functioning? What can be done to create the situation that led to
   the consolidation of the current staff, so that the process
   continues?

response 12 of 52:

Jan 8 01:51 UTC 1995

My observation, as a non-staffer, is that the process that created 
Grex isn't working as well as it did is that a big part of it moved
to Pittsburgh and we're asking staff to do a lot more these days.
Just adding the internet stuff has added immensely to staff chores.

response 14 of 52:

Jan 8 02:19 UTC 1995

One of the key things that has to happen is that there has to be a lot
of trust, hard work, a commitment to quality, and communications going
on.  We don't want to invite the friendly neighborhood vandal to become
a staff member, staff needs to be able to work well together, and the
users of the system have entrusted a lot of responsibilty to the staff;
staff needs to be capable of living up to those expectations.

response 16 of 52:

Jan 8 04:40 UTC 1995

That's one of those icky questions that is, unfortunately, probably best
left unanswered.  Well, actually, there is one easy honest answer, "I
don't know", because I don't know how many people other staffers have
thought "gee, I wish we could ask that person to join staff, but I don't
care because of X" (X could be any number of problems, not just
personality conflicts.)

Not all staff members are, or ever were, unix gurus.  We've got quite a
few people with different levels and types of experience, doing
different things.  Hm.  Of the current staff members, 5 out of 9 are
"founders"; and only 4 of 9 are of the type who build kernels as
afternoon projects.  So, it's a mistake to think there is no process to
add staff members, or that they are all founding unix gurus.

The process for adding staff members has generally been quite ad hoc.
It's been a question of identifying needs, then looking for people,
either existing staff members, or more often, other users on the system
who are not staff members, but who might be qualified and interested in
working on the problem, and asking them.  The people doing this are
existing staff members, since they have the best grasp on what the
problems are and who might best solve them.  The process hasn't been a
public process, because we want to avoid having the process turn into a
popularity contest, or hurt feelings from people who weren't selected.
We have also tried to avoid having staff make policy decisions.  All of
the founders, certainly, and most if not all of the current staff, think
those decisions should be made by the members, and not by staff.
Whenever policy decisions occur, especially ones that we think might be
controversial in any way, we try to bring those out in the open here.
We want, very much, to avoid any possibilty that people might see being
a grex staff person as being in any way glamorous, powerful, or sexy, or
anything other than a lot of responsibilty and hard work, work which if
properly done will probably not even be noticed by most.  That's why
we've kept as low key as possible.  By and large, we don't even have any
official titles.

Kernel type work is actually relatively rare; a more common occupation
is installing various applications.  Unix and C programming and trust
are important, but not deep knowledge of the kernel or of systems
programming, necessarily.  Several people don't actually do any
programming at all, but do maintenance and support type activities.
That includes things like cleaning out the mail queue, hassling people
about big files, or restarting daemons if they hiccup.  Another level of
non-programming is involved with things like rebooting the system when
it dies, doing backups, and so forth.  In a big mainframe shop, those
people would be called operators.

There are 2 main areas where we are "hurting" for staff; we have limited
access to the hardware, so that limits backups and other routine
operational needs.  The other area where we are hurting is in terms of
fixing the disk, implementing the new network policy, and so forth.
These all share the property that they require extended non-routine
access to the hardware.  Adding more staff won't fix these problems.

response 18 of 52:

Jan 8 06:06 UTC 1995

Staff members are: steve gregc mdw mju popcorn remmers meg morel srw
Of these, I think meg and morel have gone somewhat inactive, and
I tend to be inactive when I'm at school in Pittsburgh.  That means
that the "staff regulars" are really steve, gregc, mdw, popcorn,
remmers, and srw -- six people.  Staff probably each put in around
1-3 hours per day, every day, so say 2*6*7 = around 84 person-hours
per week.  There are, of course, days when an individual staff membe
puts in more than that -- there have been days when I've spent
in excess of 16 hours working on Grex, and this is true for other
staff members, too.

response 20 of 52:

Jan 8 08:05 UTC 1995

You definitely should be even the original isn't entirely accurate.  I
meant to say "can't" instead of "don't care" on lines 4-5, for instance.

Actually, the staff list that Marc & I looked at is by no means
exhaustive.  Danr, for instance, acts in certain respects as a staff
person, and in fact has root so he can maintain the members list in
/etc/group.  In points past, we've had a publicity chairperson, who was
part of staff but who was almost entirely non-technically oriented.  Ken
Ascher, who isn't on any of those lists, sometimes reboots the system
(after all, it is his warehouse).  So, to some extent, being a "staff
member" is not entirely well defined.

response 22 of 52:

Jan 8 15:08 UTC 1995

I'd quibble that access to the hardware is not the only bottleneck.
We've got a pile of software packages (eg IRC) that need to be installed
or upgraded.

response 24 of 52:

Jan 8 16:43 UTC 1995

   Rane in #10 you asked some questions about staff.  The smartass response
of course, is that staff just materialized out of the air, much like
sourdough.  Hmmm: stafflacocous. ;-)

  The process is, as Marcus said, somewhat ad hoc, and should probably
stay that way.  As people become known to us who are potential staff
vict--um prospects, they are approached.  We might have a new one in
the works now.

  Dan got it right that one of the reasons we're having problems is that
we've grown so incredibly in the last 10 months.  It really has been
incredible too, from this oldtimers standpoint.  Going from 4 new people
on each day to 40 in less than a week for example (last March).

  So we have lots and lots of things to do.  But, and this is a Really
Big But, we can't just add staff to deal with it all.  For one thing, if
we got 6 new staff types on board at once, we'd have *real* communications
problems.  Just because you add more people to a project doens't mean that
things will get any better.  In fact, oft times they get worse.  There is
a wonderful book called _The Mythical Man Month_ that talks about this much
better than I could do.  If you're interested (as in anyone, not just Rane!)
in how projects bog down, this is a classic book.

  The other interesting part is that a lot of what staff does is
unpredicictable, in that we don't know the things are going to rear
up and nip us on the ass in an envoironment like this.  Yes, we have a
definate set of things to work on like 1) pc route box, 2) disk problem
3) news,  but we also have these other little things that pop up, that
look a lot like non-maskable interrupts.  Security issues are one of them,
which we've had to deal with more often than I'd like.

  We should and will add staff here to help cope with all these things;
Marcus's talking about staff up above is right on the mark.  I only want
to see it done in such a fashion that we can abosrb them gracefully and
keep the system of staff communications working as well as it has.  And,
overall, the staff have communicated among themselves better than any
"professional" organization I've ever been a part of.  The number of times
that staff has stepped on each others toes has been rare, considering the
amount of work thats gone on here.

  Someone asked about the amount of time people have spent on the system.
For me, its always at least one hour, and sometimes much more than that.
The figure of 84 hours per week sounds about correct if you are averaging.
But when we've had a real security problem like the one we had last Oct,
that number probably doubled for a while.  So it is really uneven.