RE: Running code

[David Allan <dallan@nortelnetworks.com>]

Title: RE: Running code

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:dee3@torque.pothole.com]
> Sent: Friday, September 20, 2002 9:30 AM
> To: ietf-nomcom@lists.elistx.com
> 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 <kre@munnari.OZ.AU>
> > To: Loa Andersson <loa.andersson@utfors.se>
> > Cc: Brian E Carpenter <brian@hursley.ibm.com>,
> ietf-nomcom@lists.elistx.com
> > Subject: Re: Running code
> >
> >     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
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.elistx.com/subscribe>
> >
>
> --
> ======================================================================
>  Donald E. Eastlake 3rd                       dee3@torque.pothole.com
>  155 Beaver Street              +1-508-634-2066(h) +1-508-851-8280(w)
>  Milford, MA 01757 USA                   Donald.Eastlake@motorola.com
>
>
> ----------------------------------------------------------------
> To subscribe or unsubscribe from this elist use the subscription
> manager: <http://lists.elistx.com/subscribe>
>