Staff Conference

Jan 28 17:15 UTC 1996

I'm shifting the following discussion of changes to the staff conference
out of item 135, since I think it needs an item of its own.

-----------------------QUOTED FROM COOP #135--------------------------------

#261: by Mary Remmers (chelsea) on Sat, Jan 27, 1996 (08:06):

[...]

 But, I am starting to see a valley here between staff and users. I've seen
 this develop before, elsewhere, and I think it can be minimized by a
 couple of little changes.  Maybe. 
 
 (And this is where I get flamed)  ;-)
 
 The staff conference was meant to be for discussion of security issues.
 That's how it was initially drawn and why it was considered necessary
 it be a private conference.  It shouldn't really be a place where
 policy is pre-discussed (with non-staff Board members present) before
 giving it a whirl before the users.  It shouldn't be a place where
 staff discusses *anything* but system security matters.  Period.  So I'd
 propose the private staff conference be renamed the security
 conference, only staff have access (not non-staff Board members)
 and that the prompt which normally states, "Ok to enter this item?"
 is replaced by, "Is this a security issue?".
 
 Now, there is a whole lot of other non-security stuff that staff
 needs to communicate, and I suggest that go into a staff conference
 that is either totally public or at least readable by the public.
 I don't suspect too many people are going to want to keep up on a
 "What I did" staff log, but who knows?  Anyhow, that way the users
 can see what staff does with all their hard work.  There is less
 of a question of what staff does in private.  There won't be an
 appearance of secrecy.  And maybe, just maybe, we'll head-off some
 of the slowly growing sense of division between staff and users.
 
 I wish we'd set it up like this from the first.

#263: by TS Taylor (tsty) on Sat, Jan 27, 1996 (13:02):
 thankxx chelsea, that's an idea i can live with rather well. 
   
 any other takers?

#264: by Jan Wolter (janc) on Sat, Jan 27, 1996 (14:00):
 I need to think about it.  I've been campaigning (mildly) for some kind of
 public staff conference for a while.  I see a need for several kinds of
 things:
 
    - A completely private place to discuss security issues.
 
    - A place where only staff can post.  We maintain a "What I did" item in
      the staff conference where we post descriptions of about every little
      thing we did to the system.  Most of it is really boring, but it is
      helpful for staff to know what other staff are doing.  Keeps us from
      stepping on each other's toes too much.  If we tried to do that in a
      public conference where anyone can post, however, I'm afraid that very
      quickly some little "What I did" topic would spin off into some huge
      discussion, and swamp out the "What I did" item completely (we have
      small bursts of that as it is).  This could badly undermine the
      usefulness for such items in the communication between staff.
 
    - A public place where specific technical issues on Grex hardware and
      software can be opened to general discussion, with all welcome to
      participate.
 
 But though I see these three different catagories of items, I think three
 conferences would be one too many.  I'd be inclined to stick with just
 two, and leave things like the "What I did" item in the private conference.
 This isn't ideal, but I think it may be the next thing to try.

#265: by Valerie Mates (popcorn) on Sat, Jan 27, 1996 (15:00):
 Historically, overall, I'd say the staff does very well at minimizing the
 discussions about non-security things in the staff conference, and keeping
 those discussions here, in co-op, where they belong.  Lots of topics briefly
 crop up in the staff conf, and end abruptly, after very few responses, when
 someone says, "This really belongs in co-op."  At that point, the discussion
 moves to co-op and is discontinued in the staff conference.
 
 However, in the last 6 months or so, I've seen a steady increase in comments
 like, "I should enter this in co-op but it's not a very important issue and
 I fear it will be flamed to death there by some of our, um, more vocal
