ietf
[Top] [All Lists]

Re: Consolidating BCP 10 (Operation of the NomCom)

2014-09-13 13:47:30
At 02:09 AM 9/4/2014, Murray S. Kucherawy wrote:
Colleagues,

As part of my work with NomCom '14, I'm preparing a revision of RFC3777 that 
incorporates all of the updates made to it subsequent to its publication ten 
years ago.  This would roll all of the documents making up the NomCom's 
definition and procedures into one place.

The draft is available here:

<https://datatracker.ietf.org/doc/draft-kucherawy-rfc3777bis/>https://datatracker.ietf.org/doc/draft-kucherawy-rfc3777bis/

It is at present nothing more than a republishing of RFC3777 verbatim, with 
some slight organization adjustments that come along with conversion to 
xml2rfc (RFC3777 was done in nroff), and all of the changes made by the other 
documents that currently comprise BCP 10 have been incorporated.  There have 
been no other substantive content changes made.

My plan is to keep it that way for this go-around.  

Hi Murray - 


Until I read the "for this go around" sentence, I was actually hoping someone 
was opening this up for a comprehensive revision.

Here's what I think needs to happen (prior to the next IETF nomcom selection):

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
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 
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.
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].


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. 


Then, if the community would like to actually crack open the document and 
revisit some of the content, that would be a second project (for which I would 
probably volunteer to act as editor).

See above.  I don't think you actually gain anything by splitting this into two 
stages as the text from the roll up revision is going to need to change; going 
through the process - twice - to move revisions to RFC seems to be to be a 
waste of effort.

Mike




Comments welcome.

-MSK, hatless

<Prev in Thread] Current Thread [Next in Thread>