Re: NomCom 2006/07: Selection Process Reset

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




On Aug 31, 2006, at 3:27 PM, John Leslie wrote:

Andrew Lange <andrew.lange@xxxxxxxxxxx> wrote:

A few members of the community have expressed concern over two issues with
the selection process for this year's NomCom.

   I'm taking the liberty of responding to the second first.

Second:  A sitting member of the IAB's name appeared on the candidate
list. According to 3777, section 15, sitting IAB, IESG and ISOC members
are not eligible to serve on the Nomcom.  This was an oversight on my
part.  Ordering in the list does matter for the selection process.
Although this person was not selected to serve, and the harm done is
minimal, it is important that the IETF follow our own processes as closely
as possible.

   This is not a good reason to restart the process.

Although the inclusion of an ineligible name does affect the selection, there is no improvement in randomness from restarting vs. eliminating after
the selection is complete.

   Restarting, however, introduces problems:

- an inevitable suspicion that an unhappiness with the result may have
  influenced the decision to restart;
- the possibility that members initially selected may have already incurred
  costs from planning changes necessary for them to serve;
- the likelihood that members initially selected may have made plans which
  may prevent them from serving.

   (I do not, however, challenge the authority of the Nomcom Chair to
restart the process.)

First: The list of volunteers was published later than recommended by RFC 3777. This happened because, after the nominations period closed, there
was some dispute on the eligibility of a number of NomCom volunteers.
They were not on the secretariat's list, but they had attended the
requisite number of IETF's. I chose to provide the secretariat some time
to look into their eligibility...

   Here's our bug!

" 14. Members of the IETF community must have attended at least 3 of
"     the last 5 IETF meetings in order to volunteer.
"
"     The IETF Secretariat is responsible for confirming that
"     volunteers have met the attendance requirement.


There is another bug here - it should say

Members of the IETF community must have registered for and attended at least 3 of...

(Yes, people do sneak in - why should they be allowed to be on the Nomcom ?)

Regards
Marshall


   There is no way to ensure that this confirmation is timely. Nor is
there any practical way to challenge Secretariat records. The Nomcom
Chair must accept their finding (and risk challenge for exclusion) or
give them whatever time they need.

   I strongly recommend that future Nomcom Chairs allow more time for
this.

This resulted in the list being sent to the secretariat later than I
would have liked, and the message then got hung up in the secretariat's
queue.

Again, future Nomcom Chairs should allow more time. RFC 3777 asks for
"
" The announcement should be made at least 1 week prior to the date
" on which the random selection will occur.

   Any plan which doesn't allow three weeks seems unwise...

The selection is still deterministic, because the list ordering algorithm used (alpha by first name) is deterministic. However, since the list was
published late, the appearance is not ideal.

   One must assume that this was the source of the challenge
"
" The first announcement should occur as soon after the random
" selection as is reasonable for the Chair.  The community must
" have at least 1 week during which any member may challenge the
" results of the random selection.
"
" The challenge must be made in writing (email is acceptable) to
" the Chair.  The Chair has 48 hours to review the challenge and
" offer a resolution to the member.  If the resolution is not
" accepted by the member, that member may report the challenge
" according to the dispute resolution process stated elsewhere in
" this document.

   See section 6 of RFC 3777 for the dispute process. I agree that
resetting the selection process is arguably better than starting this
process; but I most sincerely hope we can avoid this problem in the
future.

--
John Leslie <john@xxxxxxx>

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf


_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]