users."
 
 In other words, some of our regular co-op conspiracy theorists are scaring
 off the very types of discussions they'd like to see in the open.  This
 worries me.  I'd really rather see those discussions held here.
 
 (Also in the last 6 months or so, we've gotten a bunch of new staffers, some
 of whom have entered items that might better have been better put elsewhere
 than in staff.  They'll learn.)
 
 One other concern I'd like to see addressed is privacy issues.  For example,
 if a user manages to need 7 password resets in a row, or botches a .login
 file, or does some other boneheaded thing, should that be posted in public?
 I dunno.  I don't think I'd personally mind having it announced if I needed
 my password reset 7 times in a row, but I could see where other people might
 not want that kind of information posted publically.

#266: by Steve Weiss (srw) on Sat, Jan 27, 1996 (20:57):
 I definitely think that the "what I did" item belongs private. It names all
 kinds of users names and it would serve no purpose to make it public.
 On the other hand, I just entered an item in the staff conference about 
 progress on the terminal server (now that we might make some progress there)
 and while it might have a few security issues around the edges, is mostly
 material that would do no harm to be viewed publicly. It would be great to
let
 the public see that item, but how can I do that? I can't afford to have
 it be anywhere that non-staffers can post, so until we implement a
 conference that can be read-only to the public I don't see how to do that.
 
 We have been filling in the public on the Sun-4 in a separate item in coop
 rather than providing access to the staff item, because we need that item
to
 communicate among ourselves. I think staff does a bad enough job of
 communicating amongst itself that anything which is detrimental to that would
 do this system a disservice.

[...]
#267: by The Dharma Bum (kerouac) on Sat, Jan 27, 1996 (21:30):
   prevoius message...SRW, what do you mean it would do no harm for the
 public to see the item you refer to, but it would do harm if they
 posted their thoughts?  I dont know what purpose security wise a read-only
 open staff related conf could serve?  If this is information that
 is safe to show publicly if edited right, what harm does it do to you,
 grex or the issues involved if people are allowed to post their own
 comments about it?  A read only conf to display such items would be a
 silly act of paranoia...

#268: by The Dharma Bum (kerouac) on Sat, Jan 27, 1996 (21:34):
    Also there's no point to having a read only conf, for the purpose of
 posting items but preventing discussion, because anything posted there
 worth discussing would be brought up in one of the other confs.

#269: by Valerie Mates (popcorn) on Sat, Jan 27, 1996 (22:49):
 Ja, I could definitely see putting the terminal server item in co-op,
 or possibly in some new conference like what Jan suggested elsewhere,
 where technical details about the system are discussed.  A regular
 conference that everyone can participate in.

#270: by Rob Argy (ajax) on Sun, Jan 28, 1996 (02:03):
   Kerouac, the idea behind the "what I did" item being read-only is just
 to keep drift down.  If people wanted to make separate items to discuss
 issues raised there, that would be fine; it wouldn't detract from the
 function of the "what I did" item.
  
   *If* the item were made publicly read-only (and I doubt it will be),
 a companion item to publicly discuss the first item could be entered.

[...]

#271: by Steve Weiss (srw) on Sun, Jan 28, 1996 (03:04):
 The harm comes from the staff's need to communicate with each  other.
 We use the staff conference to help coordinate our activities. I don't care
 if people want to read some of that stuff. I certainly don't mind my
 communications with Scott and others regarding the terminal server being seen
 publicly. We're working on figuring out when we can meet. This does not
 require limited visibility. It would fail to function as a way for staff to
 coordinate if it filled up with comments from non-staffers.
 
 It's very simple. We'd resort to mail if that happened, and we'd lose another
 useful tool. I have no objection to someone copying out what's there. I'm
not
 trying to hide anything, but I've got work to do and resent impediments to

 getting it done. 
 
 AFAIC the "what I did" item is way off limits for public view. 
 So is linking items with the staff conference.
 
 (I'm feeling grouchy, I guess.)

#272: by Rob Henderson (robh) on Sun, Jan 28, 1996 (11:43):
 No, I'm definitely in agreement on the "What I Did" item being
 kept private, simply because of the embarassment factor involved.
 I know I'd feel horrible telling a staff person that I'd forgotten
 my password if I knew that this fact was going to end up in an
 item in Co-op.  "Hey, robh forgot his password AGAIN!  HA ha!"
 Or that I'd accidentally deleted a file, or messed up my .login so
 I couldn't log in, etc.

response 2 of 110:

Jan 28 18:58 UTC 1996

Wow, you mean if I delete a file by mistake I can ask staff to bring
it back for me?

response 4 of 110:

Jan 28 20:27 UTC 1996

   Something else to point out.  I've recently discovered that there
are people who are reading the conferences via reading the raw files
from /bbs.  I saw someone who's been testing the locks here do that
a couple of times now.  I have no idea how many people do this, but
it certainly is a low-impact way of reading a conference, and in such
a way as to be almost undectable.  So the participant command, or
counting the number of .cf files isn't quite as accurate as I'd thought.

response 6 of 110:

Jan 28 21:16 UTC 1996

There is plainly an issue about what is and is not "security-related".  I
don't think we are going to be able to write a rule for that, nor are we
going to get all the staff to see eye-to-eye on it.  I'm sure some staff
will enter things in public that other staff are less than completely
comfortable with.  Personally, I'd be comfortable with, for example, a
verbal description of how the sun-4 kernal blocks work and what they test
for, but not the actual source code for the kernal blocks.  There is very
little I'd want to keep secret about the shadow-password system (it is, after
all, a publically available piece of code), but I wouldn't hand out source
to our local changes to it.

I do realize how often people "test the locks".  I don't particularly approve
of such activities, but it doesn't alarm me either.

Consider Star Trek.  Captain Piccard's Enterprise is a puzzling ship.  It
claims not to be a ship of war, but a ship of exploration, diplomacy, and
discovery.  True, in spite of this official mission, it is well enough armed
to be a fair match for ships that are ships of war.  The thing definately has
teeth.  But it is, in fact, not operated as a warship.  When approaching
strangers, they do not immediately raise shields, but wait for some hint of
hostile action.  They carry the families and children of the crew aboard.

On the surface this seems insane.  After all, the ship comes within a hair's
breadth of being destroyed every other episode or so.  They could hardly be
in any more danger if they *were* a warship.  Only a fruitcake would want
their children aboard that thing.  Why doesn't Piccard ever learn to raise
his danged shields sooner?

But there is, in fact, some sense to it.  If they let their behavior be
dictated by their fears they would have to surrender their ideals.  If you
hope to discover friends, you can't approach people with suspicion.  It
takes courage and self-confidence, but if it doesn't get you killed, it
can pay off many times over.

The whole Grex ideal doesn't make objective sense.  We shouldn't let people
on without validation.  We shouldn't let them on for free.  Doing so is
either incredibly stupid, or incredibly brilliant.  We have to be careful
to avoid letting fear nibble away at our openness.  We have to consciously
and consistantly push the envelope on how open we can be, in order to
balance our natural and unconscious urge to close up and close ranks in the
face of unknown dangers.

Yes, lots of people test our security in various ways.  But (1) most of them
aren't really very hostile, (2) most of them aren't really very smart, and (3)
we're pretty sharp about setting things up right in the first place, and
responding effectively to problems.  We need to have the courage and
conviction in our ideals to not allow these pathetic people to drive us into
taking a predominantly defensive stance.

response 8 of 110:

Jan 28 22:19 UTC 1996

     Query:  Maybe a solution, if this is technically possible, would be to
offer an edited "read-only" version of the staff conf.  This could be called
"staffpublic" and would allow for items from "Staff" to be linked over,
and offered for public view, but would also allow the fws to have editorial
control over what items from "staff" are seen.  Any material deemed to
be a security risk could either be deleted from the item in question, or
the whole item could be flagged and not linked.  If a response to a linked
item reveals sensitive info, it can be expurgated from "staffpublic", or
if the drift becomes dangerous, the "staffpublic" version can be frozen.

By making "staffpublic" readonly, it ensures the conversations will still
be entirely among staff.  This seems like a fair compromise and would help
limit any unneccesary suspicion and paranoia about staff activities.

response 10 of 110:

Jan 29 00:00 UTC 1996

I'm not, but I think I've always been in the minority opinion. 8)

