andyv
|
|
News about staff test :-)
| 
Jan 9 03:20 UTC 1995 |
The following article was built from excerpts on Grex by Andrew Valentine,
(andyv).
STAFF INFECTION UNDER CONTROL?
A LITTLE HISTORY
by Rane Curl (rcurl)
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?
by Greg Cronau (gregc)
1.) Yes, pretty much. Except for maybe 1 or 2 other masochists like myself
who happened to know the wrong people.
2.) Um, M-net is still functioning. Well, we could tighten up all the
rules on Grex to create a heavily fascistic system and several staff
might leave in disgust and start another system.
But seriously, my observation is that the driving force behind the
creation of Grex and the banding together of it's original staff came
from a common disgust with the Current-state-of-things, and a desire to
make something better. How do you recapture the fervor of a revolution?
Not easily, if at all. No, I think the original mechanism no longer applies
and something new must be found.
by Dan Romanchik (danr)
My observation, as a non-staffer, is that the reason 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.
by Marcus D. Watts (mdw)
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.
by Marc Unangst (mju)
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.
by Marcus D. Watts (mdw)
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.
ARE YOU A POTENTIAL STAFFER?
by Steve Weiss (srw)
There are also important support functions performed by people who do not
have root access. I think these people should be considered staffers,
as well. Our webmaster, carl, and chief helper ("guide-father") robh
come to mind, but there must be others.
I am an example of one who became a staff member. Initially I had
no knowledge of Grex or Unix systems. I became a Grex user, and started
learning Unix because my job required it. I have a very strong
software background. I decided that I wanted to install some new
software on Grex, and wound up talking to the staff about it.
With a little help, I managed it. Then later, when they were in a pinch,
they asked if I would look at newuser, which needed some changes. I agreed.
In order to test newuser changes, I was granted root access.
Since then I have learned to perform more and more functions.
The whole process was gradual, with the occasional rite of passage
(e.g. getting root). It can be done, but not in a hurry.
I still don't build kernels, but Grex doesn't really need me for that anyway.
GETTING SOME ACTION
by Marcus D. Watts (mdw)
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.
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.
by Valerie Mates (popcorn)
We've got a pile of software packages (eg IRC) that need to be installed
or upgraded.
by Chris Bartlett (bartlett)
I would like to propose that some time after the move, we organize a
meeting of people who would like to become staff members. At this
meeting, we could figure out what needs doing, who can do it, and who can
teach everyone else how to do it. I'm anxious to help, but my experience
with Unix is limited to shell account stuff, i.e I've never wandered
around in the inards of a Unix system, but I'd love to learn, and I have
sufficient free time in big enough blocks that I could contribute to staff
time.
|