Starting the conv around the suggestion list

[Karthikeyan Govindaraj]

Hi All, 

In addition to @Celeste Horgan 's email, I have a list of few terminologies curated. I would like to get all your thoughts whether or not these are something we should add.

My intention here is to create an alternative suggestion list for offensive wordings not just to the developers, also to people who are affiliated in any way with Kubernetes Community/CNCF Community.

Area/terminologies	Suggestion	Area found in k8s org	Search URL for k8s org
minority	very few/underrepresented	ssues and merge requests	https://github.com/search?q=org%3Akubernetes+%22minority%22&type=Issues
abort	terminate/stop/end/suspend/halt	issues and codes across all over k8s org	https://github.com/search?q=org%3Akubernetes+%22abort%22&type=Code
black box	mystery	issues and blog posts	https://github.com/search?q=org%3Akubernetes+%22black+box%22&type=Code
guys	people/folks/team	issues and case studies	https://github.com/search?q=org%3Akubernetes+%22guys%22&type=Code
man hours	workforce/human hours	Issues and case studies	https://github.com/search?q=org%3Akubernetes+%22man+hours%22&type=Issues
black-holed	dropped/ignored/discarded	Issues and commits	https://github.com/search?q=org%3Akubernetes+%22black-holed%22&type=Issues
lower the bar	reduce expectation	issues and MRs	https://github.com/search?q=org%3Akubernetes+%22lower+the+bar%22&type=Issues
freshman	first year student	issues	https://github.com/search?q=org%3Akubernetes+%22freshman%22&type=Issues

Please let me know if this is a good idea to add/discuss on the above list. 

---

Many Thanks,

Karthik

Karthikeyan Govindaraj

DevOps Architect | OSS Enthusiast | Blogger

Know Me!

[Swarna Podila]

I really appreciate Karthik's input here.  Huge +1.

- Swarna Podila (she/her),

Director, Audience Marketing

swa...@hashicorp.com | @skpodila

You can read more about pronouns here, or please ask if you'd like to find out more.

--
You received this message because you are subscribed to the Google Groups "Kubernetes WG Naming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-na...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-naming/CAG2XbAsAJTG%3Dh%2BuQdQhbUO7OsUpDMxQXYMW9JX5bU4PgKkLVug%40mail.gmail.com.

[Karthikeyan Govindaraj]

My pleasure! Lets keep on adding to the list even if we are not discussing right away.

I feel like treasure hunting 😉 

---

Many Thanks,

Karthik

Karthikeyan Govindaraj (he/him)

DevOps Architect | OSS Enthusiast | Blogger

Know Me! | @gkarthics

[Celeste Horgan]

I love all of these!

Do we need any discussion around them? :)

Celeste

[Zach Corleissen]

+1 to Karthik's suggestions.

All of these seem reasonably evident and adoptable. 

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-naming/93dc3e8d-4191-45a1-895f-a450d95a7a9bn%40googlegroups.com.

--

Zach Corleissen

Lead Technical Writer, Linux Foundation

[Jordan Liggitt]

Can you clarify what adopting these suggestions would mean? I can imagine a spectrum of possibilities:

• a list of terms / alternatives contributors should be aware of and consider as an "FYI"
• a list of words people writing documentation and designing APIs must avoid
• a list of words anyone commenting on a Kubernetes issue should avoid
• if someone makes a comment that shows up in one of the linked queries, it is considered a code of conduct violation

We should be explicit about where/how these recommendations will be applied. From the working group goals (emphasis added):

> Define how any member of the Kubernetes project can recommend language, how others can evaluate that proposal, and how to implement replacements across all codebases.

As an example, our website/documentation has a style guide in order to keep a consistent voice and to refer to concepts in a uniform way. Its requirements are applied when contributors submit a documentation PR. However, that style guide is not applied to issue descriptions / comments / slack discussions, etc. The more broadly and stringently we intend to apply a recommendation, the clearer and stronger the rationale should be.

For the specific terms suggested, it is easy to see how many of them could be used in an offensive way, but it is not clear that all of them are inherently offensive, especially:

• minority
• abort
• black box
• guys
• black-holed
• lower the bar
• freshman

