Re: [ietf-nomcom] While I have you all here - size of the Nomcom voting members?

John C Klensin <john-ietf@jck.com> Sat, 05 August 2023 19:33 UTC

Return-Path: <john-ietf@jck.com>
X-Original-To: ietf-nomcom@ietfa.amsl.com
Delivered-To: ietf-nomcom@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6ED9C14F726 for <ietf-nomcom@ietfa.amsl.com>; Sat, 5 Aug 2023 12:33:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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
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 VF2iZEU9kj1c for <ietf-nomcom@ietfa.amsl.com>; Sat, 5 Aug 2023 12:33:38 -0700 (PDT)
Received: from bsa2.jck.com (bsa2.jck.com [70.88.254.51]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C222C14E513 for <IETF-Nomcom@ietf.org>; Sat, 5 Aug 2023 12:33:38 -0700 (PDT)
Received: from [198.252.137.10] (helo=PSB) by bsa2.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1qSN1s-000IVg-BG; Sat, 05 Aug 2023 15:33:36 -0400
Date: Sat, 05 Aug 2023 15:33:30 -0400
From: John C Klensin <john-ietf@jck.com>
To: Michael StJohns <msj@nthpermutation.com>, IETF-Nomcom@ietf.org
Message-ID: <821004EC8A4E75BEAFE1FA79@PSB>
In-Reply-To: <5b8ace86-f8ea-0e0e-454f-e3da6b753642@nthpermutation.com>
References: <5b8ace86-f8ea-0e0e-454f-e3da6b753642@nthpermutation.com>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
X-SA-Exim-Connect-IP: 198.252.137.10
X-SA-Exim-Mail-From: john-ietf@jck.com
X-SA-Exim-Scanned: No (on bsa2.jck.com); SAEximRunCond expanded to false
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-nomcom/z6xeZvYcNC5WlqSuaDHwLEYkDJU>
Subject: Re: [ietf-nomcom] While I have you all here - size of the Nomcom voting members?
X-BeenThere: ietf-nomcom@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Discussions of possible revisions to the NomCom process <ietf-nomcom.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-nomcom>, <mailto:ietf-nomcom-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-nomcom/>
List-Post: <mailto:ietf-nomcom@ietf.org>
List-Help: <mailto:ietf-nomcom-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-nomcom>, <mailto:ietf-nomcom-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 05 Aug 2023 19:33:42 -0000


--On Friday, August 4, 2023 16:31 -0400 Michael StJohns
<msj@nthpermutation.com> wrote:

> Hi -
> 
> One of the side discussions I had with a few people was
> related to the expanding number of positions the nomcom has to
> fill, the expanding number of liaisons (who get to vote on
> everything but candidate, and participate on everything and
> who in quantity are approaching the number of voting members),
> and the static number of nomcom voting members (same since
> nomcom #1).

Mike,

I have two, perhaps larger, concerns that interact with yours.
First, a good deal of the integrity and effectiveness of the
process depends on confidentiality and the nomcom really being
representative of the community.  The former is subject to the
old principle that, the larger the group becomes, the likelyhood
of leaks rises along with it (that is a problem with the long
liaison list as well).    However, several conversations I've
had in the last few years with people who I thought would have
made good candidates for, in particular, IAB/IESG positions --
people who, for one reason or another, are critical of the
current state of those bodies and their membership -- suggest
that at least some otherwise-qualified people are unwilling to
put their names in because, even if they trust the integrity of
the voting nomcom members, the rising number of liaisons and
other non-voting Nomcom participants leaves them in fear of
retaliation if they are not selected.

>From that perspective, having those liaisons and others
participating in all discussions and privy to all information
given to the Nomcom is, itself, a problem.  Perhaps one way of
looking at the issue is that the reason we rely on rough
consensus rather than voting in most IETF proceedings is that
effective participation in the discussions influences, and may
be as important as, the final conclusions (whether determined by
an assessment of consensus or of voting).

I gather than Nomcom Chairs can mitigate those problems
considerably, but, because of variations in chairs and their
personal styles over the years, that makes things rather fragile
from year to year.

Second, representativeness of the community may perhaps be more
of an issue now than it was at the beginning. Other changes have
appeared to result in proportionately fewer voting members
having deep knowledge of the community and potential candidates,
increasing the workload due to the need to rely on interviews,
third-party comments, etc.  In particular, one of the
differences between the voting membership of the Nomcom of today
and that of yore is that, AFAICT, in a typical year, the
fraction of nomcom voting members with significant first-hand
experience with the work of the IETF (present or former members
of the technical work leadership, WG chairs, authors of
documents that have made it into IETF Stream publication, etc.)
is much reduced, increasing the need to rely on job
descriptions, liaisons, etc., and increasing the threat of the
leadership becoming self-perpetuating. IIR, the main reason we
went down the nomcom path was precisely to avoid the IAB
appointing its own members and the IESG or each of those bodies
appointing its own members/successors.

With those issues, adding more voting members does not reduce
the workload at all unless we are willing to essentially divide
the Nomcom into parts with some members considering candidates
for some roles and other members considering others.  I don't
think that is what we want and note that, if we did, we might
want a second Chair and a whole new set of liaisons.   I have to
assume that difficulties getting a good (and large and diverse
enough) volunteer pool is, at least in part, because the work
commitment has increased considerably.  We've discussed more
sinister theories about organizations trying to pack the nomcom
but, to the extent that is a concern, it just adds to the
problem.   Assuming the randomization algorithm works, if the
characteristics of the pool of volunteers does not change and we
draw more people from it, selecting more voting members wouldn't
make that problem any better and might increase the workload
(and load on the Chair and liaisons) because more voting members
would need to understand the candidate collection and agree on
the choices.

> I'm wondering if increasing next year's nomcom to by some
> amount (to 15, 16 and 20 were numbers discussed) might help
> ease the burden, and give a few more people opportunities to
> participate in selecting the future leadership, and deal with
> the occasional problems of missing in action voting members? 
> 15 because it sort of matches the scaling of positions
> somewhat, 16 because its the next even number, and 20 as sort
> of the maximum I think could be easily absorbed.

For the reasons above, I don't think that would help.  I suppose
we could change the model so that people volunteered for two
years, serving as observers/ learners the first year and voting
only the second one, possibly with provision for promoting an
observer (at random) to voting status if there were dropouts
from the effective voting membership. That would address the MIA
problem you identify without the problem of adding someone
mid-term with no knowledge of earlier discussions and might help
with the spin-up problems and maybe make things more efficient.
But that, of course, adds to the unwieldiness of the whole
system and would probably further reduce the diversity of the
pool of volunteers.

> That might give the chair some opportunities to delegate some
> of the tedium of getting interviews done and arms to be
> twisted.

If that is a significant part of the problem, we might want to
think about supplemental members who assist with those
activities without becoming part of the voting membership, privy
to candidate interviews, etc.  They could be volunteers without
the randomization process precisely because they presumably
would have no substantive influence on the results.  My guess is
that managing an arrangement like that would put more burden on
the chair than just doing the work, but maybe I'm wrong.

> This would require community consensus, but the update
> document would simply change that number and nothing else.
> 
> Thoughts?  Mike

Doesn't feel right to me.  If we want to reduce the nomcom
workload, we need to figure out how to reduce the number of
positions the nomcom needs to fill or increase the fraction of
nomcom members who have sufficiently broad first-hand experience
with the IETF and the likely candidate base to permit
significant candidate filtering without relying on interviews.
I don't see either of those options as being feasible in the
current IETF unless we remove appointment slots from the
nomcom's task list and assign making those appointments to the
IESG, IAB, or LLC staff.  I don't see any of those as good
options.  Indeed, it would reduce the idea of selection by a
broad selection from the community (the idea behind the nomcom
in the first place) and shift us toward the self-perpetuating
leadership model we had pre-Kobe and maybe made it worse.

    best,
      john