Skip to content
This repository has been archived by the owner on Jan 24, 2024. It is now read-only.

SEP 28: proposal to add inclusive-language #37

Closed
Closed
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
56 changes: 56 additions & 0 deletions inclusive-language.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,56 @@
- Feature Name: Inclusive Language
- Start Date: 2020-10-05
- SEP Status: Draft
- SEP PR: (leave this empty)
- Salt Issue: (leave this empty)

# Summary
[summary]: #summary

Following examples set by others in the tech industry and even the Linux kernel itself, Salt should adopt inclusive language to replace racially-charged jargon.

# Motivation
[motivation]: #motivation

**Why are we doing this?** If Salt is to continue to grow and gain wider adoption, it needs to drop references to terms that do not have a place in this world.

**What use cases does it support?** This will affect all current and future users of Saltstack.

**What is the expected outcome?** Salt will join a growing number of companies and projects that are making changes to use inclusive language.

**If this SEP is not accepted?** I don't believe there is an alternative way around this.

# Design
[design]: #detailed-design

**Proposed Updated Terminology**
Salt does use non-inclusive language for a key component. While I will submit what is becoming commonly accepted alternatives, I think the Salt Master/Minon terms will require some larger considerations. I understand that it's not just updating a configuration term, but falls into the larger product branding. I understand this will likely touch a lot of files, but should not require any significant refactoring of code. Mostly just agreeing upon new terms and making sure they mach up as they are updated.

| Avoid non-inclusive language | Prefer inclusive versions |
| ---------------------------- | ------------------------- |
| Whitelist | Allowlist |
| Blacklist | Blocklist |
| Master/slave | Leader/follower, primary/replica, primary/standby |

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Salt does not use the word "slave". None of the preferred terms accurately describe the role of the master.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to include a list of terms that have been provided by other companies as general alternatives. I understand that in this context, the alternative names do not provide an accurate label. While "slave" is not included in any of Salt's language, the term "master" ,on its own, is enough. Having to have a conversation about why a word isn't racist, right or wrong in the given context, highlights the need to change it. A possible alternative name might be "commander". This could be tied into the branding as well, "Salt Commander, helping lead the good fight in SecOps".

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right or wrong in the given context

So we should just accept the wrong thing as being true? Or pander to minority groups by making mindless, meaningless changes?

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

right or wrong in the given context

So we should just accept the wrong thing as being true? Or pander to minority groups by making mindless, meaningless changes?

"mindless, meaningless changes" feels like a strong statement with many other software companies seeing value in removing these terms. Even Github themselves now prefer main vs master https://github.com/github/renaming/

VMware seems to have an opinion, which will hopefully impact Salt https://www.vmware.com/company/news/updates/replacing-problematic-terminology.html

Copy link

@OrangeDog OrangeDog Oct 6, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

VMware seems to have an opinion

Hopefully that means we don't have to argue about it. There's no need for an SEP if they just make the decision.

many other software companies

Doing it because everyone else has is a pretty good definition of "mindless". Github especially have been widely criticised for it, as the word "master" in that context doesn't even anything to do with being in charge.

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While I agree with the sentiment around master in the context of Salt doesn't evoke comparisons to a very controversial past, there's no doubt a not-insignificant number of people do (regardless of context). Might I suggest the most appropriate alternative be "director?"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To continue the bikeshedding a bit, and maybe explore some history, I'll throw in my $0.02USD.

Salt has never used "master/slave" terminology, AFAIK, but has been "master/minion". The origins of minion seem to come from the French "mignon" -- which meant "a king's favorite". Eventually it came to just mean a hanger-on, a follower.

Master, in the Salt master/minion relationship definitely applies to the 14c use of "one who has the power to control, use, or dispose at will". Obviously the word also has strong ties to slavery, especially American slavery. As @ggiesen rightly states, for many people the word "master" evokes those ties -- so it is worth avoiding.

If the term master is off the table then, what's the most accurate term we can use to replace it? Well, the Moby thesaurus has a multitude of options, but I'll just provide a handful:

  • boss
  • captain
  • chief
  • commander
  • controller
  • director (suggested by @ggiesen)
  • executive
  • instructor
  • maven
  • owner
  • proprietor
  • wizard

The fantasy fan in me wouldn't mind a wizard casting spells, but a change like that definitely requires an alternate reality :trollface: Out of the rest of these, controller seems most accurate to me. Director is a good choice, but at least in my experience a director's instructions can be flexible or ambiguous. In Salt, that's not the case. Instructions sent to the minions must be followed precisely and accurately. The computers must be controlled. Which sounds a bit like the beginning of a dystopian sci-fi movie, TBH 😂

Anyway - those are my thoughts on the color of this bikeshed 🙃

Copy link

@ITJamie ITJamie Dec 9, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Internally we called our setup salt-director. moving away from salt-master needs to happen IMHO

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah I thought "director" might be a good term because of synergies with other VMware products (vCloud Director). Of course, the opposite might be true and there could be concern about confusion

Copy link

@ScriptAutomate ScriptAutomate Dec 10, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I really like salt-hero as a potential, too.

Working with heroes makes it sound like we all have superpowers when using salt.

We could also make use of salt-sidekick in relation to other things, maybe kinds of minions or minions in general, depending on how complex the renaming initiative may end up developing into.

| Grandfathered | Legacy |
| Gendered pronouns (e.g. guys) | Folks, people, you all, y'all |
| Gendered pronouns (e.g. he/him/his) | They, them, their |
| Man hours | Person hours, engineer hours |
| Sanity check | Quick check, confidence check, coherence check |
| Dummy value | Placeholder value, sample value |

## Alternatives
[alternatives]: #alternatives

**What is the impact of not doing this?** I don't believe it is possible to have an alternative to this. You are either making a change or not. Not making the change just leaves the old terminology intact.

## Unresolved questions
[unresolved]: #unresolved-questions

Specific terminology to use should be discussed, agreed upon and then formalized. This should prevent competing terms from making their way into the code.

# Drawbacks
[drawbacks]: #drawbacks

Why should we *not* do this? Please consider:

Without digging into the code, I do not have a full picture of what the impact will be. This will consume time. This will likley cause backwards compatibility issues a likely break communications between different verisons of releases. Documentation and formal terminology will need to be updated. Since a `salt-master` is a significant part of Salt's branding, there is likely to be marketing costs for making this change. Regarding alternatives, I cannot imagine an alternative way around solving this problem.