Subject: RE: Running code

From: David Allan <[email-masked]>
Date: Fri, 20 Sep 2002 15:06:06 -0400

One anti-conspiracy data point. Having been on a NOMCOM, I recommend the
experience to my colleagues, many of which volunteer on that basis.

cheers
Dave

> -----Original Message-----
> From: Donald Eastlake 3rd [mailto:[email-masked]]
> Sent: Friday, September 20, 2002 9:30 AM
> To: [email-masked]
> Subject: Re: Running code
> 
> 
> I have to agree with kre and Brian.
> 
> Working Groups and the IETF don't even have a defined 
> membership but if
> you look at their mailing lists they are normally huge and hard to
> domiante in the public forum of the mailing list. I haven't seen
> anything hard to deal with in attempts to pack a WG and in any case,
> that is something the WG chair can take into account.
> 
> But the nomcom is different. Its small and sensitive and works, as do
> almost all personel seletion processes and hire/fire decisions, in
> private. 3 members with the same affiliation is bad. 4 or more is
> unacceptable for the future.
> 
> It is well known that some companies, due, in my opinion, to the
> misguided transporting to the IETF of the company voting 
> block politics
> that infest so many other standards organizations and which I 
> see every
> IEEE 802 meeting I go to, have strong internal campaigns to get every
> employee who is eligible to volunteer for the IETF nomcom. Such
> campaigns usually state quite clearly that their purpose is to try to
> get as many employees of the company as possible on the nomcom to
> maximize influence.
> 
> Every nomcom I have participated in (2 as a voting member, 1 as chair,
> and 1 as past chair) has informally taking the affiliation of 
> potential
> nominees into account. The feeling was that, say, both ADs in an area
> being from the same organization (company, university, 
> whatever) or too
> many IAB members with the same affiliation would look bad to 
> the outside
> world no matter what. The IAB and IESG have specific defined 
> members and
> the list is public and are scrutinized, for good or ill, by those
> evaluating the IETF. Not that any nomcom has thought there should be a
> hard and fast rule on this, since their might be overriding
> circumstances, but it was a factor taken into consideration by most
> nomcom members. (IAB and IESG members change affiliation also, perhaps
> more than nomcom members due to their longer terms, but there really
> isn't anything you can do about that.)
> 
> Similarly, the nomcom has a specific defined members and the list is
> public. Frequent appearance of bias should be avoided unless such
> avoidance would cause severe problems. With the huge (from a historic
> point of view)  number of eligible volunteers we are getting, a
> restriction on multiple nomcom members with the same 
> affilitation isn't
> going to cause any selection problem at all, as far as I can see.
> 
> 4 nomcom members affiliated with one company is proof that, for the
> nomcom, action should be taken. I'd somewhat prefer a rule of only 1
> voting member affiliated with an organization although a rule 
> of 2 would
> be adequate. To avoid disruption, changes of affiliation should not
> count. All volunteers would be required to give their affiliation and
> that information should appear in the public list of volunteers.
> 
> Donald
> 
> On Fri, 20 Sep 2002, Robert Elz wrote:
> 
> > Date: Fri, 20 Sep 2002 15:17:24 +0700
> > From: Robert Elz <[email-masked]>
> > To: Loa Andersson <[email-masked]>
> > Cc: Brian E Carpenter <[email-masked]>, 
> [email-masked]
> > Subject: Re: Running code
> > 
> >     Date:        Fri, 20 Sep 2002 09:22:06 +0200
> >     From:        Loa Andersson <[email-masked]>
> >     Message-ID:  <[email-masked]>
> > 
> >   | 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
> > 
> > 
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.elistx.com/subscribe>
> > 
> 
> -- 
> ======================================================================
>  Donald E. Eastlake 3rd                       [email-masked]
>  155 Beaver Street              +1-508-634-2066(h) +1-508-851-8280(w)
>  Milford, MA 01757 USA                   [email-masked]
> 
> 
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.elistx.com/subscribe>
>