response 12 of 110:

Jan 29 02:04 UTC 1996

   If I seem touchy, I'm sorry.

   I just see that we're going to A) make more work for staff here
by making "open" things for people to read and/or B) we're going to
let something slip becuase of this and really screw ourselves over.

response 14 of 110:

Jan 29 07:39 UTC 1996

I favor a closed staff cf in which they discuss and coordinate their staff
activities. I also favor an open "garage" ("shop"? - some heat would be
nice in winter), for most system hardware discussions. I have no problem
whatsoever with some security for the space in which personal and security
issues can crop up unexpectedly but necessarily. Its a small price for a
large benefit - and staff members are sensitized to not getting far into
discussion that should be in an open cf - "take it to coop" is said many
times. 

response 16 of 110:

Jan 29 08:33 UTC 1996

I have no objection to a garage conference, either. Only time will tell
whether it is useful, but that is true of any new conference.

response 18 of 110:

Jan 29 12:34 UTC 1996

When hardware/system issues have come up in coop - which happens more often
than this discussion might suggest - staff members have not been slow to jump
all over each other's suggestions.  I think that trying to separate purely
technical issues from policy issues by putting them in another conference is
probably a really good idea, but I foresee a lot of trouble making it actually
work that way.

I'm also concerned about the tendency for seemingly innocent technical
discussions to sprout security-issue branches, but I think staff can handle
that well enough.

