Avoid oppressive language in code base

[jettr]

Let's make the Zephyr codebase a more inclusive codebase by avoiding oppressive terms and keywords.

• We should document our expectations with regards to what terms are blocked, and when there may be exceptions. For example, following the naming convention of an external specification could allow for an exception (DONE: doc: Add inclusive language coding guideline #30508)

• We should introduce an automated check for each pull request to scan for blocked words. We would also need a way to suppress a warning/error if the instance was allowed via above to-be-documented policy

• We should audit the current codebase for existing instances of oppressive terms and replace them. This should include the names of git branches like master.

As a first round, we could specifically target to remove the following terms: master, slave, whitelist, and blacklist

Suggested alternatives include

• master - main, controller
• slave - peripheral, replica
• blacklist - deny list, block list
• whitelist - allow list, approve list

List of sub-issues for different components:

• I2C: Update terminology related to I2C #27033.

[jettr]

@ioannisg @nashif @MaureenHelm @carlescufi fyi. I didn't find an existing issue to track this.

[jfischer-no]

I suggest to follow Linux Kernel, https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=49decddd39e5f6132ccd7d9fdc3d7c470b0061bb

[jettr]

I like the idea of consistency. Are you suggesting that we use the kernel's recommend replacements or something else about that commit?

[pabigot]

I hadn't seen this; for I2C I have #27033.

[jettr]

I hadn't seen this; for I2C I have #27033.

Do you prefer to merge the two issues or keep them separates since the one you filed is more targeted to the I2C subsystem?

[pabigot]

I'd like to keep I2C separate; the changes are likely to be made one subsystem at a time anyway.

[sslupsky]

I believe that for API's created / defined in the Zephyr codebase, this is a good approach. However, for API's that are defined by external standards (USB, I2C, CAN, etc), it seems necessary that changes have to be addressed with the standards first.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.

[github-actions]

This issue has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this issue will automatically be closed in 14 days. Note, that you can always re-open a closed issue at any time.