ci: add a workflow to check for exclusive language

[tonyandrewmeyer]

This adds the standard Canonical workflow for detecting non-inclusive language (and suggesting alternatives).

Only one language change is made: tox supports allowlist_externals instead of whitelist_externals (and likely will remove the old option eventually), so switch to that.

There are two terms that occur across the code base that fail the default config: "dummy" and "sanity". I think debating whether we should replace those can be done in a different PR.

For now, this should prevent any non-inclusive language accidentally making it into the code.

[benhoyt]

I would rather not go down this path. Policing our language in this way seems officious and bureaucratic, and give me 1984 vibes. Efforts like this start with good motivations, but end up signalling virtue instead of being actually virtuous. I believe there are much better ways of including potential new Ops users and developers.

We should avoid specific terms like "slave" that are widely agreed to be problematic (though that particular term we don't use at all in this repo). However, I disagree with several specifics in config.yml, and more importantly, I don't think this approach to language is helpful.

I think it's catering to manufactured offense, which is not something we need more of in our world. Was this prompted by a real person being offended at a specific term? Has anyone actually been offended by the use of "dummy charm" or "grandfathered in"? I highly doubt it, and even if so, I think the problem is that they don't understand metaphor, not that those terms are "exclusive". We couldn't watch TV or read a book if we were constantly looking for terms that could be seen as offensive to someone, somewhere. We couldn't even hang out with Australians! ;-)

In addition, context is important. "Ops is your master" is inappropriate, but are we going to ban a "master's degree" or the phrase "jack of all trades, master of none"? As far as I can tell, the woke tool ignores context and would flag all of these.

Even the term woke is rather polarizing and political. Dare I say exclusive? Folks on the left often use it positively; those on the right mostly use it as a term of derision. (Not to mention that the word woke in this context is itself arguably cultural appropriation.)

For what it's worth, I think core Python developer Raymond Hettinger has a good take on all this:

If a particular passage is demonstrably unclear or offensive, it should be changed; otherwise, we shouldn't let vaguely formed notions of political correctness shape other clear uses of plain English.

It would be great if Ops could be more inclusive, that is, include more people in using and developing it. But I'm certain that what's stopping us is not the use of the term "dummy charm" in code comments, rather, it's people not knowing or caring about Juju. Let's aim for more of that!

Happy to discuss further.

[tonyandrewmeyer]

I personally feel that as long as the tool is being used to signal "here's some word choice that should trigger thought or discussion" rather than "this breaks a rule", then value is added. I also feel that younger people and people whose first language isn't English are often unaware when better phrasing could be used (certainly I think I am better at this now than I was 20 years ago, and I think that's more to do with my own experience over that time than because of changes in the world itself). I can see value in that being pointed out by a tool.

Context (and homonyms and common root words) are definitely all important and reasons that I don't believe this can be an automated rule (only a flag to consider something).

However, I am sympathetic to the view that the tool itself can be divisive (and I completely agree that woke is a terrible choice of name) and that used poorly (or, I suppose, co-opted) it can be a net negative.

I also agree that the configuration here is overly broad (I don't know the history there). There are ~6 terms in the config that I feel don't belong there (and I would guess I'm pretty far 'left' as these things go). I would rather have a config that only included words that were very widely accepted as best replaced. However, it seems like if this should be adopted then it would be better using the company list with minimal changes.

I don't disagree with Raymond's take - I saw the contribution of the check being surfacing new text that should be evaluated to see whether it is "demonstrably unclear or offensive" rather than being a way to define what is/is not offensive.

@benhoyt and I had a voice discussion about this as well, and we agreed that we won't merge this. We will rely on code review to identify when better choices can be made (for clarity as well as inclusiveness).