Re: Revised IETF LLC Draft Strategic Plan 2020 to address feedback raised

Jay Daley <jay@ietf.org> Tue, 02 June 2020 03:48 UTC

Return-Path: <jay@ietf.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72A493A07F6 for <ietf@ietfa.amsl.com>; Mon, 1 Jun 2020 20:48:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 LMXeqLmVccvz; Mon, 1 Jun 2020 20:48:24 -0700 (PDT)
Received: from jays-mbp.localdomain (unknown [158.140.230.105]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPSA id 4D0FD3A07F2; Mon, 1 Jun 2020 20:48:23 -0700 (PDT)
From: Jay Daley <jay@ietf.org>
Message-Id: <57A76FF0-B081-40BA-A436-B6B31E44535B@ietf.org>
Content-Type: multipart/alternative; boundary="Apple-Mail=_6B6A8E16-2EE0-411C-A9E0-8BC6F9EEA7B5"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Subject: Re: Revised IETF LLC Draft Strategic Plan 2020 to address feedback raised
Date: Tue, 02 Jun 2020 15:48:20 +1200
In-Reply-To: <CABcZeBPwqdf8u5AULSw3LY8p93PgUxHTmF4SZV0sR_5=weFOww@mail.gmail.com>
Cc: ietf <ietf@ietf.org>
To: Eric Rescorla <ekr@rtfm.com>
References: <CABcZeBOnddO=uiBzaDC82f+Ot532ArAE-czrSHWVqaDUtakGYA@mail.gmail.com> <6FF21BBC-936A-4D28-8E78-1BCE3BE8EF16@ietf.org> <CABcZeBPwqdf8u5AULSw3LY8p93PgUxHTmF4SZV0sR_5=weFOww@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/8AkWFsGXVCzndnTLS9svVviL4XE>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Jun 2020 03:48:25 -0000

All of your points are now addressed in the latest draft at 

	https://github.com/ietf-llc/strategy-2020-consultation/blob/latest-updates-from-consultation/DRAFT%20Strategic%20Plan%202020.md <https://github.com/ietf-llc/strategy-2020-consultation/blob/latest-updates-from-consultation/DRAFT%20Strategic%20Plan%202020.md>

Jay

> On 30/05/2020, at 8:59 AM, Eric Rescorla <ekr@rtfm.com> wrote:
> 
> 
> 
> On Fri, May 29, 2020 at 1:37 PM Jay Daley <jay@ietf.org <mailto:jay@ietf.org>> wrote:
> Eric
> 
>> On 30/05/2020, at 2:38 AM, Eric Rescorla <ekr@rtfm.com <mailto:ekr@rtfm.com>> wrote:
>> 
>> 
>> Jay,
>> 
>> Thanks for sending this. Some comments below. I've also sent
>> you a PR to convert the tables to Markdown, which would
>> make this rather easier to read.
> 
> I personally find html tables far easier to read and manipulate than markdown tables, which is why I used them but I’ll look at the PR to see how easy you’ve made them to read.
> 
> In my experience, they're much harder to diff.
> 
> 
>> > 6. To deliver a toolchain that is up-to-date and well regarded by users.
>> 
>> This seems in conflict with "evidence-led". Suppose the toolchain
>> was well-regarded by users but empirically less efficient than
>> other toolchains.
> 
> I’m not convinced that there is another toolchain we can measure against or that measured user satisfaction is that distant from empirical observation of efficiency.
>  
> As someone who has been at organizations that go through toolchain changes, I can tell you that very often the stakeholders have minimal experience with other toolchains and therefore their level of satisfaction is not related to whether those toolchains would be more efficient.
> 
> 
>> > Sponsors, in addition to supporting the IETF for the value it
>> > delivers, are also increasingly concerned about how the organisations
>> > they sponsor operate, how they treat their volunteers and staff and
>> > what opportunities they provide for a diverse range of new
>> > participants.  To be able to explain this, we need to document the
>> > participant journey, a map of the different stages of participation
>> > (e.g. newcomer, leadership), at what stages people start their
>> > participation in the IETF, how they transition between them and at
>> > what stages they end their participation.
>> 
>> There seems to be an implicit assumption here that people should
>> have a "career arc" in IETF that starts with newcomer and
>> ends with leadership, but I don't think that's obviously
>> true. Many of our most valuable contributors have never served
>> in leadership and some of them do lots of reviewing but not
>> a lot of RFC writing.
> 
> No implicit assumption at all.
> 
> The phrase "the participant journey" and the description of different stages implies that.
> 
> This is simply documenting what exists though admittedly that information could be used for that purpose if the community so desired (I have no views at all on whether it should or should not). 
> 
> Well, I don't know what it is you propose to document, so it's hard to know what I think about it. But given that this is unclear, perhaps either clarify it or document it.
> 
> -Ekr
> 

-- 
Jay Daley
IETF Executive Director
jay@ietf.org