Re: [Terminology] Guidance for NIST Staff on Using Inclusive Language in Documentary Standards (NISTIR 8366)

Brian E Carpenter <brian.e.carpenter@gmail.com> Thu, 29 April 2021 20:50 UTC

Return-Path: <brian.e.carpenter@gmail.com>
X-Original-To: terminology@ietfa.amsl.com
Delivered-To: terminology@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 824013A0E1E for <terminology@ietfa.amsl.com>; Thu, 29 Apr 2021 13:50:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 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, FREEMAIL_FROM=0.001, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 VX-5zCwMEfYs for <terminology@ietfa.amsl.com>; Thu, 29 Apr 2021 13:50:38 -0700 (PDT)
Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 064DC3A0E1F for <terminology@ietf.org>; Thu, 29 Apr 2021 13:50:37 -0700 (PDT)
Received: by mail-pj1-x102b.google.com with SMTP id gj14so3397752pjb.5 for <terminology@ietf.org>; Thu, 29 Apr 2021 13:50:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=zSPNPE9GaCbef4M2DG7O2ZpUAKyvcDnxb6o0+z4TuwU=; b=fMg4y+/WKwrQgQ21x13G3bORpqc7KaejqUWO5W1r734ICG9E3MWJyaK2aK+eeZTns+ MQRV1GAvFXsuaKfBTcX13OmagobchySbSga70jlr3AdelSPDPebnDB5ssVhUcyX3fnD7 3wc7ca4DYh1Kc8WhDa4jHqSlm6fGXGTrdFsAeyXWz2yOoaltety9973zA6DlPBxVK/wD WKwk1Jcjvlr5c9T2LCysUsuRSjQIWxBdKxW7xadhxh4H6bbWIjI49nSjTXf40oNa04dF lkcJ6QMGghy791lDbQzjydo1GEz08ZaR34A+CMatB5KvpKRV47iBEqhFRXglFTjWwDN0 1r1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=zSPNPE9GaCbef4M2DG7O2ZpUAKyvcDnxb6o0+z4TuwU=; b=YtGpOYFTN/es+2Afj0L+OcL/oPUtJxaBYH3zr+7q6JoXXHPtLCT40UtNHSghF4qfqD NvZzA2RBB39ah1irRQ1Hcvw2f1PM8+6h0R3MjgeU2m4kpDUtBy1swafV5W65+vfIuCo5 n0/56DyWFuRQkUgkGCqWceO99hEQu/g/BjTI5QMYTc7liZ8tBkpM7iFQRdFTR42Nsb25 VHpSbmZskvLz4WM7bmVCKtee0zq6koQnBHCImJTovIMOfcJ67tMxUraSiOPNYI/1C0Dk BiuIRHb7jM6JEfl0LgtVVd+XCK2AY2DGm57YVhlU/nucQiqusPpW91/v4hyDj/C3i6j7 jkCg==
X-Gm-Message-State: AOAM5322Z+dvezsV38KEcf7fITxGnyjE/4qtzPb0916+kud8lXTl1nGc lTxkHPGqx61YrONNGPunYeJdgZ26bvXO6g==
X-Google-Smtp-Source: ABdhPJyUmgoJ9vVYwgjZVtgVEGnC8AMEs80yZop6ijxo+LEsaZxSVyb4pTtGDAlz85LsI8NgLDmQ/A==
X-Received: by 2002:a17:90a:1a47:: with SMTP id 7mr10695437pjl.84.1619729436831; Thu, 29 Apr 2021 13:50:36 -0700 (PDT)
Received: from [192.168.178.20] ([151.210.131.14]) by smtp.gmail.com with ESMTPSA id w14sm3591187pff.94.2021.04.29.13.50.34 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 29 Apr 2021 13:50:36 -0700 (PDT)
To: Keith Moore <moore@network-heretics.com>, terminology@ietf.org
References: <CAFfrZstRpSrbc5X6OhPsAiiER1srh3aHEuS1sLYsghUJz4PO5g@mail.gmail.com> <7ab5d973-7c8e-cdaa-823b-d22395447455@network-heretics.com>
From: Brian E Carpenter <brian.e.carpenter@gmail.com>
Message-ID: <57eaa15c-9230-68f7-063e-4a5558106dd3@gmail.com>
Date: Fri, 30 Apr 2021 08:50:35 +1200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <7ab5d973-7c8e-cdaa-823b-d22395447455@network-heretics.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/terminology/c46aGfsuQMvdE9Ev73u2oxH9cN4>
Subject: Re: [Terminology] Guidance for NIST Staff on Using Inclusive Language in Documentary Standards (NISTIR 8366)
X-BeenThere: terminology@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Effective Terminology in IETF Documents <terminology.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/terminology>, <mailto:terminology-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/terminology/>
List-Post: <mailto:terminology@ietf.org>
List-Help: <mailto:terminology-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/terminology>, <mailto:terminology-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Apr 2021 20:50:43 -0000

On 30-Apr-21 08:17, Keith Moore wrote:
> On 4/29/21 3:45 PM, Nick Doty wrote:
>> Today, NIST has published this Internal Report on "using inclusive 
>> language" publicly, in part because it may be useful to other 
>> standards groups interested in clarity and inclusiveness of terminology.
>>
>> Blog post/announcement:
>> https://www.nist.gov/news-events/news/2021/04/nists-inclusive-language-guidance-aims-clarity-standards-publications 
>> <https://www.nist.gov/news-events/news/2021/04/nists-inclusive-language-guidance-aims-clarity-standards-publications>
>>
>> NISTIR 8366:
>> https://doi.org/10.6028/NIST.IR.8366 
>> <https://doi.org/10.6028/NIST.IR.8366>
>>
>> I think both the blog post and the report itself do a good job of 
>> describing the particular goals, including some examples (but not 
>> especially long lists), and pointing to other resources that might be 
>> useful for writing standards that are clear and respectful to a wide 
>> range of readers.
>>
>> Hope this helps,
>> Nick
> 
> I could _almost_ support just using this document, especially if it 
> would get IETF out of the business of trying to write its own.   Then we 
> could all just get back to work.

Yes. The IESG could suggest to the RFC Editor team to add an informative
reference to the NIST document to the style guide, and remind the IETF
that Internet-Drafts should aim to adhere to the RFC style guide,
and we're done.

(Clearly NIST is not international in scope, and the IETF is, but since
our shared working language is more or less American English, it seems
reasonable.)

> A couple of its examples are problematic, and are actually good examples 
> of why such guidelines can do harm to the readability of technical 
> documents.
> 
> One that stood out is recommending use of plug/socket rather than 
> male/female connectors.   Even though the gender analogy is cringeworthy 
> (along with the term androgynous connector), the terms male and female 
> as applied to connectors are actually MUCH more precise, because there 
> are many kinds of connectors for which the male and female ends are much 
> more obvious than the plug vs. socket designations.   (There are 
> exceptions, like "reverse polarity" SMA and TNC connectors for which the 
> female connector is the one with the inner pin, but mostly this 
> convention works well and it's hard to replace.   plug/socket 
don't do it.)
> 
> Another example is recommending against use of "totem pole" as a 
> priority scheme, but "totem pole" is actually the established term of 
> art for a kind of electrical circuit, and again not easily replaced.
> 
> Neither of these would probably affect IETF very much though since we're 
> not generally in the business of specifying connectors or electrical 
> circuits.
> 
> Keith
> 
>