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

Michael StJohns <msj@nthpermutation.com> Sat, 25 November 2023 17:42 UTC

Return-Path: <msj@nthpermutation.com>
X-Original-To: eligibility-discuss@ietfa.amsl.com
Delivered-To: eligibility-discuss@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A90C1519A8 for <eligibility-discuss@ietfa.amsl.com>; Sat, 25 Nov 2023 09:42:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.906
X-Spam-Level:
X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nthpermutation-com.20230601.gappssmtp.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aB4t6Ict4K61 for <eligibility-discuss@ietfa.amsl.com>; Sat, 25 Nov 2023 09:42:05 -0800 (PST)
Received: from mail-oa1-x35.google.com (mail-oa1-x35.google.com [IPv6:2001:4860:4864:20::35]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 756B5C1519A2 for <eligibility-discuss@ietf.org>; Sat, 25 Nov 2023 09:42:05 -0800 (PST)
Received: by mail-oa1-x35.google.com with SMTP id 586e51a60fabf-1fa235f8026so364244fac.3 for <eligibility-discuss@ietf.org>; Sat, 25 Nov 2023 09:42:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nthpermutation-com.20230601.gappssmtp.com; s=20230601; t=1700934123; x=1701538923; darn=ietf.org; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=iHDBIPFGThr0853yWLLX1IkkWM3ey1jouoT67gswlTM=; b=nbRflO/UV2EBt3LSswWps7aq/dcA+HGWbfIdHzBTv9S/EY4P8ZzRJPBraJD7oKveKA WpMrtzF+H+4G1xq39VxgJgSKcavuY+Gw/H45n+VqmOHAEWC+kIKEgS4bGZAyyoRyf3yp wjP7Ir59R+QhWibl3Hr1ER98XwSw+wjio1SwhZgP0OS1QvYeu0klaJZfsQJhbLlNRWKL E84SkHvuWuYot1uD4rs6z4EfsnsCnmlWIWmQlICez7zYfrVRaO0BMOnZVBaERhhLznvC RJFHZ3Rjfw/5GNN7kpvb4/VGjPRuORxOBgTQT3QVMAoo1CPIf82bTtODI1nu90OvBAc3 +ABw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1700934123; x=1701538923; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=iHDBIPFGThr0853yWLLX1IkkWM3ey1jouoT67gswlTM=; b=vnOiy9BYTvKG7Xo9qviCoyMtEJ+c9Mvkr5HBarKkUf8dMHpmQAfRoAyi8g3nyjRxsI v88iaHMxNMMhsLwOppAOKN4gt4d0h2a3rU39+gV7U1VzLrsTmaKHX5dNMJ/GXHsfFmrG JuS3gUGjH51BrR25VStm9qTN6WiCmOWifnhdxD8UY2XhXJFSTadzFwyzwcH1gF2/R+LC cpic6vocDdy4HP66Fp/47aROr4heyzEAL4QTRd6hJzazKjJMjTzBb8bJIUnnZnC8fHbg H2d+3qrEcZo8gvwfvKU+OMHZkE05+o8owbpJbST1RdD63yXEEtlO7Ik7EtubOQlUMpx5 kmHg==
X-Gm-Message-State: AOJu0YzpXSLL0VXDs3MqVn9LGJYrxgjYW4DMb6RGLW2HHRqM4dh+5NUK 1dF0R9YT1T0PjUTtMdiC7HpIqSTSwHnS43vdYY8=
X-Google-Smtp-Source: AGHT+IGcI92eeMSYY/c3O/ZkqQYWGYIBrkisMUd5MbQwirs9XpDwg3LMxW/JjmZtuPHSS5hBMd7yFQ==
X-Received: by 2002:a05:6870:c18a:b0:1fa:511:ff40 with SMTP id h10-20020a056870c18a00b001fa0511ff40mr6677053oad.21.1700934123020; Sat, 25 Nov 2023 09:42:03 -0800 (PST)
Received: from [192.168.1.23] (pool-108-31-156-76.washdc.fios.verizon.net. [108.31.156.76]) by smtp.gmail.com with ESMTPSA id g23-20020ac84817000000b0041eef6cacf4sm2360684qtq.81.2023.11.25.09.42.02 for <eligibility-discuss@ietf.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 25 Nov 2023 09:42:02 -0800 (PST)
Content-Type: multipart/alternative; boundary="------------RRFqv00ujGtXavB04Mtu6QIw"
Message-ID: <a37ad0bc-a69c-45c4-b471-088f107ee467@nthpermutation.com>
Date: Sat, 25 Nov 2023 12:42:00 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Content-Language: en-US
To: "eligibility-discuss@ietf.org" <eligibility-discuss@ietf.org>
References: <f871d358-8d9d-4714-99a8-6a51198a61c9@cdt.org> <5282ED25-E538-493A-A7B5-DA34CD0460ED@yahoo.com> <CALaySJ+4206AH0BoTvsLkn4LYw-TcdBFJSc0vCK6BR58QH=zfA@mail.gmail.com> <39411eb3-7947-49bf-9406-089f43ada331@nthpermutation.com> <CABcZeBN=_Lg2Hd=4QdB6c-_RN8f8b2f3So_AWAuwZGafs_Mocg@mail.gmail.com> <25ea1487-d5f6-46e2-9c2e-487291fd55b3@nthpermutation.com> <761E201D-5D19-4F1D-94C4-40E9A011BDE2@akamai.com> <b78b56cc-b37d-4385-b746-be782621dfa1@nthpermutation.com> <00B57B77-CADF-4183-B0A1-84AF1AB5981A@akamai.com>
From: Michael StJohns <msj@nthpermutation.com>
In-Reply-To: <00B57B77-CADF-4183-B0A1-84AF1AB5981A@akamai.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/eligibility-discuss/H4aud753Uj9yUUNbU4N96YYfQyM>
Subject: Re: [Eligibility-discuss] [Gendispatch] New Version Notification for draft-knodel-nomcom-gender-representation-00.txt
X-BeenThere: eligibility-discuss@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: IETF eligibility procedures <eligibility-discuss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/eligibility-discuss>, <mailto:eligibility-discuss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/eligibility-discuss/>
List-Post: <mailto:eligibility-discuss@ietf.org>
List-Help: <mailto:eligibility-discuss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/eligibility-discuss>, <mailto:eligibility-discuss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 25 Nov 2023 17:42:06 -0000

I'm going to reset this slightly and offer a heretical comment.

    The lack of a particular community participating on a given nomcom
    is NOT a problem, well-known or otherwise.  It's one fact from a
    fair random selection.

Instead, "The Nomcom candidate selections under-represent a given 
community over many Nomcoms."  would be a problem if the statistics 
showed that.  Is that the actual problem we should be addressing?

Is the following a more accurate statement of the perceived problem?

If Mallory's document said "We have this problem of under-representation 
in the IETF leadership.  Under-representation in the proposed candidates 
is measurably increased in the years where the voting members of the 
Nomcom do not include a member from that community and here's the 
statistics to show that case. If we imposed a requirement to require at 
least one of those community members on each Nomcom statistics show this 
would help to resolve the under-representation of that community within 
the output selections."   I would probably be more accepting of 
Mallory's proposed solution in that case.

Unfortunately the current document doesn't say that, and I can't 
actually figure out what the problem being addressed actually is. It 
can't be that losing a lottery is the actual problem.

I might still argue against the simplistic approach proposed to solving 
the under-representation problem.  I would suggest that instead the 
liaison/advisor approach coupled with greater oversight by the 
confirming bodies and a willingness by them to require the Nomcom to 
reconsider selections as a means of achieving appropriate levels of 
representation might address an under-representation problem.

We address the input conditions to affect the output conditions. If 
adjusting the input condition results in no difference to the output 
conditions, why are we twiddling?  If adjusting the input conditions 
does affect the output - show me the math.

A few other questions before I end - related to the proposal on the 
table and that will need to be addressed without hand waving:

1) Does the mandatory requirement apply if the volunteer pool 
participation for a community falls below 10%?  5%?  3%?  Or goes above 
20%? 30%?

2) What is the criteria for selecting other communities for similar 
treatment?

3) Are claims of community membership subject to challenge (similar to 
claims of organizational association)?

4) What happens if the sole selected community member needs to be 
replaced?  Consider both the before the Nomcom convenes and after?

5) Is there a sunset clause?  If so, how is it triggered?  If not, why not?

Lastly - the more general algorithm that would probably work without 
collapse is to select the special community members at the beginning of 
the process applying all of the rest of the rules for the remaining 
batch of selections.

And to capture the possibilities:

Possible changes to the Nomcom process (zero or more of these):

1) Impose a requirement to select at least one member from the non-male 
community to serve on the Nomcom.

1a) .... at least 2 members...  [[generally to address a past issue 
which has resulted in knock on present issues, you over represent the 
affected community for a period of time]]

2) Increase the number of voting members from 10 to 15 or 16.  At 16, 
with 10% of the pool, a community has a 4 in 5 chance of at least 1 
member, a 1 in 2 chance of at least 2.

3) Provide a non-male liaison/advisor either for every Nomcom or for any 
Nomcom without a non-male voting member.

4) Have a mandatory 1/2 briefing for the Nomcom on diversity issues 
prior to their first deliberation?

Later, Mike