Re: Challenge: was Re: Updated Nomcom 2020-2021: Result of random selection process

[Toerless Eckert <[e-mail]>]

On Fri, Jul 10, 2020 at 06:58:39PM -0400, Michael StJohns wrote:
> > This puts the determination of how to proceed in the hands of the chair.
> >  She is not required to roll back the clock to simulate a situation in
> > which Luigi Iannone had filled in the volunteer form correctly.
> 
> You're mischaracterizing what happened I believe.  Luigi was always a Huawei
> employee, but the chair did not have that information.  Once the chair had
> that information, the results of the selection process needed to be
> corrected so they were based on reality - Note: not "changed".

I am not going to ask you again to provide evidence, e.g.: text from RFC
that says what you write because you already did not do this when i asked
for it in my first mail on this subject. Instead, i will just state my
opinion:

I think what you write is your opinion, and you are not providing evidence
that what you write is an actual rule. Yoav did provide evidence by
citing relevant RFC paragraphs.

> The whole process is designed to eliminate discretion from the selection
> process.   While I agree that the document says the above, it does not mean
> that the chair may take any action they choose.

In my reading of the RFC paragraph cited by Yoav, it does not support
that opinion of yours.

> E.g. there were three
> Huawei members - what if she kept Luigi and Tal and got rid of Xuesong?   We
> still end up with two Huawei members.

And your point being ?

>  In any event, you need to look at more than just the above.
> 
> The correct path is to take the list from all common knowledge and work from
> there.  And that list built from the common knowledge (the volunteer list,
> plus associations plus the random seeds) has Luigi on it and Tal off of
> it.   Per
> 
> >     It must be possible to repeat the selection method, either through
> >     iteration or by restarting in such a way as to remain fair and
> >     unbiased.  This is necessary to replace selected volunteers should
> >     they become unavailable after selection.
> 
> and
> 
> >     If a single voting volunteer position on the nominating committee is
> >     vacated, regardless of the circumstances, the committee may choose to
> >     proceed with only nine voting volunteers at its own discretion.  In
> >     all other cases, a new voting member must be selected, and the Chair
> >     must repeat the random selection process including an announcement of
> >     the iteration prior to the actual selection as stated elsewhere in
> >     this document.
> 
> If Luigi declines to take the position, "the chair must repeat the random
> selection process" or work with 9 members.   In general, that's meant
> continuing down the list, not going back and picking up someone who was
> already not selected.

   rfc3797

   The best way to handle this is to maintain the announced schedule,
   INCLUDE in the published pool all those whose eligibility is
   uncertain and to keep the published pool list numbering IMMUTABLE
   after its publication.  If someone in the pool is later selected by
   the algorithm and random input but it has been determined they are
   ineligible, they can be skipped and the algorithm run further to make
   an additional selection.  Thus the uncertainty only effects one
   selection and in general no more than a maximum of U selections where
   there are U uncertain pool members.

   Other courses of action are far worse (refer to the RFC for the why...)

> > I believe she has made such a determination, and has acted within the
> > mandate of RFC 7437.
> 
> Luigi indicating he works for Huawei restructures the list and eliminates
> Tal.  Luigi indicating he won't serve triggers 5.7. These are two separate
> events.

I don't think the period for complaints is over, so the nomcom is not
officially enacted yet, which makes 5.7 irrelevant i think. I may be wrong.
Even when i am wrong, i am not sure why you say 5.7 is in play here.

Cheers
    Toerless

> This is not ambiguous.
> 
> Mike
> 
> 
> 
> > 
> > Yoav
> 
> 
> 

-- 
---
[e-mail]