response 20 of 110:

Jan 30 12:08 UTC 1996

I very much agree with Jan's assessment in response #15.  This discussion
in not intended to be a slap of staff's hand.  Not at all, but if it's
taken that way that would be a real pity, because there is an opportunity
here to take a larger look at what we started out to do and whether 
we've done it right.  I'd sure hate to see defensiveness get in the way.

Grex prides itself on being democratically run, with as much of the inner
workings made available as possible, and welcoming of user participation. 
Great concept.  And how we structure the thing should work toward that
goal if we're serious about the mandate.  The staff conference as it's now
set up relies on the staff and Board to constantly be policing themselves
and each other to prevent drift into policy issues and discussion of
people and politics that really don't belong in a private conference. 
Now, we all know how drift happens, innocently, without malice.  It's
probably impossible to stop entirely, but in the case of the staff's need
for private security discussion the system could be changed some to
facilitate this yet come even closer to the goal of an open, co-operative
administration. 

I'd change the Staff conference to the Security conference, changing
prompts to serve as reminders and maybe minimizing the need for staff to
keep each other consistently in line.  Everything that's not clearly
security related should go into a read-only public conference called
staff. 

The issue over "What I Did" type items is maybe overblown.  I don't really
see it as a humiliation issue requiring secrecy when staff resets a user's
password, or fixes a mail problem, or whatever.  Would users
mind this information being readable?  Have we asked them?  But no matter,
is it critical for the names to be mentioned in the item?  I mean, *really
critical*?  Staff is a bright group and I bet there would be a way around
this if they thought the goal was worthwhile.  If it was something they
wanted to do.  

*Discussions* regarding specific users (unrelated to security issues)
simply don't belong in a private staff conference.  If it's a specific
behavior being discussed, then talk about the behavior and don't use
names.  That too is good policy.  And if the discussion is about unwelcome
behaviors and what's appropriate intervention then, as with all items
in the read-only conference, if anyone (staff or user) wants two-way
discussion, an item is entered in co-op. 

There is concern over publicly readable discussion slipping into security
issues.  Well, I trust the staff to not enter security issues in a
publicly readable conference.  That they would take to the security
conference.  I don't see the issue here.  Again, the overall structure
should favor openness instead of secrecy - one of our highest priorities. 

I'm stumped to come up with a compelling reason, again in light of our
goals, to have non-staff Board members participating in private
administrative conferences.  If the staff wants Board input on security
issues they go into private session at a Board meeting and ask for policy
direction.  All other Board business should be done in public.  That
too is simply good policy.  If the staff conference is made readable then
non-Board staff would be able to read it like anyone else who was
interested.  Non-staff Board members shouldn't have posting privileges in
a readable staff conference and shouldn't have access at all to the private
security conference. 

Had this type of structure been put into place long ago I believe staff
would have functioned just fine.  Folks wouldn't now be seeing this as a
punitive move.  There would have been more of a natural division of
responsibilities between staff and Board.  Users (and staff) could have
benefited from sharing more information on how Grex works.  And, most
important of all, what we say we want from Grex - openness, user input, a
minimum of secrecy and cliquishness - would be backed up by our policies,
even if that takes a little extra effort. 

My 2 cents.

response 22 of 110:

Jan 31 07:34 UTC 1996

It is absolutely essential for the staff to identify to each other what they
have done in extremely specific detail. this necessarily involves identifying
users and reasons, etc. This information should not be made public. It
currently appears in the staff conference, and that is where I believe it
belongs. If staff is denied that vehicle for that communication, then I
believe staff will use mail for that purpose, which would be a big shame, IMO.

I agree with most of the rest of what Mary said, though. Including not seeing
any real benefit of the board being able to read that conference. I don't
think it does any great harm, though.

response 24 of 110:

Jan 31 14:15 UTC 1996

  I've always thought that staff as a whole answered to the board.