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

[Michael StJohns <[e-mail]>]

For later reference:

This is the binomial probability table for the selection of Nomcom 
members.  The probability is based ONLY on the proportion of a 
particular population within the volunteer pool.  For example, if 
Unicorns make up 20% of the population, the probability of having 
exactly one unicorn member of the Nomcom is 26.8%.  The last two columns 
are "At least 2" and "at least 1", so having 20 percent of the pool 
leads to a 62.4% of at least two members (which would be capped at 2) 
and an 89.3% of having at least 1 member.  Roughly speaking having 25% 
of the pool gives you  about a 1 in 20 chance of not having any 
members.  15% of the pool gives you a 1 in 5 chance of not having any 
members.

Each of the cells is "=BINOMDIST(numOfSelectedMembers, totalMembers e.g. 
10, percent of pool)" - so =BINOMDIST(2,10,.01) yields .4%.  The >= 
cells are the sums of the columns from N to 10.



	
	
	
	
	
	
	
	
	
	
	
	
	
	Number of Nomcom Members 	
Percent of Volunteer Pool 	0 	1 	2 	3 	4 	5 	6 	7 	8 	9 	10 	>= 2 	>=1
1.0% 	90.4% 	9.1% 	0.4% 	0.0% 	0.0% 	0.0% 	0.0% 	0.0% 	0.0% 	0.0% 	0.0% 
0.4% 	9.6%
5.0% 	59.9% 	31.5% 	7.5% 	1.0% 	0.1% 	0.0% 	0.0% 	0.0% 	0.0% 	0.0% 	0.0% 
	8.6% 	40.1%
10.0% 	34.9% 	38.7% 	19.4% 	5.7% 	1.1% 	0.1% 	0.0% 	0.0% 	0.0% 	0.0% 
0.0% 	26.4% 	65.1%
15.0% 	19.7% 	34.7% 	27.6% 	13.0% 	4.0% 	0.8% 	0.1% 	0.0% 	0.0% 	0.0% 
0.0% 	45.6% 	80.3%
20.0% 	10.7% 	26.8% 	30.2% 	20.1% 	8.8% 	2.6% 	0.6% 	0.1% 	0.0% 	0.0% 
0.0% 	62.4% 	89.3%
25.0% 	5.6% 	18.8% 	28.2% 	25.0% 	14.6% 	5.8% 	1.6% 	0.3% 	0.0% 	0.0% 
0.0% 	75.6% 	94.4%
30.0% 	2.8% 	12.1% 	23.3% 	26.7% 	20.0% 	10.3% 	3.7% 	0.9% 	0.1% 	0.0% 
0.0% 	85.1% 	97.2%
35.0% 	1.3% 	7.2% 	17.6% 	25.2% 	23.8% 	15.4% 	6.9% 	2.1% 	0.4% 	0.1% 
0.0% 	91.4% 	98.7%
35.3% 	1.3% 	7.0% 	17.2% 	25.0% 	23.9% 	15.7% 	7.2% 	2.2% 	0.5% 	0.1% 
0.0% 	91.7% 	98.7%

	100.0% 	8.3% 	25.4% 	50.4% 	74.4% 	90.1% 	97.2% 	99.5% 	99.9% 	100.0% 
100.0% 	
	





On 11/24/2023 1:13 PM, Salz, Rich wrote:
>
>   * 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.
>
By a majority of the entire committee actually.   And given the already 
large number of liaisons relative to the overall size that means you 
only need a few voting members along with all of those to add an advisor.

And given how much participation those liaisons and advisors had in my 
last go round as a Nomcom member I'm not worried about the non-voting 
aspect of it.  Or are you trying to say that a single mandatorily 
selected voting member has some sort of super powers to get their way?

>   * 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.
>
*And that's where this runs off the rail.  If because of diversity, it 
is in our interest to guarantee at least one non-male as a voting 
member, why - also considering diversity - wouldn't it also be in our 
interest to guarantee at least one from Asia, North America and Europe?  
Do we also consider Africa, and South America in that grouping and 
reserve a slot for each?  Next do we look at the various age bands  - 
again in the service of diversity -  <35 (because youth and energy are 
the future of the IETF), >60 (because we've already made the mistakes 
that we don't want the Nomcom to make again) to make sure we have those 
communities represented?*

*When is a community too large or too small  or not special enough to 
require special treatment to perturb the math?*

I haven't done the math of non-male-percent-of-pool, and Mallory's 
document hasn't describe the actual problem with doing things the way we 
do them but addresses only a single point result.  From an email I saw 
on the gendispatch thread, of the last 5 nomcoms or so only one got us 
to the point of not having a voting female member.    So I'm unclear 
what defends the need to do something special for what appears to be an 
outlier.

I don't have the time to go back and review the volunteer list and guess 
at genders, but there's a pretty simple formula that explains the 
expected outcomes given an input pool and selection criteria (table 
above). If you can figure the expected result, you can figure out how 
many sigmas this last Nomcom was off from the expected result using 
various criteria.  Notably we do not capture anything in the selection 
algorithm other than organizational association - but that hasn't been a 
problem to this point AFAICT.


>   * 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).
>
Good on you for denigrating my Nomcom chair stint... didn't really need 
to be done I think.   And if you've actually had everyone offer an 
opinion on every candidate - including all of the non-voting members - 
no wonder things are taking so long.   My most recent member stint was 
about 8 years ago and it was rare to have extended conversations about 
all the candidates - especially on the IAB selections.  We generally had 
a good idea of ordering fairly early, and were mostly arguing about 
those at the border between selected and non-selected.

What took a lot of our time and scaled proportional to the number of 
vacancies was the set of interviews we needed to do, not as your 
experience suggests, discussion about the actual set of candidates.

So your empirical results and my diverge at that point and I believe 
having a few more people to do the interviews of the various candidates 
would be helpful rather than burdensome to the process and completion 
thereof.


>   * 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.
>
And that algorithm is set up to mostly guarantee large companies 
overwhelming representation on the Nomcom each year.  That is not a 
feature in my book.

Nor is this "simple" proposal.  Keep in mind Mallory's suggested process 
runs *after* the selection of the first 9 slots.  Say - as is usual - 
three companies already have 2 members by that point in the selection.  
Not a single special selection will draw people from those groups 
meaning that the already small pool of special selection volunteers gets 
even smaller.


> 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.
>
Try and extend this for more than one special class and see how quickly 
it becomes unwieldy.   The "number_of_same_vendor()" is why I suggested 
the alternate from my other email (and its also listed below).  But even 
that doesn't work with more than one special class as you now need to 
run the iteration multiple times, with the possiblity of overwriting a 
ClassA special selection with a ClassB selection and subsequently with a 
ClassC and so on.

A simple algorithm won't work fairly, and a complex algorithm will 
(probably) collapse if you try to extend it too far.

Lastly - if we ever do something like this to bypass the statistics 
upwards - perhaps we should also bypass the statistics rounding down.  
E.g. if ClassA is 20% of the pool and is guaranteed 10% of the votes on 
a given Nomcom, and in 2025 ends up getting 30% of the votes due to a 
quirk of the random  number generator, should we limit that class to a 
maximum of 20% and re-roll that third member?   Or do we track year to 
year watch the over/unders and do an adjustment when the cumulative 
numbers get above 25% for the past 10 years?

Let's just use the current set of tools we have and make sure the voices 
are heard even if they can't vote.

Later, Mike


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