Words or phrases can be problematic or exclusive when used in some ways or in some contexts, and be fine in others. As an example, "freshman" to describe a generic inexperienced person is not great (and labeling someone else as inexperienced might be questionable anyway). Someone choosing to refer to themselves as a freshman is fine (and all of the instances in the linked query were of the latter use).

It's important to be clear about the reasons why a word or phrase should be avoided:

• Some reasons don't apply in all contexts. For example, localization / translation considerations would definitely inform use in project blog posts, documentation, APIs, and published examples, but wouldn't be applied in non-translation contexts like issue comments.
• If the actual meaning/use of the word is the problem, then replacing it with an alternative that means the same thing doesn't seem like an improvement. For example, using "lower the bar" to communicate "reduce expectations in an inequitable way" should be avoided, not just replaced with a different-but-equivalent phrase. Using it to mean "make an unnecessarily difficult thing easier" is commendable and in line with how I'd want to see people in our community treating each other and our users (and is what many of the uses in the linked query were communicating).
• For claims that a term cannot be disassociated from a problematic meaning/use regardless of how it is used or in what context, how is that claim evaluated, and what standard is used to determine when the problematic association is tenuous and meaning-in-context should rule?
  

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-naming/CABAQYeCj5W37zdrtFLujFQy631jVZshPmwSForm246bbzW8-Eg%40mail.gmail.com.

[Celeste Horgan]

Hi Jordan,

So I think your email raises three points that we need to discuss:

1. What does adopting a suggestion mean?
2. Does this WG want to cover changes that do not have code changes attached to them?
3. How do we evaluate what to adopt, aside from throwing a +1 beside it?

For #1, what does adopting a suggestion mean: I think that this has to vary from suggestion to suggestion. In the case of Karthik’s list, I actually think we need to parse these out case-by-case.

Which brings us to #2 – does the WG care about changes that do not have code attached to them? I think the WG should focus on wording that specifically affects code, but feel free to argue otherwise, folks.

And finally, #3 – how do we evaluate what we want to adopt?

I can’t speak for anyone else, but I’ve been consistently following two principles: does a term cause harm to someone, or create a barrier to contribution; and, if we remove or change that term, will we cause less harm and provide greater welcome?

No word is inherently offensive. Words are just sounds and letters – that’s it. The context of a specific word (for example, master) changes over time. Something that may start out innocent may end up being quite painful for some. In other cases, for example the word queer, a word that was once used to cause pain can be reclaimed by a community. As such, my first principle is this: does this word cause harm to someone? Can we cause less harm to someone by using something different?

Secondly: If we replace a word or term, does something make more sense? Is it easier to translate, clearer, or easier to understand? If so, then we should consider making the change, even if the original term wasn’t overly harmful.

Viewed through that lens, here’s how I evaluate Karthik’s changes:

* minority – In the context of representing non-human things which are, indeed, a minority, I don’t think this is offensive. When referring to humans, however, it’s problematic on a fundamental level.
* abort – As a woman, not a fan. It feels violent. I prefer to think about abortion – and indeed, my uterus – in my workplace as little as possible. I imagine women who have gone through abortions might feel similarly. The replacements suggested for this one, however, are a bit difficult – “abort” vs. “terminate” vs. “end” vs. “stop” are somewhat loaded terms in computing.
* black box – I personally feel no offense at the idea of a black box, however others might. What I did like about Karthik’s suggestion is that “mystery” is more easily translatable and clearer.
* guys – There are lots of members of the community who don’t identify as guys. There are prominent community members who identify as non binary and indeed, deeply dislike being attached to the word guys. We should remove this, though I admit I struggle to stop using it too :)
* black-holed – This is not inherently offensive.
* lower the bar – This is not inherently offensive.
* freshman – This is not inherently offensive.

One thing I’d like to point out about the “not inherently offensive” ones, however, is that the alternatives given are clearer, less idiomatic, and easier to translate.

Jordan, are there any other principles we need to consider when evaluating language? How did you view and evaluate Karthik’s changes, and what do you think we need to consider?

Cheers,
Celeste

[Karthikeyan Govindaraj]

I think the list created a little bit of confusion on the "How to adopt?" part. I agree on @Celeste Horgan 's explanation for that. This has to be done case-by-case in this instance. Haven't really thought about the implementation details back then.

But now, on the implementation details I was thinking a little bit inclusive for both speakers and coders as well. Was thinking of something like the below list to be displayed; may be in https://k8s.dev. The people involved with Kubernetes in any way either Coders or Speakers, can refer to a list something like below.

S No	Words	Level of acceptance		Alternative recommendation	Context Suggestions	Notes	Approved by WG Naming
		Speaker	Coder
1	master/slave	Must not	Must not	Leader/follower	Like etcd clusters		UNDER REVIEW
				Parent/child	applications
				Control plane/control plane node	In k8s
				Controller/Developer
				primary/replica	In Databases
				active/standby	In Databases
				readers/writer	In redis clusters, elastic clusters
				active/passive	In Databases
2	whitelist/blacklist	Must not	Must not	allowlist/denylist	In networking		UNDER REVIEW
				allowedNouns/deniedNouns	-
3	minority	May not	May not	very few	Referring peoples	Must not use to address/represent people	PENDING
				underrepresented	referring peoples
4	abort	Must not	Must not	???	???		PENDING
5	black box	May not	May not	mystery	testing		PENDING
6	guys	Must not	Must not	folks	Referring people		PENDING
				team	Referring people
				people	Referring people
				kubefolx	Referring people
7	black-holed	May not	Ok	dropped	Networking packets	This is not so offensive term. May be ok to use this.	PENDING
				discarded	Networking packets
				ignored	Networking packets
8	lower the bar	May not	ok	reduce expectation	explaining the constraints	This is not so offensive term. May be ok to use.	PENDING
9	freshman	May not	Ok	first year student	While referring the experience	This is not so offensove term; when one is referring to themselves.	PENDING
10	man hours	May not	May not	human hours	While referring to the effort needed		PENDING

Also can enforce in the code base with some YAML structure like 

---
word: master/slave
speaker: must not
coder: must not
alternativeRecommendations:
- alternativeWord: Leader/follower
  contextSuggestion: Like etcd clusters
- alternativeWord: Parent/child
  contextSuggestion: ""
- alternativeWord: Control plane/control plane node
  contextSuggestion: In k8s
- alternativeWord: Controller/Developer
  contextSuggestion: ""
- alternativeWord: primary/replica
  contextSuggestion: In Databases
- alternativeWord: active/standby
  contextSuggestion: In Databases
- alternativeWord: readers/writer
  contextSuggestion: In redis clusters, elastic clusters
- alternativeWord: active/passive
  contextSuggestion: In Databases

 which has a word in discussion "master/slave" and the level of acceptance for "coder" and "speakers" followed by the array of objects having the alternative word and its context suggestion.

For >> Define how any member of the Kubernetes project can recommend language

Using the above YAML in a WG Naming code repo, any one should be able to create a PR and WG Naming should hold the decision on approving the suggestions. Once approved, the suggestions will be automatically added to the above display in any website.

And may be in case of the speakers, if anyone is not adhering to the inclusive code of conduct, we can mandate them to take the "Inclusive language" course from LF.

Lets keep brainstorming. I like this WG Naming already, Working carefully and inclusively for inclusiveness. 😊

--

Many Thanks,

Karthik

Karthikeyan Govindaraj (he/him)

BlackRock,

DevOps Architect | OSS Enthusiast | Blogger

Know Me! | @gkarthics

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-naming/27da87ca-2005-4e3d-b4c5-a050a6dacf20n%40googlegroups.com.

[Jordan Liggitt]

1. What does adopting a suggestion mean?
2. Does this WG want to cover changes that do not have code changes attached to them?
3. How do we evaluate what to adopt, aside from throwing a +1 beside it?

 

For #1, what does adopting a suggestion mean: I think that this has to vary from suggestion to suggestion. In the case of Karthik’s list, I actually think we need to parse these out case-by-case. 

 

Which brings us to #2 – does the WG care about changes that do not have code attached to them? I think the WG should focus on wording that specifically affects code, but feel free to argue otherwise, folks.

 

And finally, #3 – how do we evaluate what we want to adopt?

I think clarity around where recommendations are to be applied, and rationale for recommendations are exactly what this WG should establish. The earlier we can set up that framework, the more efficient and consistent evaluation of particular suggestions can be. I imagined a framework where this WG:

