RE: Running code

[Steve Silverman <steves@shentel.net>]

I would like to support both the analysis and the solution proposed below.
Steve Silverman

> -----Original Message-----
> From: Robert Elz [mailto:kre@munnari.OZ.AU]
> Sent: Friday, September 20, 2002 4:17 AM
> To: Loa Andersson
> Cc: Brian E Carpenter; ietf-nomcom@lists.elistx.com
> Subject: Re: Running code
> 
> 
>    
> 
> 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>
> 
>