Some more thoughts about language and what to do next

Eliot Lear <lear@cisco.com> Thu, 30 July 2020 08:10 UTC

Return-Path: <lear@cisco.com>
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 6C4EC3A0F86 for <ietf@ietfa.amsl.com>; Thu, 30 Jul 2020 01:10:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 c3ZGGMNpJeW0 for <ietf@ietfa.amsl.com>; Thu, 30 Jul 2020 01:10:44 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDBD33A0D38 for <ietf@ietf.org>; Thu, 30 Jul 2020 01:10:43 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9192; q=dns/txt; s=iport; t=1596096644; x=1597306244; h=from:mime-version:subject:message-id:date:cc:to; bh=07+aPaua6Hc2QQ5cvchSsWEkyzoWFRkc0Tptw5J57AI=; b=WwE7f+LvNXnW7Io7wGvvnC/+JDSalY93JSrueXhBD6vn62lmSsZyci+K KwzTq9UuhWPe+zDKoEyOVilxAY/h2ruFhcc3NfU3lazaUfXQ5XJJ9ccgP uBrg/ElZGIYIYYe8BEU2AuUQcmmfbR5+xOA35dwFw/SwUx9iuG+RaY5uN o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CJBgBmfyJf/xbLJq1gHgEBCxIMg38GgXIBMiyENYkBh3KUGoYugWkLAQEBDAEBLwQBAYRHAwKCKyU4EwIDAQELAQEFAQEBAgEGBG2FaIVxAQEEJEgBCAUFLioCXxMUgxKCXSCuNXaBMoVShQCBOI0nggCBOAwQgU9QhHQBEgGDNzOCLQSLMIQIKxSmEIJpBIMGkROCfoJkAgEegnuJS4UFjimtaYNWAgQGBQIVgWojZ3AzGggbFWUBgj4+EhkNj0QBDo0VPwMwNwIGAQcBAQMJkElgAQE
X-IronPort-AV: E=Sophos; i="5.75,413,1589241600"; d="scan'208,217"; a="28315985"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Jul 2020 08:10:39 +0000
Received: from [10.61.211.2] ([10.61.211.2]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 06U8AcEf028046 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 30 Jul 2020 08:10:39 GMT
From: Eliot Lear <lear@cisco.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_46D6DF7A-C1F0-4133-87CA-E4736E9A2FE4"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Subject: Some more thoughts about language and what to do next
Message-Id: <09474801-7189-4C01-8242-163454C3E936@cisco.com>
Date: Thu, 30 Jul 2020 10:10:37 +0200
Cc: The IETF List <ietf@ietf.org>, Richard Barnes <rlb@ipv.sx>, "Vinton G. Cerf" <vint@google.com>
To: Bron Gondwana <brong@fastmailteam.com>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-Outbound-SMTP-Client: 10.61.211.2, [10.61.211.2]
X-Outbound-Node: aer-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/c2v4G9LOJbUncmWRau7N1n9NGSg>
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: Thu, 30 Jul 2020 08:10:47 -0000

Hi Bron and everyone,

I’ve got a proposal for a way forward toward the bottom.  &tldr; be iterative and do research.

I very much enjoyed your explanation of virtue vs virtue signaling, and in particular the parenthetical got me chuckling.  On this point:

> On 29 Jul 2020, at 15:32, Bron Gondwana <brong@fastmailteam.com> wrote:
> 
> It seems to be me that most of the debate in this thread boils down to: "is this effort is a clear signal that we're serious about trying to be inclusive rather than facile pandering to a particularly noisy political group?", and an associated "would publishing something like this be effective and attract people who want to make the Internet work better by producing high quality, relevant technical documents that influence the way people design, use, and manage the Internet?”


Yes.  But I think we can walk and chew gum at the same time, and that we can be iterative.  The IETF is by no means the only or first organization to have these sorts of ridiculously long and argumentative threads about terminology.  The arguments themselves are plaguing the OSS community, companies, and other standards organizations.  The arguments themselves are toxic and counterproductive, and not just at the IETF.*

As I have previously written, at the moment, there is no commonly accepted, well researched decision framework for inclusive terminology selection.   This leads to lots of opining (e.g., the toxicity).  A few of us are actively working to correct this by attempting to establish a funded agenda with an eye toward finding decision frameworks that people would be comfortable using.  The idea is to bring in experts such as linguists, ethicists, sociologists, psychologists, etc who understand these things far better than engineers are likely to.

Our challenge: gaining the attention of those sorts of researchers from our distant position from their normal professional lives.  My company is large and can make a splash.  A few companies can make a wave.  A lot of companies asking for help from experts will turn the tide.  If you work at such a company with a research department, and are interested in collaborating on such an agenda, please drop me an email.  A few of us are already in touch, and the more the merrier.

In the meantime, I propose an iterative approach, noting that we are all trying to learn a bit more on this:
March 2021 (or so**): a BCP that states what people should think about with regard to their terminology, and guidance to people doing reviews.  I would keep this short.  The idea is not to prohibit certain words but to make use of WG and IETF rough consensus rules to encourage avoidance of the more obvious terms that people are likely to find offensive.  This allows deference to the specifics of each case, and we don’t have to worry about formal role assignment at this stage.  Just by us being a bit more mindful, I imagine our documents will clean up nicely.
March 2023: a BCP that is a more normative process based on whatever we will have learned through experience and consultations with real experts, perhaps after the results of a bit of applied research and analysis.  This will also allow for a more formal approach to corner cases, like where we are interacting with works and processes outside the IETF.
By the way, I expect the research to be iterative as well, and that sometime after 2023 we would revise again.  Also, I am hoping that what we learn from experts will benefit more than just the IETF.

Eliot
* I apologize if I have contributed to that toxicity.
** Eight months for a WG result is pretty much lightning speed.