1. enumerates contexts to apply recommendations to, e.g.:
• website, documentation, API documentation, k8s.io blog posts, etc
• user-visible programmatic names (APIs, type names, field names, command-line flags, etc)
• developer-visible names (comments, variables, etc.)
2. enumerates categories for recommending against using a term, e.g.:
• unclear/ambiguous
• idiomatic expressions
• difficult to translate/localize
• non-inclusive (e.g. "man hours")
  
• violent (e.g. "shot the node in the head")
• offensive or socially-charged (e.g. "master/slave")
• ...
3. enumerates potential actions to take, e.g.:
• pair with clarifying text
• prefer alternative terms
• make available via an alternative name (for example, mapping two command-line flags to the same functionality)
• deprecate in favor of an alternative
4. maps categories to recommended actions in each context (including what to do with existing instances in each context)
   
5. sets up a issue template/form/mailing-list topic template/whatever for initiating an evaluation of a given term
• having a thread/issue/whatever per suggestion is probably helpful to avoid sprawling megathreads (like this thread has become :-/), and to have a reference to a coherent discussion from the recorded outcome
• discussion around a particular suggestion can be more focused on which categories a term falls into

Jordan, are there any other principles we need to consider when evaluating language?

I had two thoughts:

• When considering barriers to participation, we also need to recognize the barrier that changing/breaking existing programmatic interfaces represents to our users. It may be warranted in some cases, but the cost should be considered and weighed against the reasons for changing. As a far-fetched example, I wouldn't expect us to recommend renaming the HorizontalPodAutoscaler API type, breaking existing users, because it was difficult to translate.
• Some categories are more objective (is this term an idiom? is this term difficult to translate? does this term exclude some members of the group it is supposedly addressing?) and some are more subjective (is this term offensive or socially-charged?). The more subjective the category, the clearer we should be about the approach we'll take to evaluate it.

How did you view and evaluate Karthik’s changes, and what do you think we need to consider?

In the context of docs/APIs, etc., I agree most of the terms have good alternatives we could recommend that are clearer, less idiomatic, easier to translate, and more inclusive.

For two of the terms, I think the suggested alternatives are less clear / accurate:

