ietf
[Top] [All Lists]

Re: Nomcom Enhancements: Improving the IETF leadership selection process

2010-07-24 09:16:13
Jari,

Thanks for the thoughtful comments. With luck, any revisions you make to them won't render the following responses invalid...

On 7/24/2010 10:24 AM, Jari Arkko wrote:
RECOMMENDATION -- Selective Exclusion
I agree in principle that we need this -- for conflict of interest and for
verified breach of rules, for instance. But I fear that implementation is very
difficult

As already noted on this thread, there's a continuing danger of having too many rules and attempting too much precision in the rules. (My own comment is that we are a community that shows far more preference for creating detailed rules than for following even simple ones...)

The team of folks collaborating on this proposal approached the more interesting topics by riding a pendulum. We would swing back and forth for most issues, especially on the axis of specificity. For the Exclusion discussion, that predictably led to thoughts of all sorts of detailed criteria. (To be fair, most topics had that ride.) Luckily, most of the other folks are pretty reasonable and these debates came down on the side of more simplicity, rather than more and more detailed rules.

In this case, simplicity is based on the core fact that exercise of the power to exclude is so daunting, its exercise must be extremely rare and extremely well-founded. Having the rest of Nomcom reverse the chair will be a very big and painful deal. Having it happen more than once on the same Nomcom is likely to be devastating.

So the chair is likely to be careful about exercising this authority, exactly as they should be.

In the face of those forces, we felt that we could leave the rules simple and basic, and leave the details to the folk on the Nomcom at the time.


More worryingly, you wrote later in the text "Reasons for exclusion include,
..., potential for violation of confidentiality, ...". Are you saying that we
should exclude nomcom members not merely based on violation of confidentiality
rules, but also based on predicted, potential future violations? I hope the text
was just sloppily written and that you are not suggesting this, for obvious 
reasons.

Exclusion is not meant as punishment. It is only useful for prevention. Waiting until there is a violation -- assuming that the violation can be detected -- doesn't accomplish that.

Again, the balancing forces, here, are the need to get a job done and to avoid nasty conflict. Exclusion is an act that tends to work against both of these. (Or rather the second invites failing at the former...)


RECOMMENDATION -- Nomcom Tutorials
Agree, though I don't see a big need for keeping them closed.

The dominant view on the team was that closed sessions will make frank discussion more likely. There's a difference between getting information in order to make critical decisions, versus having more casual interest in the topic. Having folks sitting in with only a casual interest affects the tone of the discussion.

Perhaps a simpler way to think of it is that these sessions are likely to include some "interview" content with the instructors. Nomcom interviews are private.


RECOMMENDATION -- Nomcom Expertise Requirement

I have very mixed feelings about this. On one hand I believe that such expertise
is very useful, but I am also afraid of too much self-selection and conservatism
as a result.

I don't understand what you mean.

Making a guess, I'll note that selection of 3 from the second pool was largely based on wanting to avoid having a Nomcom be dominated by the old guard.


 The IETF has many problems, but one issue that I have been
personally worried about is having a sufficient influx of new people.

That was specifically the reason the team chose 3 as the number to recommend from the second pool, rather than more.


Do we have evidence that more experienced nomcom works better than an
inexperienced one? Are there any downsides to choosing experienced members

"works better" would not be language I would choose. The concern is the basis for knowledge, not the style of participation.

Without any experience in IETF management processes, one must resort to abstract theory, which might or might not relate well to reality. As the proposal notes, having too little experience among the voting members essentially requires relying too much on the advisers for basic information about how things work.

As for downsides, the team certainly worried about requiring too many experienced folk. I'd class the worry as matching yours...


Unlike almost all other recommendations in the draft, this one does not address
a current problem.

Unfortunately, yes it does. Some Nomcoms have suffered from too little experience among voting members.


RECOMMENDATION -- Interview Monitoring

I would prefer to see a weaker rule, such as allowing liaisons to ask to be
present in some interviews but not all.

You won't be surprised to hear that this was considered among the team.  At 
length.

The problem is that that means that that defeats the purpose of the rule. Is it ok to have the presence of Advisers create intimidation /some/ of the time?


RECOMMENDATION -- Politicking

For the reasons already stated on the list by others, I think this
recommendation is problematic.

So is the politicking.


Some more detailed comments:
Many participants still are deeply involved in the IETF, but many others are
more narrowly focused, with limited IETF involvement. Often they track only
one working group and contribute to none of its discussion, writing or 
leadership.

I would like to ask for clarification. Did you mean participants who contribute
none to *general IETF discussion* or participants who are in listen-only mode in
their only working group?

The exemplar was describing an extreme.  It meant the latter.

It's not unusual to have regular attendees who do not really participate at all. They attend to observe, perhaps to learn, perhaps to engage in hallway marketing, etc.


This results in volunteers with potentially less IETF experience, less
understanding of IETF culture and less appreciation of the specific strengths
(and weaknesses) of the IETF approach to standards development. Instead, they
bring their own norms, often including a stronger sense of loyalty to other
groups.

This is written in a bit of an us-vs-them style. I think the reality is more
complicated. We might want a particular outsider group to bring their work to
the IETF, for instance. And experience on how well the IETF enables these people
to do it would be very valuable in the nomcom.

The discussion was not about relative merits of different standards groups, nor about the value in working together.

It was only concerned with the effect on a Nomcom from having voting members who do not know IETF culture but do know other standards groups' cultures.

Since we are in the Netherlands, this week, let's try to imagine having a body selecting members of The Netherlands' Parliament, with the body comprising only people with grade-school education in the very different political structure of the United States' version of democracy. Personally, I'd question the competence of such a body.




John,

On 7/24/2010 2:24 PM, John Leslie wrote:
> How can we impose additional
> experience requirements on some NomCom members without implying that
> we want their opinions to be considered "better"?

I've been on 3 Nomcoms. Voting members with experience are typically notable, but those without have yet to show anything I'd call "deference" or "intimidation". On the average, IETF participants are each and all rather independent-minded and painfully unintimidated by folks with extensive experience.

During a discussion among members, being able to cite experience when offering an opinion helps, but I haven't seen anything that looked like inherently preferential position because a member has more experience. Decisions still require making a good case for a position.

d/

--

  Dave Crocker
  Brandenburg InternetWorking
  bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf