rfc7: add item about inclusive language

[garlick]

Shall we add a statement about inclusive language to our style guide?

As an example the following patch was proposed on LMKL:

https://lkml.org/lkml/2020/7/4/229

Their coding-style.rst change is:

diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst
index 2657a55c6f12..4b15ab671089 100644
--- a/Documentation/process/coding-style.rst
+++ b/Documentation/process/coding-style.rst
@@ -319,6 +319,18 @@ If you are afraid to mix up your local variable names, you have another
 problem, which is called the function-growth-hormone-imbalance syndrome.
 See chapter 6 (Functions).
 
+For symbol names, avoid introducing new usage of the words 'slave' and
+'blacklist'. Recommended replacements for 'slave' are: 'secondary',
+'subordinate', 'replica', 'responder', 'follower', 'proxy', or
+'performer'.  Recommended replacements for blacklist are: 'blocklist' or
+'denylist'.
+
+Exceptions for introducing new usage is to maintain a userspace ABI, or
+when updating code for an existing (as of 2020) hardware or protocol
+specification that mandates those terms. For new specifications consider
+translating specification use of the terminology to the kernel coding
+standard where possible. See :ref:`process/inclusive-terminology.rst
+<inclusiveterminology>` for details.
 
 5) Typedefs

Plus there's a new inclusive-terminology.rst document that we could perhaps cite if we want.

[dongahn]

Good idea.

'secondary',
+'subordinate', 'replica', 'responder', 'follower', 'proxy', or
+'performer'.

"worker" would be another replacement which I hear often one of these days.

Do you want to also add terms like "master" and "whitelist" as well? I plan to replace "whitelist" too allowlist in Fluxion. I don't know what to do w/ master though when the main trunk is called "master."

[chu11]

Shall we add a statement about inclusive language to our style guide?

Seems like a good idea. Perhaps we should pick a convention that we prefer? i.e. leader/follower, blocklist/allowlist, or what not? (I think leader/follower is what I've done in my few PRs).

I don't know what to do w/ master though when the main trunk is called "master."

Github is apparently going to be changing the default. I'd suggest we wait to see what default they choose, then we can manually adjust our repos to that.

[chu11]

I plan to replace "whitelist" too allowlist in Fluxion.

Doh! I had missed that while trying to update all the flux projects (I think I only grepped "master", "slave", and "blacklist"). I can fix that up quick.

[dongahn]

Doh! I had missed that while trying to update all the flux projects (I think I only grepped "master", "slave", and "blacklist"). I can fix that up quick.

Sorry I didn't let you know earlier.

flux-framework/flux-sched#669

[grondo]

Perhaps we should pick a convention that we prefer? i.e. leader/follower, blocklist/allowlist, or what not? (I think leader/follower is what I've done in my few PRs).

I think it might depend on context. We don't want to as restrictive as, say, pylint in our naming conventions. I like the list of suggestions from the doc @garlick referenced.

For allowlist I also see that Travis-CI uses safelist as an alternative.

Another idea, we could enhance pr-validator to check for commits that introduce non-inclusive terms and post a warning or error.

[chu11]

I think it might depend on context. We don't want to as restrictive as, say, pylint in our naming conventions. I like the list of suggestions from the doc @garlick referenced.

Agreed there is context and we wouldn't always want to restrict to certain ones. Just don't want people to start calling some code "coordinator-worker" when we use "leader-follower" in other places. But I guess code-reviews will be good enough to catch those cases.

[grondo]

Good point!