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>