Re: [Rfced-future] Proposal for RSCE recruitment committee and process
John C Klensin <john-ietf@jck.com> Sat, 12 March 2022 01:53 UTC
Return-Path: <john-ietf@jck.com>
X-Original-To: rfced-future@ietfa.amsl.com
Delivered-To: rfced-future@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1F53A0D5B; Fri, 11 Mar 2022 17:53:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfE7LJyzF25I; Fri, 11 Mar 2022 17:53:00 -0800 (PST)
Received: from bsa2.jck.com (ns.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 C44103A0D69; Fri, 11 Mar 2022 17:52:59 -0800 (PST)
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 1nSqwC-000J6w-JB; Fri, 11 Mar 2022 20:52:56 -0500
Date: Fri, 11 Mar 2022 20:52:49 -0500
From: John C Klensin <john-ietf@jck.com>
To: Jay Daley <exec-director@ietf.org>
cc: rfced-future@iab.org
Message-ID: <10A6F1DF88F6A8907AE41EBB@PSB>
In-Reply-To: <19BC7845-5880-4885-A5EA-4B21DB3706A7@ietf.org>
References: <119A2179-3949-46F3-9B42-4F1DD7BBF98E@ietf.org> <086A66C3-2F07-49E1-8E0C-0571DA5129E3@ietf.org> <A315AE7B53470F88CFC7DD9F@PSB> <19BC7845-5880-4885-A5EA-4B21DB3706A7@ietf.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
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/rfced-future/ut1gaLMcg9CBejAbDGarmqA5Qpw>
Subject: Re: [Rfced-future] Proposal for RSCE recruitment committee and process
X-BeenThere: rfced-future@iab.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: RFC Editor Future Development Program <rfced-future.iab.org>
List-Unsubscribe: <https://www.iab.org/mailman/options/rfced-future>, <mailto:rfced-future-request@iab.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rfced-future/>
List-Post: <mailto:rfced-future@iab.org>
List-Help: <mailto:rfced-future-request@iab.org?subject=help>
List-Subscribe: <https://www.iab.org/mailman/listinfo/rfced-future>, <mailto:rfced-future-request@iab.org?subject=subscribe>
X-List-Received-Date: Sat, 12 Mar 2022 01:53:05 -0000
Jay, Thanks for the detailed and careful response. One observation, which is that, by not addressing those controversial and non-consensus items, you are not avoiding circumventing anything but, instead, are making decisions. There is nothing wrong with your doing that -- the specification is very clear that you get to make these decisions any way that you think appropriate -- but, in your terms, all I was really looking for was to get the "data points" better represented. Good luck with the process. john --On Saturday, March 12, 2022 10:32 +1300 Jay Daley <exec-director@ietf.org> wrote: > John > >> On 12/03/2022, at 9:35 AM, John C Klensin <john-ietf@jck.com> >> wrote: >> >> >> >> --On Wednesday, March 9, 2022 12:43 +1300 Jay Daley >> <exec-director@ietf.org> wrote: >> >>> An update on this. >>> >>>> On 1/02/2022, at 2:50 PM, Jay Daley <exec-director@ietf.org> >>>> wrote: >>>> >>>> In line with Peter's proposed text [1], here is my proposal >>>> for the RSCE selection committee and recruitment process, >>>> which I would like community feedback on. I realise that >>>> things have not been fully settled but this recruitment is >>>> going to take some time and the sooner we can start the >>>> better. If this is too soon then please let me know. >>>> >>>> # Rationale >>>> >>>> 1. The RSCE role is very different from the previous RSE >>>> role and for the recruitment to be a success it is critical >>>> that the committee recruits to the new RSCE role as defined. >>>> It would be problematic if anyone on the committee was not >>>> clear about the new role and was inadvertently targeting the >>>> old role. The committee members therefore need detailed >>>> knowledge of the new role, in all its subtleties. >> >>>> 2. The committee needs detailed knowledge of the working >>>> environment in which the new RSCE will operate in order to >>>> assess fit and answer questions. This environment includes >>>> the RPC, IETF community, IETF community leadership and >>>> non-IETF RFC community (as such as it exists and we have >>>> knowledge of it). >> >>>> ... >> >> Jay, >> >> With the understanding that I'm fine with the people listed, I >> have a small issue with a role that might be missing, one that >> interacts with the characterization above. Whether >> intentionally or not, there has seemed to be an assumption >> that (to exaggerate a bit for emphasis) anyone who >> participated in previous selection processes for the RSE >> and/or definitions of that role are somehow so irreversibly >> contaminated or seriously brain-damaged by those involvements >> to be stuck on trying to resurrect that old role (or, as you >> put it, targeting that role). > > There is no such assumption at all. I have not looked at who > participated in the previous selection, though a few have > recently been identified to me, nor did that figure in the > selection in any way at all. I am confident that anyone who > participated in the previous selection could also be an > excellent choice for this one if they met the criteria above. > >> With the understanding that I am _not_ looking for an >> appointment with the committee, several of those who were >> involved in those previous selections have been very active in >> the Program effort, including contributing to the definition >> of the new role. >> >> None of that would make much difference were it not for one >> other aspect of the issue. The qualifications you list are >> primarily knowledge of the working environment (presumably >> past and present since no one has experience with the actual >> operation of the new model), contracting and (general) >> recruitment expertise, and the details of the new model. All >> that is fine and, if I were making a list, those things would >> be on it. However, what is missing is in-depth understanding >> of the more fundamental and philosophical decisions about how >> RFCs are structured and published. At least as I understand >> it, it was never an agreed goal of this program to >> fundamentally change those things, only to significantly >> change the organizational and decision-making structure that >> supports and drives the Series. > > As we have seen from conversations on this list, when an > attempt was made to codify the "more fundamental and > philosophical decisions" there was considerable pushback and > only a small set reached consensus. If I recall correctly, > when I attempted to list a set of de facto decisions that > appeared to apply, you were very uncomfortable with even that > approach. Given that, I do not think it would be at all > appropriate for me to try and circumvent this group by finding > a route for those non-consensus items to be reintroduced into > the recruitment process as anything other than data points. > >> Sandy knows much of that from observation and >> participation in more recent versions of that history. But, >> perhaps by a side effect of what appears to be assuming that >> irreversible contamination, you have no one one your list who >> knows that history. Not only is there no one who was involved >> in the prior RSE (or earlier) selection processes, but AFAICT, >> there is no one who was on the RSOC before the meltdown(s) >> started, no one who has been on the RSE's advisory (as >> distinct from "oversight") body or its predecessors, and no >> one who has served on the ISE's editorial board. > > This is not intentional - it is partly an artefact of the > criteria and because I did not go back through that history > when reaching out to people. > > To reiterate what I have said before - we have a new structure > for the RFC Editor function and we have a new RSCE role, both > of which have been developed in an open community process and > which have consensus. While the history and past > contributions are very much valued, it would be improper if > that overrode the new structure. > >> >> Eliminating those people may also reduce the committee's >> knowledge of the "non-IETF RFC community". In particular, it >> also appears that, when you mention contracting, you are >> focused on options available to the IETF LLC and not the >> rather different sets of issues faced by people who use RFCs >> as part of their procurement processes. Those who use the >> RFCs in procurement may not be a "community" in any real >> sense, but they are vitally important to the relevancy of the >> RFC Series and, indeed, the IETF. >> >> It might even be worth mentioning that at least one of the >> people who was interviewed during the cycle in which Heather >> was selected would have been much more qualified for the >> current definition of the RSCE role than they were for the >> RSE one -- the latter was seen as having some requirements >> that the candidate didn't satisfy but that are now largely or >> completely irrelevant. Certainly the roles are very >> different, but that does not make the candidate pools >> disjoint. > > Marvellous. Please let me know their name offlist. > >> >> In addition, our definition of "detailed" may differ but I >> don't think there is _anyone_ who has "detailed knowledge of >> the new role, in all its subtleties". Substitute "opinions" >> for "knowledge" and I'd agree, but it is knowledge that you >> asked for and that, IMO, is needed. From observation of the >> discussion on this list, I believe that some people expect the >> RSCE to be someone who brings some expertise to the table but >> whose role is largely passive, more or less speaking only when >> spoken to. Others see the need for a more active role >> including noticing current or potential problems and bringing >> them to the attention of the RSWG, RSAB, or other actors as >> appropriate and before they evolve into crises. I think the >> community would be better served by having both perspectives >> on the role (and/or perspectives in between) represented on >> the committee rather than having only one perspective because >> of the choices of committee members (maybe both perspectives >> are adequately represented on your list but it is not obvious >> and does not appear in the criteria you list). The current >> version of the document does say (Section 5, second bullet) >> "Identify problems with the RFC publication process..." which >> moves things a bit in the second direction. It does not say, >> for example, "Identify and alert people to potential future >> problems facing the Series" but that is not excluded either: >> the text only talks about "primary responsibilities" and, >> further on, "might provide guidance [that] could include...". >> I don't recall any consensus that would eliminate the >> possibility of the RSCE taking a longer-term view or offering >> advice proactively; only the possibilities of the RSCE having >> any individual authority or making unilateral decisions is >> excluded. > > This is a non-problem. Not only has there not been any > consensus that we should have a passive RSCE, I have not seen > anyone at all argue for a passive RSCE. In fact, when that > topic has come up there has been strong unanimity that the > RSCE should be free to offer whatever advice they see fit as > proactively as they wish. > >> >> I think the text is ok and that the RSAB and RSWG will have to >> do a certain amount of sorting out of roles (the RSCE one and >> many others) as experience with the new model accumulates. >> But it seems to me that it could be important to have one or >> more people on the selection committee with that longer-term >> perspective on Series philosophy so that candidates who would >> be good at the more proactive role are not systematically >> excluded. FWIW, that difference in skills should be reflected >> in the instructions given the recruiters. >> >> A different way to read some of your comments and criteria >> --and we have talked about this before-- is they can be >> interpreted as looking for a committee with completely shared >> views about roles and responsibilities. That would certainly >> make things easier. It would also not be representative of >> the community (or even the consensus of this Program) with >> regard to questions about the details of roles. Fortunately >> from my point of view, the committee members you listed are >> not going to give you that level of homogeneity. > > Excellent. > >> I'm suggesting that, because the >> advantages of complete homogeneity have been abandoned, it >> would be an advantage to broaden things even a bit further >> and that it would have no downside ... again unless there is >> consensus about the brain-damage hypothesis about people with >> prior experience with the selection process and/or long-term >> series strategy. > > Thanks. As I've explained a couple of times before, step 1 > of the recruitment is for the recruiters to speak to a wide > range of community participants to get their views on the > candidates they should seek out and assess. > > Jay > >> >>> ... >> >> best, >> john >> >> -- >> Rfced-future mailing list >> Rfced-future@iab.org >> https://www.iab.org/mailman/listinfo/rfced-future
- [Rfced-future] Proposal for RSCE recruitment comm… Jay Daley
- Re: [Rfced-future] Proposal for RSCE recruitment … Martin J. Dürst
- Re: [Rfced-future] Proposal for RSCE recruitment … Salz, Rich
- Re: [Rfced-future] Proposal for RSCE recruitment … Jay Daley
- Re: [Rfced-future] Proposal for RSCE recruitment … John C Klensin
- Re: [Rfced-future] Proposal for RSCE recruitment … Jay Daley
- Re: [Rfced-future] Proposal for RSCE recruitment … John C Klensin