Re: [Eligibility-discuss] [Gendispatch] New Version Notification for draft-knodel-nomcom-gender-representation-00.txt

["Salz, Rich" <[e-mail]>]

  *   To the extent not having a POV from a specific community is a problem, the chair of the Nomcom has a tool to resolve that - the appointment of a non-voting liaison or advisor.  Yes, this person will not get a vote

It’s nowhere near the same as a voting member, and advisors must be approved by the entire committee.

  *   Reserving a spot on the Nomcom for a member of a given community seems fraught.  …  I would put that general tool of mandatory selection from a community in the category of non-useful.

But this is NOT a general tool of mandatory selection. This draft proposes that future all-male (because let’s be frank, for the foreseeable future that’s the concern here) voting membership doesn’t happen.

  *   On the question of the size of the Nomcom - we've been at 10 since the start.  We've mostly doubled the work load.  It may be time to increase the size to say 15 or 16.

As a recent chair (as opposed to 25 years ago), the scheduling issues alone would be incredibly difficult to manage, and I would oppose this. It might make some things easier: if such a NomCom continued the 75% requirement, 75% of 16 is 12, so it would take FOUR people to oppose a selection, rather than the current three.  I’m not sure that’s much of a difference. But deliberations are likely to take at least half again as long, in order to give everyone a chance to speak.  So overall, it doesn’t seem like a benefit and Brooke’s Law is more likely to apply (https://codescene.com/blog/visualize-brooks-law/ among countless other links).

  *   It's possible for any community to be underrepresented (or for that matter overrepresented) in any Nomcom - that's just how random selection works.    If you want to avoid that, probabilisticly,  you add members of that community to the source pool.  You might still end up with no members from the group, but over time it will balance out.

Or you can decide to tweak the algorithm. If the IETF community feels that it doesn’t want single-general voting for NomCom, the proposal here seems like a very easy way to address that. We have already tweaked it to limit company representation.

I would do is this way:

    while (number_of_same_gender(voters) == 10) {
        x = next_random_pick() % 10;
        delete voters[x]
         votes += volunteers[next_random_pick()]
    }

Still have to figure out how to do number_of_same_vendor().  I would lump “male” and “prefer not to say” into the same, but YMMV.






So a big no on this document and this approach from me based on the existing tools and the fact that the naive algorithm proposed would have some interesting side effects.

If we did reserve a slot and we got to the end with 10 non-community members, I'd go back and randomly select from the entirety of the community member volunteers.  If the selected one was also a member of one of the max-2 orgs I'd randomly replace one of the two members with that person.  If not, I'd pick 1-10 and replace that member even if it reduced one of the max-2 orgs.  This is not a simple algorithm, but is less unfair (probability wise) than the one proposed.

Later, Mike