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