Re-sending Maarten’s email for quick reference, since we’re on this topic.

From: Koning, Maarten <maarten.koning@windriver.com>
Sent: Saturday, May 15, 2021 1:04 PM
To: OpenAMP TSC <tsc@lists.openampproject.org>
Cc: Nathalie Chan King Choy <nathalie@xilinx.com>; Tomas Evensen <tomase@xilinx.com>
Subject: Biased terms

Hi all,

Below is some WR material on terminology that I would like to put forth as draft terminology guidelines for consideration by the group.

Maarten

Guidance

- use inclusive language in documentation to support a diverse audience and to avoid distracting terminology.

- when a biased term in project is encountered, notify the TSC for remediation

- if there is risk that the replacement term is unclear to the audience, you can mention the industry-standard term verbally (for now), but not in writing.  E.g.: “Open box testing (also known white-box testing) is a method of software testing that tests internal structures or workings of an application, as opposed to its functionality.”

- do not use the below biased terms in your documentation; use the provided replacement terms.

Biased term	Replacement term
black-box testing	closed box testing
black hat	illegal
blacklist	forbidden list
cripple	slow, break, limit, or alter the functionality
dummy packet	test packet
dummy variable	placeholder variable
female adapter	socket
grandfather	legacy
grey-list	inspect list
male adapter	plug
man hours	labor hours or work hours
man-in-the-middle (MITM)	person-in-the-middle (PITM)
manpower	labor or workforce
master (outside of the master/slave context)	main
master/slave	For high availability: active/standby For clocks: primary/secondary For virtualization: host/guest For services: server/client For notifications: publisher (or provider) / subscriber For other scenarios: initiator/responder
middleman	middle person
owner	main
white-box testing	open box testing
white hat	legal
whitelist	allow list

<snip>