Re: On diversity in the NomCom

[Victor Kuarsingh <[e-mail]>]

On Mon, Jul 13, 2020 at 13:29 Tommy Pauly <tpauly=[e-mail]>
wrote:

>
> > On Jul 13, 2020, at 10:16 AM, Christian Huitema <[e-mail]>
> wrote:
> >
> >
> >> On Jul 13, 2020, at 6:37 AM, Stewart Bryant <[e-mail]>
> wrote:
> >>
> >> That is an interesting point, though I am not sure of the specifics of
> the proposal.
> >>
> >> The IETF is very tribal along area lines with too little interaction
> between the tribes. Some consideration of areas of interest would be useful
> in Nomcom so that the special issues that effect the areas are better
> understood by those taking the decisions. Now I know they can ask, but some
> background context helps a lot.
> >
> > I don't think we are that tribal. Look at the QUIC WG happily mixing
> contributions from application, transport and security experts, with
> management also debated. I am sure there are other examples.
>
> >
> > -- Christian Huitema
>
> +1
>
> Lots of the best work we do is spread across the fuzzy boundaries between
> areas.
>
> Areas have changed over the years, and I’d be reticent to see these areas
> institutionalized to the point that people choose “primary” affiliations. I
> certainly wouldn’t want to have to choose an affiliation.
>
> The NomCom talks to the community of contributors in each area, and
> listens to that feedback as the way to determine who is best suited for
> each role.


I would also agree with this position in general.  Folks may clump together
at times - perhaps in ephemeral or long lasting tribes, but I see
significant cross area collaboration, input and work done in spite of all
of this.

In my personal experience on Nomcom, I would say cross area understanding,
over a body of 10 voting members persons, has not seemed to be a limitation
doing the work (speaking also both a chair and a voting member).

The key attribute was that the nomcom knew at least some of the people, and
understood how work gets done (both in person and on lists) to help
evaluate the needs of the roles (considering input from the bodies,
liaisons and the community at large through feedback).  If after all of
that, there is still an issue, the confirming bodies are present to affirm
selections are in line with the community needs.

I am not opposed to diversity in general, but attempting to engineer that
diversity (in a model where randomness is needed), and across N vectors,
seems like a challenge.

If this is the desire of the community, then I would like to know if we
understand the problem statement more fully before trying to engineer a
solution.   With primary affiliation, the problem statement (IMO) is well
understood and is easy to define and action against.  Attempting to group
folks in other categories, of which boundaries change constantly, may not
result in a better outcome.

Regards,

Victor K







>
> Best,
> Tommy
>
>