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

Keith Moore <moore@network-heretics.com> Thu, 29 April 2021 20:17 UTC

Return-Path: <moore@network-heretics.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 51C443A0C3C for <terminology@ietfa.amsl.com>; Thu, 29 Apr 2021 13:17:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_NONE=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=messagingengine.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 ccmuv5W8StPH for <terminology@ietfa.amsl.com>; Thu, 29 Apr 2021 13:17:36 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D95F3A0C3A for <terminology@ietf.org>; Thu, 29 Apr 2021 13:17:36 -0700 (PDT)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 0F096FBD for <terminology@ietf.org>; Thu, 29 Apr 2021 16:17:31 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute3.internal (MEProxy); Thu, 29 Apr 2021 16:17:32 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=XXdfGQYWckKKM70O8nCN2NlyKdOikwqGU9gNos2/y p8=; b=q9pwmHojdO7BLQ6Ks9kOeM8mMjAZEkyNY6mv8zLGl2X8HCRCrkAGqExPw +IlNBJ21L+n97TvbJMA8wDMOn+EM4c5MHZfENWx8vO2xjSHuRu9JLhSfKz0XpplL 3ehcCZ+zNQ4uBvZlYq7881paKMoi9gScFirdsQNJmWUQscH0P9JotTV9KEPT4nu2 o86OmOw2W8yrRHw7oYnUjO3RNinLKv+DPHLGMLQTXqWflUTZFvL3XJigYCmr62YI T0lKXEPMZJCSrIaz3FRy0VeusfUMc8O6vInNpkHHkIj8/uGeJNXYu1Fx8eNFuwqN iLHWyEAs4OOdqqEdnI18I8v1cLmJA==
X-ME-Sender: <xms:WhSLYNk-nZpiALR9e0fcEj_R1DNat54HRQKPDGxE-21pZxCXTHoM8A> <xme:WhSLYI3UbIHDXr7yysesiNLIumIFYOz855qxg1T4HP0CnH3kAc_Tf-0pWqU2ZERgK cKnZiVwjW47FQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvddvgedgudeglecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecufghrlhcuvffnffculddqiedmnecujfgurhepuf fvfhfhkffffgggjggtgfesthekredttdefjeenucfhrhhomhepmfgvihhthhcuofhoohhr vgcuoehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomheqnecuggftrf grthhtvghrnheptdehueeijeeileduieduuedvudevvedtgfffveekueejgffhleeitdel heffueehnecuffhomhgrihhnpehnihhsthdrghhovhdpughoihdrohhrghenucfkphepje efrdduudefrdduieelrdeiudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhep mhgrihhlfhhrohhmpehmohhorhgvsehnvghtfihorhhkqdhhvghrvghtihgtshdrtghomh
X-ME-Proxy: <xmx:WhSLYDqGqRH6RlqKc6dCl_EK-BXaws0zAsbymqh15sBeXFfu00TIeg> <xmx:WhSLYNmuISIFGFq_KtCLMfG-Gvg_XojKSgSL_IWzn6e-7VkqxjmWmQ> <xmx:WhSLYL0svmWHZPsLO2E3ZBxQ7pdDMkGIXb3kvf0V_h1Xf8IJ4VmR5g> <xmx:WxSLYC3Ol7sXSSJgAzQZn0fvN8Eufkr7_sm9wLfX340Ibyk4VT9cCA>
Received: from [192.168.30.202] (c-73-113-169-61.hsd1.tn.comcast.net [73.113.169.61]) by mail.messagingengine.com (Postfix) with ESMTPA for <terminology@ietf.org>; Thu, 29 Apr 2021 16:17:30 -0400 (EDT)
To: terminology@ietf.org
References: <CAFfrZstRpSrbc5X6OhPsAiiER1srh3aHEuS1sLYsghUJz4PO5g@mail.gmail.com>
From: Keith Moore <moore@network-heretics.com>
Message-ID: <7ab5d973-7c8e-cdaa-823b-d22395447455@network-heretics.com>
Date: Thu, 29 Apr 2021 16:17:29 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.7.1
MIME-Version: 1.0
In-Reply-To: <CAFfrZstRpSrbc5X6OhPsAiiER1srh3aHEuS1sLYsghUJz4PO5g@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/terminology/TojqtAN0tfu8uh_dfYqTesmvYy8>
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:17:42 -0000

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.

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