On Mon, Jul 13, 2020 at 13:29 Tommy Pauly <tpauly=40apple.com@xxxxxxxxxxxxxx> wrote:
> On Jul 13, 2020, at 10:16 AM, Christian Huitema <huitema@xxxxxxxxxxx> wrote:
>
>
>> On Jul 13, 2020, at 6:37 AM, Stewart Bryant <stewart.bryant@xxxxxxxxx> 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
