ietf-nomcom message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-nomcom Home]


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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [ietf-nomcom Home]


Powered by eList eXpress LLC