Re: IESG Statement On Oppressive or Exclusionary Language

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxx> 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





[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux