Re: IESG Statement On Oppressive or Exclusionary Language

Joseph Touch <touch@strayalpha.com> Fri, 24 July 2020 02:01 UTC

Return-Path: <touch@strayalpha.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 ED8803A060A for <ietf@ietfa.amsl.com>; Thu, 23 Jul 2020 19:01:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.319
X-Spam-Level:
X-Spam-Status: No, score=-1.319 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, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.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 v3f5SpiWBD9Z for <ietf@ietfa.amsl.com>; Thu, 23 Jul 2020 19:01:11 -0700 (PDT)
Received: from server217-4.web-hosting.com (server217-4.web-hosting.com [198.54.116.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09C593A05AC for <ietf@ietf.org>; Thu, 23 Jul 2020 19:01:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=To:References:Message-Id: Content-Transfer-Encoding:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Cc:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZVFCPo9wBt/9nJw88fMwAHXtZ9bIlIqWj/ewWebyEcA=; b=vg3VR1n1rnx41x2dK2sI4yxNQ vL9Z0SQj1InG2jrmj583MGlE67E3CySU87kO34oWLpf/nUaqD+01GebJ0v1xtAYpB1bBu7ogDNF22 qjoU5IqUbqCfyhJdYT55KuVCI7Klw2I6yhZOJgp5tTwuYPuWRodWL1i+xecJYxTbmyBPfLLkWfE0h esbbAtV4PNP0dZYDIvwdEhg9P0Lp58baK+Efrghw24u6Q6/OocakccyufQCGMGMX+bOMwpV1rlNxJ kQ5+g5Gvs1pKOCr0g+Iy8FF3UZNIpNC5EPxVH700L7YHdjq/Ea8Hri1967wgluQjuhqemUCkbCaPr icHn9jRBA==;
Received: from cpe-172-250-225-198.socal.res.rr.com ([172.250.225.198]:51958 helo=[192.168.1.14]) by server217.web-hosting.com with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from <touch@strayalpha.com>) id 1jyn1G-000BaI-0p; Thu, 23 Jul 2020 22:01:10 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.1\))
Subject: Re: IESG Statement On Oppressive or Exclusionary Language
From: Joseph Touch <touch@strayalpha.com>
In-Reply-To: <462DDF07-A04D-4438-B854-1F52E0A7FB3D@strayalpha.com>
Date: Thu, 23 Jul 2020 19:01:05 -0700
Content-Transfer-Encoding: quoted-printable
Message-Id: <21A24A5E-2586-403D-AE56-1349BDAF7C66@strayalpha.com>
References: <159552214576.23902.6025318815034036362@ietfa.amsl.com> <462DDF07-A04D-4438-B854-1F52E0A7FB3D@strayalpha.com>
To: IETF list <ietf@ietf.org>
X-Mailer: Apple Mail (2.3608.120.23.2.1)
X-OutGoing-Spam-Status: No, score=-1.0
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server217.web-hosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - strayalpha.com
X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com
X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com
X-Source:
X-Source-Args:
X-Source-Dir:
X-From-Rewrite: unmodified, already matched
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/zSkOp6M-6x3mdLaNVJtYPCxcRoA>
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: Fri, 24 Jul 2020 02:01:12 -0000

FYI - in case it wasn’t clear:

a) I’m serious (this isn’t reductio ad absurdum) 
b) writing more professionally/collegially is more than just addressing two sets of terms

Joe

> On Jul 23, 2020, at 1:50 PM, Joseph Touch <touch@strayalpha.com> wrote:
> 
> Hi, all
> 
> I think this doc could be more useful if it leaves the discussion and debate of context to a single background section with at most one paragraph each on a few examples. Instead, it should spend more time providing groups of suggested alternatives with explanations as to when each might be more accurate, e.g.:
> 	
> 	primary-secondary	when limited to two instances, one of which is privileged
> 	primary-replica	when more than two instances are possible, one of which is privileged
> 
> I agree that none of this doc should mandate when to use any particular alternate, but it should say that documents SHOULD NOT use the exclusionary language except in direct reference to legacy uses. Leave it to the community and RSE to help clean things up - and yes, tools help here too.
> 
> (i.e., I can’t see how we can get around pointing out the correspondence between current and legacy terms in future docs or external standards, not just here).
> 
> FWIW: alternates for primary-replica when one is in control could be:
> 
> 	leader-follower
> 	commander-subordinate
> 
> Recognizing that this doc can never be complete, we should scrub the current RFCs for terms that we think should - or could - be used. Below are a few I found that we either need to provide alternatives for or explain are not currently known as problematic (i.e., a more complete ‘accept/deny’ list). It would also help to point out that the list should include other areas, such as:
> 
> 	ageist terms
> 	sexist terms
> 	disability terms
> 
> Joe
> 
> --------
> 
> Additional “deny” list (note that most of these I either found in RFCs are other tech literature):
> 
> 	grandfather(ed)
> 		legacy/legacied
> 
> 	whitewash
> 		(none - euphemism that may be better phrased directly)
> 
> 	black and white (referring to binary decisions with clearly desirable outcomes)
> 		(none - euphemism that may be better phrased directly)
> 
> 	gyp (as in to short-change or cheat)
> 		cheat/swindle
> 
> 	greybeard (as senior member of a community)
> 		senior member
> 
> 	greylist (because it is derived from white/blacklist)
> 		partial accept/admit
> 
> 	minon
> 		follower/subordinate
> 
> 	dummy
> 		placeholder
> 
> 	sanity check / reality check
> 		validity check / correctness check / confidence check / quick check
> 
> 	bitch
> 		complain
> 
> 	hobbled
> 		undermined / made less effective by 
> 
> 	there’s also the question of whether we can avoid gendered terms for people (he/she/guys/dude, his/her)
> 
> “Accept” list (or at least I think they are; please point out if otherwise):
> 
> 	black/red as network security levels
> 
> 	black and white referring to images (i.e., binary greyscale)
> 
> 	dark web/net
> 
> 	grey web/net (as in partially dark)
> 		FWIW, I prefer “dim” to grey as being more clear, but that’s me
> 
> 	white pages / yellow pages (refers to historical use of paper of those colors to publish phone directories)
> 
> 	white paper (a brief though-piece)
> 
> 	black hole
> 
> 	black box
> 
> 	red/green, red/yellow/green
> 
> 	red (as a warning or error)
> 
> Joe