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

[Ted Hardie <[e-mail]>]

Hi Martin,

I'm not sure this works in all cases.  Imagine the case where one of the
original nine provides the information that they are gender fluid, even
though they have commonly presented as male in IETF contexts. If that
participant provides this data to the chair in private, the gender
diversity requirement will be met.  But the announcement that it has been
met will bring additional attention to the gender identities of all those
in the original set (because the community will not have expected it to
have been met based on their incomplete understanding of the situation).
That scrutiny will hit people who might have chosen PNTS and who might not
be okay with this scrutiny because of their own gender identities.

regards,

Ted Hardie

On Sat, Nov 25, 2023, at 16:24, Mark Nottingham wrote:
> > However, I am extremely wary of creating a situation where people's
> > gender identity is necessarily declared and scrutinised in public as
> > part of our process -- even with a 'prefer not to say' option.
>
> I have a suggestion that hopefully does a better job of balancing these
> concerns.
>
> The NomCom chair is entrusted with a lot of responsibility.  They could
> ask each volunteer as they are selected.  This information could be kept
> confidential short of an appeal specifically related to this specific
> question, in which case it would be revealed to the ISOC president.
>
> The audit requirement is largely met by announcing that all of the first
> nine fail to meet the diversity requirement.  People would then have to
> make their own inquiries to verify if the integrity of the NomCom chair is
> in question, or rely on the former chair, as noted below.  That largely
> fails to provide privacy for those who are unlucky enough to fall into that
> category, so this risk needs to be made clear when volunteering.  Though,
> with PNTS, it means that the nine all declared gender A or PNTS.
>
> The larger privacy failure is for the person who fills the final slot, who
> is thereby identified as a different gender to the majority, with no
> ambiguity about whether they chose PNTS.  Again, if information is
> requested by the NomCom chair at the time of selection, along with a
> reminder of the implication of different choices, someone who wants to
> avoid this can invoke the PNTS protection, though that would disqualify
> them.
>
> With the former NomCom chair as a trusted auditor, I think that this could
> work.
>
> The time needed to serially request gender after the draw might cause this
> to drag on a little.  The chair can maybe make some assumptions (as risky
> as that is) and make the request of more than one person at a time.
>
> Note that this creates a low probability scenario where there is a
> potential for abuse.  If all gender A or PNTS reaches 9/10, then everyone
> who is asked thereafter can strategically choose PNTS if they consider the
> next likely person to be a better option for some reason.  There is the
> option to have the chair execute a commit and reveal protocol, so that
> volunteers do not have this option, but that draws things out more and I
> don't think that is necessary.  We should instead rely on the fact that
> their own gender identity is not something that people treat so frivolously
> as to use it in this way.
>
> The other thing that has come up is the potential for a rule like this to
> cause the pool to be exhausted without resolution.  That would be bad, but
> my suggestion would be that the rule would be deactivated in that case,
> with the first person who was disqualified by it then being asked to serve.
>
> (A side note: this sort of complexity is why I think that attempting to
> index on other dimensions of diversity is not helpful.  I would suggest
> that if we ever find that gender diversity improves, we might drop this
> process so that we might apply it to another dimension.)
>
> Cheers,
> Martin
>
> --
> Gendispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/gendispatch
>