Substantial nomcom procedure updates (Was: Re: Consolidating BCP 10 (Ope

Michael,

Your list is good and worth working on. Thank you!

I do have some comments and questions though.

> 1) Update 3777 to merge in the various changes that have been posted. (this 
> rev)
> 2) Add text to fix the revealed-broken recall process
Remind me what this is about.

> 3) Add text to fill out what constitutes a vacancy.  E.g. 
>     a) Vacancy by term completion
>     b) Vacancy by resignation
>     c) Vacancy by death or incapacity
>     d) Vacancy by recall
>     e) Vacancy by expulsion 
Seems reasonable. What are you thinking of under e)?

> 4) Add text to fix disconnects between what the Nomcom and the confirming 
> bodies believe to be true with respect to:
>    a) what is and is not confidential about a candidate with respect to the 
> confirming body
>    b) what MUST be provided to the confirming bodies
>    c) what MAY be provided
>    d) what must be provided to the nomcom by the confirming body on rejection 
> of candidates (my take, simply the fact of rejection)
>    e) that the rejection of a candidate is NOT a failure of process.
Agree about e). It can be that the confirming body simply has more information. 
And I understand that items a) through d) have been a source of discussion 
between nomcom and the confirming bodies in some cases. However, I am wondering 
if we can specify useful, general rules about what must be provided. Is there a 
working practice that we believe could be taken on?

> 5) [This one is one of my hot buttons, but is somewhat controversial.  It's 
> based  in part on my belief that the "we all participate as individuals, 
> rather than members of company" trope is no longer even minimally true, 
> especially for more recent participants.] Rework the Nomcom selection process 
> to minimize the statistical affects of one or more companies each comprising 
> large portions of the Nomcom volunteer pool. [Statistically,  if a company 
> has 30% of the volunteers, they have an 85% chance of having 2 nomcom 
> members, a 97% chance of having at least 1].
I do think the IETF still has a lot of individual opinion and “best for the 
internet” flavour in it. But we all are coloured by our affiliations and other 
associations. Some to smaller, some to greater extent. Not sure we should label 
the recent participants in this respect any more than others. 

In any case, I agree with your point about needing to shield the nomcom for 
over-extended influence from any particular party. The question is of course if 
there’s anything we can do about it. Do you have a suggestion?

Reading on…

> Item's 2, 3 and 4 are fixes  for events (failures of process) that have 
> happened since the publication of 3777.
>
> With respect to 5 - the text in 3777 is that the selection process should be 
> fair - which is defined to mean:  "
> A method is fair if
> each eligible volunteer is equally likely to be selected." 
> That definition is already broken in that we cap the number of nomcom
> members from any given company at 2 - which means that anyone in a large
> company already has a lesser chance of selection then that represented by
> his portion of the volunteer pool. 
>
> I think we benefit from diversity of opinion, and even more from diversity of 
> experience. I'm concerned that the Nomcom has been at times rather over 
> populated with large company representatives with a related narrowing of the 
> experience pool. 
I’d argue that 2 out of 10 is not necessarily a big problem. But are you 
concerned about that, or are you concerned there might be cases where closely 
associated entities can circumvent the limit of 2, or are you concerned that 
the nomcom volunteers to a too large extent consists of commercial vendors?

There might be ways to tackle some of these issues, but the solutions are 
different depending on which problem you want to address.

Jari

signature.asc
Description: Message signed with OpenPGP using GPGMail