Re: Running code

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Fri, 20 Sep 2002 09:22:06 +0200
    From:        Loa Andersson <loa.andersson@utfors.se>
    Message-ID:  <3D8ACC9E.6060300@utfors.se>

  | the normal response to this is "we don't do companies, people
  | act as individuals". While I realize that that the "company aspect"
  | could be important in this context and needs to be fixed, it could
  | have an impact in other contexts as well. If it is fixed here, we
  | need to "fix it" elsewhere, or clearly motivate why it is a problem
  | here and only here.

That one is easy to see.   In (essentially) all other IETF activities,
all is done in the open.   If people who happen to come from the same
organisation start acting in concert to achieve a result (a practice
not totally unheard of, though fortunately not all that common) then
it usually becomes quite obvious, quite quickly, and everyone else can
take that into account - that they're acting together doesn't make their
point invalid, but it does raise some suspicions, so we can be just that
bit more careful.

The nomcom doesn't work like that, all its activities (or all that
matter) are done behind closed doors.   There's no way the community
can tell who is doing what - and whatever we eventually decide the
role of the liaisons is, I certainly can't see that it should be to
report back to the bodies they're from (or the rest of the community)
on who is voting which way inside the nomcom.

Even if we assume that everyone acts in entirely the best interests of
the IETF, and we currently have no reason to assume that anything
different is happening, it can be very difficult for members of the
same organisation where one might happen to be senior, and the others
much more junior, and perhaps not completely willing to oppose their
senior colleague (and note: I know none of the people concerned this
time, and have no idea what their internal dynamics might be).

So, I agree with Brian, this is one that we should be fixing.   A limit
of 2 nomcom members from one organisation seems like it should do no
harm - the random selection of members from the pool of volunteers can
just go on generating more numbers, with any that were picked, but come
from the same organisation as 2 earlier selections being ignored.

Obviously, this to apply to the next nomcom selected, not this one.

kre