Hi Tomas, Maarten, Jeff,

Thanks, Maarten.

Tomas: I propose that everyone can send to the TSC mailing list to facilitate asynchronous discussion, and then I’ll just link to this email thread in the mailing list archives from the OpenAMP Wiki.

@Hancock, Jeffreymailto:Jeffrey_Hancock@mentor.com: If you have a draft of Mentor’s initial thoughts & could share before/at the TSC meeting that would be great.

Also, a question to discuss at the TSC meeting related to this topic: Should we try to align with this project: https://inclusivenaming.org/blog/_posts/welcome-post/ ? (I’m not sure if it is a Linux Foundation project, or just a project with a bunch of Linux Foundation members involved)

Thanks & regards, Nathalie

From: Tomas Evensen tomase@xilinx.com Sent: Monday, May 17, 2021 8:18 AM To: Koning, Maarten maarten.koning@windriver.com; OpenAMP TSC tsc@lists.openampproject.org Cc: Nathalie Chan King Choy nathalie@xilinx.com Subject: Re: Biased terms

Thanks Maarten.

Nathalie, Can we create a global place (google docs, github, something else?) where we can put this and potential other proposals so we can refer to them with links?

Tomas

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

CAUTION: This message has originated from an External Source. Please use proper judgment and caution when opening attachments, clicking links, or responding to this email.

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>

All,

While looking for the Zephyr MISRA-C rules (also on the page below) I found there section on biased terms.

https://docs.zephyrproject.org/latest/contribute/coding_guidelines/index.htm...

That also referenced the kernel doc patch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?i...

I am hoping that Zephyr currently has a typo and that "leader" (by itself anyway) is not considered offensive. Certainly leader with slave would be offensive but so would any use of slave by itself.

The kernel considers leader a valid replacement for master.

Bill

On 9/22/21 5:35 PM, Nathalie Chan King Choy via Tsc wrote:

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>

-- Tsc mailing list Tsc@lists.openampproject.org https://lists.openampproject.org/mailman/listinfo/tsc