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
- [ietf-nomcom] While I have you all here - size of… Michael StJohns
- Re: [ietf-nomcom] While I have you all here - siz… Abdussalam Baryun
- Re: [ietf-nomcom] While I have you all here - siz… Salz, Rich
- Re: [ietf-nomcom] While I have you all here - siz… John C Klensin