ietf
[Top] [All Lists]

Re: Consolidating BCP 10 (Operation of the NomCom)

2014-09-13 19:07:18
At 07:20 PM 9/13/2014, Joel M. Halpern wrote:
It may (or may not) make sense to examine all of the issues you list.
It seems to me the next thing to certain that the work will not even be 
completed by the time the next nomcom is seated.

Might it make sense to follow the original proposal first, and just ge the 
current procedures as understood documented in one place.  And make sure that 
is correct, before embarking on changes?

As far as I understand, Murray is proposing "no change in effective behavior" 
in the first pass, so whether or not we manage to get an RFC through before the 
next nomcom or not, the publication of a simply updated 3777 is really nothing 
more than clean up without any change in effect to the current Nomcom, nor in 
the behavior of any follow-on Nomcom.  

Given that there's a real cost (can you say Last Call?) to the community as a 
whole for each and every RFC action, I'm underwhelmed at the idea of opening up 
3777 without making a commitment to actually address its warts.

That's a long winded way of saying no.  If there were a pressing need for the 
current Nomcom, I'd suggest they use the "operational discretion" portion of 
the document.  If there were a well understood set of changes that have been 
incorporated in practice, but not in documentation, I *might* say yes.  Neither 
of these appear to apply - hence, "No".

To be blunt, we're already... *sigh* splitting nits about the meaning of 
certain sections, words, word combinations, etc.  I'd really rather not go 
through that more than once every 5 years or so.

Mike





Yours,
Joel

On 9/13/14, 2:46 PM, Michael StJohns wrote:
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/

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>