|
Grex > Coop12 > #194: Motion to encourage staff delegation of responsibility | |
|
| Author |
Message |
| 25 new of 120 responses total. |
gelinas
|
|
response 6 of 120:
| 
Jun 1 03:11 UTC 2003 |
Right. But how is this different from all of the other things the staff
does? Yes, staff *should* keep one another informed, both to prevent
duplication of effort and to make sure that things actually do get done.
I don't *object* to adding an explicit requirement for notification to
this proposal; I simply consider it unnecessary. On the other hand,
the question has been raised, so maybe it is necessary.
|
jmsaul
|
|
response 7 of 120:
|
Jun 1 04:02 UTC 2003 |
<shrug> Just mentioning it. No biggie.
|
carson
|
|
response 8 of 120:
|
Jun 1 06:39 UTC 2003 |
(Eric's on the board, which IMO would be the better avenue for this
proposal. does this really need a member vote?)
|
other
|
|
response 9 of 120:
|
Jun 1 07:08 UTC 2003 |
What's wrong with duplication of labor, in this context? If the job's
not getting done, and suddenly two or four people have been delegated the
responsibility, that's still a whole lot better than none. I think the
additional requirement is extraneous and unnecessary.
I'd like to keep the proposal as narrow and tailored as it is in order to
accomplish its goal. I'm trying to lighten the load here, not increase
it.
|
remmers
|
|
response 10 of 120:
|
Jun 1 17:22 UTC 2003 |
The proposal is pretty close to something the Board passed a few years ago:
Staff Membership - November 16, 1994
------------------------------------
Motion (remmers, srw):
----------------------
Staff with permanent root access may at its discretion grant
specific resources to qualified individuals for the purpose of
performing work that is beneficial to Grex. Examples of such
resources would be write access to selected directories in
order to modify data files or to install software. In the the
event of an emergency, temporary root access may be granted by
any permanent root.
Permanent root access, access to the staff conference, and
access to the "baff" mailing list shall be with the advice and
consent of the Board.
Basically, the motion says that a certain level of privilege requires
Board approval, but short of that, staff may, on its own, appoint
volunteers to do useful stuff and grant them the resources to do it.
Although I support the idea behind Eric's proposal, I don't think
the proposal is needed since the policy is already in place.
(See http://cyberspace.org/local/grex/policy.html for a list of
policy decisions both by the Board and by member vote. Jan
compiled this summary from archive of minutes a couple of years
ago.)
|
jmsaul
|
|
response 11 of 120:
|
Jun 1 21:22 UTC 2003 |
So... why aren't staff just going ahead and doing this, then?
|
gull
|
|
response 12 of 120:
|
Jun 2 12:39 UTC 2003 |
Grexian inertia.
|
flem
|
|
response 13 of 120:
|
Jun 2 18:05 UTC 2003 |
Yeah, I was gonna ask how this proposal was any different from the status quo
in terms of what staff *can* do. I don't think it is.
|
janc
|
|
response 14 of 120:
|
Jun 2 20:32 UTC 2003 |
Well, news to me that Grex staff has that discretion (though I should know
better if I compiled that page). Wow, I see we are also authorized to
institute disk quotas. That's good, because we mean to turn them on on the
new Grex system. If we're quick, we may be able to get that policy
implemented less than ten years after it was passed.
OK, someone should go appoint a partyadm.
|
carson
|
|
response 15 of 120:
|
Jun 2 21:11 UTC 2003 |
(there's certainly several candidates...)
|
jmsaul
|
|
response 16 of 120:
|
Jun 3 00:31 UTC 2003 |
I guess I shouldn't have worried about staff members rushing out and
appointing too many people. ;-)
|
other
|
|
response 17 of 120:
|
Jun 3 02:46 UTC 2003 |
re #10: I think that the policy as worded now is inadequately explicit and
insufficiently encouraging. It is never a bad thing to clearly and
specifically state a policy if you want it to be observed.
|
flem
|
|
response 18 of 120:
|
Jun 3 14:59 UTC 2003 |
I think the real problem here is that staff has too much to do and not enough
time/motivation to do it. This is not a problem that can be solved with a
clearly worded policy.
|
other
|
|
response 19 of 120:
|
Jun 3 16:12 UTC 2003 |
On the contrary, the whole purpose of the proposed policy is to spread that
workload more easily to a larger pool of individuals.
|
cross
|
|
response 20 of 120:
|
Jun 3 17:03 UTC 2003 |
As is the idea of adding more staff members. At least three people,
including myself, have volunteered. I was under the impression that
this issue would be discussed at the board meeting last night. What's
happened with it?
|
gelinas
|
|
response 21 of 120:
|
Jun 3 17:32 UTC 2003 |
Staff is still discussing candidates to present to the Board.
|
aruba
|
|
response 22 of 120:
|
Jun 3 17:41 UTC 2003 |
We discussed the matter some at the meeting. Staff was not ready to make
any recommendations to the board, so we didn't take any action. THe staff
plans to discuss adding new people at its next meeting, which is (we think)
next week.
We also discussed how we could have a better system of mentoring new staff,
so that there is some sensible track toward acquiring the necessary level of
trust. No one had any brilliant ideas on how to go about it. There was a
general consensus, though, that we don't do a good job of it now.
One thing that seemed to be a good idea is to make a list of staff's current
tasks, and known future projects, so that there is something to give new
people to do. Of course, no one wanted to invest the time to make such a
list. But it might happen - some staff member will have to say where we
left that.
|
flem
|
|
response 23 of 120:
|
Jun 3 18:14 UTC 2003 |
re resp:19 - allow me to clarify. The problem, as it relates specifically
to non-essential maintenance tasks that do not require root access, is that
because staff is busy, it doesn't get around to appointing other less busy
people to to those non-essential non-root tasks. It's not because they're
not allowed to, or because they aren't "encouraged" to, it's because they're
too busy. Hence, the proposal in #0 will not change the status quo at all.
There are two things that I think we can do that will actually improve the
status quo at this point:
1) Someone make that party channel already, so that at least the
immediate issue will be less pressing. Or make Eric or someone
else a partyadm, or whatever.
2) Wait for staff to have a staff meeting and possibly recommend new
staff members, or at least have a somewhat better idea of how to go
about adding new staff members.
|
other
|
|
response 24 of 120:
|
Jun 3 22:29 UTC 2003 |
I definitely did not get that the staff don't have the time to delegate, but
rather that there is not currently the common perception that staff may
actually do so at their discretion. The discussion revealed that such used
to be the case, doesn't seem to be now, and that there is no good reason why
it shouldn't be that way again.
|
flem
|
|
response 25 of 120:
|
Jun 4 15:45 UTC 2003 |
Hmm, that's not exactly the impression that I got from that discussion, but
I'm having a hard time articulating in what way my impression differs.
I think everyone is in agreement that it would be a Good Thing if staff
delegated responsibility for certain maintenance tasks, such as party channel
administration, at their discretion. That's not in dispute. Furthermore,
it seems pretty clear that, in light of the resolution remmers posted above,
staff is at liberty to do so right now. The fact that this does not seem to
happen is arguably a problem, but -- here's my key point -- I don't think the
proposal under discussion will help to solve that problem.
|
carson
|
|
response 26 of 120:
|
Jun 4 17:29 UTC 2003 |
(so, what happens if this proposal goes up for a vote and is defeated?
would that invalidate the previous policy, which it largely duplicates?)
|
other
|
|
response 27 of 120:
|
Jun 4 18:00 UTC 2003 |
No. We don't have that kind of precedental system. The vote on a proposal
is exclusively on the proposal as worded at the time of the vote.
|
jmsaul
|
|
response 28 of 120:
|
Jun 5 00:39 UTC 2003 |
Why doesn't some staff member just go ahead and appoint a partyadm?
|
jp2
|
|
response 29 of 120:
|
Jun 5 00:57 UTC 2003 |
This response has been erased.
|
janc
|
|
response 30 of 120:
|
Jun 5 02:31 UTC 2003 |
I've proposed that we have a staff meeting real soon, with the discussion
of staff candidates as a top priority and with the discussion of
the new Grex as the second priority. We didn't get a date set yet.
Someone needs to give that process a kick in the rear - see if we can
get a decent number of people to agree to a date.
Why don't I go out and appoint a partyadm? Well, there were three
or four candidates, and I'd probably have to think of a good reason
for choosing one. I don't have the brain space for that right now.
Aside from a whole lot going on in my life, and some amount of stuff
going in in my work, I'm putting in a lot of hours on the new Grex.
I don't want to deal with this too.
Probably there is a systemic problem here too. Most staffers like to
do some talking to other staffers before taking any action in an area
that isn't in their usual area of operations. This is in principle
a good thing. The problem is that not many staffers are very good
at communicating these days. Some don't read the staff conference.
Some don't read the staff email (I just recently discovered the my
staff email was broken, so I'm not innocent). Staff meetings are no
longer frequent. So, to a large degree, we can't talk to each other.
So we are reluctant to make any decisions.
We should have a staff meeting. If only we could talk to each other
enough to pick a meeting time.
Maybe we need to reinstitute regular staff meetings. Maybe we need
a "chief of staff" whose job is to talk to all the other staff people
and keep communications working. Or an alternate title might be better -
"Grex catherd" maybe.
|