Re: IESG Statement On Oppressive or Exclusionary Language

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

 



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