Re: guidance on avoiding too many people from one company/group

[Donald Eastlake 3rd <dee3@torque.pothole.com>]

On Tue, 12 Nov 2002, Fred Baker wrote:

> Date: Tue, 12 Nov 2002 12:26:23 -0800
> From: Fred Baker <fred@cisco.com>
> To: ietf-nomcom <ietf-nomcom@lists.elistx.com>
> Subject: Re: guidance on avoiding too many people from one company/group
> 
> At 10:24 PM 11/11/2002 -0500, Donald Eastlake 3rd wrote:
> >But the only perceived problem, the only thing there
> >is a consensus on, is to fix the
> >too-many-nomcom-members-from-the-same-organization problem.
> 
> dumb question, for which there must be an obvious answer. I have seen 
> several recent nomcoms with more than one participant from the same 
> company, and I haven't noticed in the outcomes of those nomcoms anything 
> that smacked of corporate bias.

The problem isn't 2, it's 4. The problem isn't any specific nomcom
outcome, it is the appearance of gross bias and the burden placed on
nomcom members by that appearance. With the current pattern of nomcom
volunteering, about 1 out of 20 times, random selection will result in a
nomcom with 40% or more of the voting members from the same
organization. Although I think that with the huge pools of volunteers we
are getting, limiting to one person per organization would be best, I'm
fine with a limit of 2, which appears to me to be the consensus.  That
is, 3 or more is prohibited.

> In this discussion, we're getting into some pretty microscopic cases, 
> presuming for example that everyone who sent in their name now looks at the 
> list coming out, notices that they were the third from their organization, 
> and opts back out, etc. To accomplish that, we need timestamps in the list 
> and some interesting controls.

No. the algorithm given in RFC 2777 and draft 2777bis selects people
from the list in a random way. Everyone has an equal chance of being the
Nth person selected for all N < list length. If no problems arise, the
first ten people selected are it. There are several types of problems
that can happen. Some can volunteer, be selected, and then turn out to
be uncontactable! This has happened. So you have to go to the next
(11th, etc.) selection according to the algorithm. Also, although it
shouldn't happen, if the administrator is a bit slow and there are
disputes, you might have someone with an unresolved status when the list
is posted. In that case, it is much better to include them and, if they
turn out to be disqualified, skip thm if tghey are selected and go on to
the m+1st selection because if you leave them out but then have to
insert them into the list, it totally changes the selection rather than
just changing one person.

What is being suggested is to simply add a rule such that the
administrator, when going through the list of volunteers in the random
selection order specified by the algorith will know that if two people
from an organization have been earlier selected, any further people from
that organization that come up are to be skipped.  There is no need for
time stamps anywhere. No one has every said anything about any volunteer
needing to back out.

> Are we solving a real problem, or one that is merely worried about? If the 
> latter, can we avoid a difficult and complex process to manage it? 

Havinig 40% or more of the voting nomcom from one organization is a real
problem that has happened and will happen again. The rule to eliminiate
this problem is trivial. The overall selection procedure is moderately
complex but we are talking about a very minor tweak to it.

Thanks,
Donald
======================================================================
 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