• "Abort" has a precise meaning in process lifecycle (e.g. SIGABRT/abort() in https://en.wikipedia.org/wiki/Signal_(IPC)#POSIX_signals), so if the API or documentation is describing that specific signal or scenario, the suggested alternatives are misleading/incorrect. Most terms related to stopping processes could be construed as violent in a different context (kill, terminate, abort, etc), so I'm not sure how to be clear/accurate while avoiding those entirely.
• "Black box" is usually used in these contexts:
• "Black box testing", in which tests only observe external behavior, and not the internal implementation. I'd suggest "behavioral testing" as an alternative here.
• A system being a "black box", or unobservable. "Opaque" might be a better alternative here.

[Bob Killen]

I'm a strong believer in the mission of the naming working group, but I would avoid any sort of hard-automatic enforcement of the terms being discussed. As Jordan pointed out there are things we cannot change without severely obscuring the meaning of the term making it difficult for both end-users and contributors to infer the actual meaning.

We have very clear lines with master/slave and whitelist/blacklist, but for the other potential terms I think we should lead by community example and provide guidelines that allow room for the usage where it actually is appropriate in context. That context is lost when just searching broadly for counts of terms in GitHub search =/

A few things we could do to help drive this as a community effort:

- Write inclusive language guidelines (Example: Microsoft's guide to bias free communication[1])

- Update our developers docs mentioning it should be considered when coming up with API naming schemas

- Call it out in our triage process documentation as something to evaluate when looking at an issue or PR

- As SIG leads encourage more people (owners) to take the LF inclusive language course

- Bob

[1]: https://docs.microsoft.com/en-us/style-guide/bias-free-communication

[Karthikeyan Govindaraj]

Apologies for the delayed response, was caught-up a little with chores at work.

On Jordan's thread: 100% on the side with Jordan, that the  WG Naming should have a framework. But when you mean framework, are you meaning to have this programmatically taken care or something like the Inclusive Language Guidelines from MS as Bob suggested?

Like the points put forth for barriers for participation, but on the other hand who are all allowed to propose alternatives and raise issues on offensive/non-inclusive languages? 

imho, anyone in the community should be able to raise an issue and also the (may be) a PR to some repo for alternatives suggestion.

I understood the skeleton list that I put up is mixed with clear and unclear phrases/idioms. This is also not including all the contexts as Jordan suggested. But I was unsure how to  include all the possible areas independently like APIs, Blogs, docs etc. Maybe if possible we can see those contexts listed by Jordan to be segregated into more generalized context as guidance. I am sure it is not easy. 

On Bob's thread; I agree there shouldn't be automatic enforcement. And I also agree the context is very important. One cannot change the statement just because it has some words (that are offensive in a complete diff context.). 

Also not to mention, we must not change/propose the words that are not even offensive. (Funny when I write this, my employer's name struck my mind. It's BlackRock, and no not intend to propose a change for 😉 ). 

The list I have created is just a starting point and as I referred once we get a consensus on "how and what and why", we can host this like the Inclusive Guidelines from MSFT. This is inlined with what Bob mentioned.

I also think, if we decide on the non-inclusive words then we can discuss the alternatives. For this to be productive, we need to have the answers for "what needs to replaced", "where to refer".

--

You received this message because you are subscribed to the Google Groups "Kubernetes WG Naming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-na...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-naming/98a2e86d-2c27-47c0-beb1-39f113d41013o%40googlegroups.com.

[Jordan Liggitt]

On Sat, Aug 29, 2020 at 3:50 AM Karthikeyan Govindaraj <github.g...@gmail.com> wrote:

Apologies for the delayed response, was caught-up a little with chores at work.

On Jordan's thread: 100% on the side with Jordan, that the  WG Naming should have a framework. But when you mean framework, are you meaning to have this programmatically taken care or something like the Inclusive Language Guidelines from MS as Bob suggested?

More like the guide Bob suggested.

 

Like the points put forth for barriers for participation, but on the other hand who are all allowed to propose alternatives and raise issues on offensive/non-inclusive languages? 

imho, anyone in the community should be able to raise an issue and also the (may be) a PR to some repo for alternatives suggestion.

That could be good. The clearer that process is, the easier it should be to participate. Overall guidance can save time as well. For example, if guidance is to avoid English-centric idioms, then we don't need to enumerate every English idiom that exists. If there are particular idioms we see used in the contexts this WG makes recommendations for, listing those and thinking through alternatives seems helpful.

 

I understood the skeleton list that I put up is mixed with clear and unclear phrases/idioms. This is also not including all the contexts as Jordan suggested. But I was unsure how to  include all the possible areas independently like APIs, Blogs, docs etc. Maybe if possible we can see those contexts listed by Jordan to be segregated into more generalized context as guidance. I am sure it is not easy. 

Definitely, that seems like general guidance that should be defined, so that the process for thinking through a particular term doesn't have to redo that work and can focus on meaning/clarity/etc.

[Celeste Horgan]

> More like the guide Bob suggested.

This works for me, but I'll bring up this from the MSFT guide:

The guide still provides specific recommendations on racially charged language, but does not provide guidance on how to evaluate language. So we're back where we began with this discussion.

How would everyone feel about spending discussion time in our next meeting (Monday, Sept. 14th) to start hashing out guidelines? I'll do a little research to see what other frameworks or resources for evaluating language biases exist and we can see what we think?

Cheers,

Celeste

--

You received this message because you are subscribed to the Google Groups "Kubernetes WG Naming" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-wg-na...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-naming/CAMBP-p%2B16DFL30WSd_iCF-s%3D%3D_UZic6K1vvPyvL6CX0Yg9UzaQ%40mail.gmail.com.

[Bailey Hayes]

Another excellent resource: https://apastyle.apa.org/style-grammar-guidelines/bias-free-language/

Specifically: https://apastyle.apa.org/style-grammar-guidelines/bias-free-language/general-principles

Building on the suggestion above for adding a category... The APA style provides categories for the types of bias. These can be used when evaluating language.

word: master/slave
speaker: must not
coder: must not

bias:

- historical context

- racial and ethnic identity

[Karthikeyan Govindaraj]

@Celeste Horgan Should I create an individual thread for all the terms or should I create an issue in the k/community ? Please advise.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-wg-naming/31950cab-8645-4b70-8624-c7f3b52f67f0n%40googlegroups.com.

[Celeste Horgan]

Hi Karthik,

Maybe space them out 1-2 per week, so that people have time to absorb and discuss them. Thank you!

Celeste