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

[Dave Crocker <dhc@dcrocker.net>]

Avri,

Nice summary.

Nomcom differs from working group processes in two ways: its deliberations
are closed and the damage likely from reversing the results of those
deliberations is very high. This prompts us to look for ways to make
reversal very, very unlikely. Hence, the nomcom processes need to have more
"surface" objectivity than the usual, open, lengthy incremental IETF
processes.

We rely on the diversity achieve this. That is, we rely on random sampling
to produce a group from sufficiently diverse backgrounds, affiliations,
locations, etc. This will ensure a sufficiently diverse range of agendas and
perspectives. (We are not simply worried about conscious and manipulative
agendas. We are also worried that the group be able to consider things
broadly. Commonality of a characteristic -- like company affiliation --
makes it more likely that people will see and analyze things in a similar
fashion. For a nomcom, this would be problematic.

Unfortunately the selection process must rely on a rather small
"population", namely folks who self-select to offer to participate. (The
pool of candidate nomcom participants is inherently biased, because it is
self-selected and because even as many as 100 volunteers makes for
statistically problematic pool.) So it is not suprising that -- as we have
seen -- the resulting group of nomcom participants is not random enough to
ensure community comfort.

The special nature of nomcom requires that we be proactive and prevent
statistical anomalies, such as too many from the same company.


We need to consider 3 things:

1.  What are the list of attributes that we need to worry about?

    Company affiliation is the one that has surfaced. Are there others?

    Would we be concerned if 8 nomcom members were from Malaysia, or from
    the UK, or from China or from the US? What about having 8 being from
    what, in the US, is called a "protected minority"? What about 8 being
    mathematicians, or being psychologists? (Don't laugh. There are more of
    the latter in the IETF than folks realize. As one of them, I am sure
    that we should worry about it...) What if 8 had never been an editor,
    working group chair, AD or IAB member -- ie, what if we had essentially
    no voting member of nomcom with any real hands-on experience dealing
    with the management process?

2.  What can we do to make randomization better, in terms of the pool that
    members are drawn from and in terms of the mechanism for drawing from
    that pool?

3.  What should be the hard limits, in case the randomization does not work?


Here are my own suggestions, just to offer a starting point for discussion:

1.  Attributes of concern

    Company
    Geography
    IETF management experience.

2.  Randomization

    Use limits to protect against too many from company or geography. Make
    separate selection pools from based on experience.

    Draw from the "experienced" pool first, up to 50% of the nomcom. Fold
    the remainder of that pool into the second, pool and select the
    remaining 50%.

3.  No more than 3 from the same company.

    Use a standard table of geographic region and limit participation to no
    more than 50% from a single region.

d/

ps. This topic quickly gets distasteful. There are some attributes we would
not want to acknowledge are a concern, even if he concern is valid. As a
counterbalance, against this discomfort, we really do need to ask how the
community will feel if nomcom has a very large number of participants with
one of these "interesting" attributes. If the community would be worried
when 8 out of the 10 voting nomcom members had a particular attribute in
common, then we MUST find a way to mitigate against its occurrence.

Sunday, November 10, 2002, 3:33:18 AM, you wrote:
avri> - While the policy of the IETF is that individuals participate
avri>    as individuals and not representatives of their companies,
avri>    it is also accepted that in practice, many participants do
avri>    represent their employer's viewpoints.
...
avri> - If we do something to consider companies as participants in
avri>    this instance, the IETF may need to do something about it
avri>    in a broader sense.
...
avri> -- However, since the nomcom process is not an open process,
avri>     the normal safeguards against collaboration may not operate.


d/
-- 
 Dave Crocker  <mailto:dhc@dcrocker.net>
 TribalWise <http://www.tribalwise.com>
 t +1.408.246.8253; f +1.408.850.1850