Re: [Gendispatch] Diversity and Inclusiveness in the IETF

Lars Eggert <> Fri, 26 February 2021 08:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B28A3A0BFA; Fri, 26 Feb 2021 00:34:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id DGbLnikbPbDj; Fri, 26 Feb 2021 00:34:42 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 23B3E3A0BF9; Fri, 26 Feb 2021 00:34:42 -0800 (PST)
Received: from [IPv6:2a00:ac00:4000:400:b9:15ed:9bd5:c92f] (unknown [IPv6:2a00:ac00:4000:400:b9:15ed:9bd5:c92f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 40C5860004C; Fri, 26 Feb 2021 10:34:33 +0200 (EET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=dkim; t=1614328473; bh=BBT/gE8Qwv4k25deOIDSX8uvAqXYJsL05DFYUEpv1eU=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=0oO7XpXJF+FpVWv2ERuxSSqYoSjuJF5NAFsuEboDt/oQ2FsSXkIyrnbKGZcpZdMmm miuxzOO1V8dL4fVfDyWzUL1HLxzUFPx5RiwfiXNHct9TfiFGOSbeEOylouU3CYc0GB JjiXI2IG+UMcBWz7yXWriXV3qNhgLvV61Druv9tU=
From: Lars Eggert <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_860C18F7-E372-44D2-9554-BE4FFE193379"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.\))
Date: Fri, 26 Feb 2021 10:34:32 +0200
In-Reply-To: <>
Cc: "Salz, Rich" <>, Andrew Campling <>, Dominique Lazanski <>, Bron Gondwana <>, "" <>, "" <>
To: Fernando Gont <>
References: <> <> <> <> <LO2P265MB057322BA95B1B44D4175356BC29E9@LO2P265MB0573.GBRP265.PROD.OUTLOOK.COM> <> <> <>
X-MailScanner-ID: 40C5860004C.A08D7
X-MailScanner: Found to be clean
Archived-At: <>
Subject: Re: [Gendispatch] Diversity and Inclusiveness in the IETF
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Area Dispatch <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 26 Feb 2021 08:34:44 -0000

On 2021-2-25, at 21:34, Fernando Gont <> wrote:
> On 25/2/21 16:24, Salz, Rich wrote:
>> of git/github does represent yet another barrier.
>> Nothing requires anyone to use Git or GitHub.
> If a WG somewhat requires use of github, then the barrier is there.

It may be a barrier to some. It may also *lower* the barrier for others. It's a tradeoff.

For example: The QUIC WG uses GitHub extensively. That has made it very easy for the engineers that are implementing QUIC stacks at various organizations to participate in the WG, because much of that development already happens on GitHub and so the WG process is more approachable. For many of these engineers, QUIC is their first involvement in the IETF, and using tools and workflows that are familiar hence lowers the bar for their participation. On the flip side, several longtime IETF participants were not very familiar with GitHub and its workflows, and the WG's heavy use of them required some adjustment, making it a bit more challenging for them for a while. Personally, I believe this was a worthwhile tradeoff to make, given that we needed to manage the design of a very complex protocol, but YMMV.