Remove non-inclusive language

[dwelsch-esi]

Remove non-inclusive language throughout the documentation as recommended by the Inclusive Naming Initiative.

Use-Case

CNCF is among the organizations spearheading the adoption of more inclusive language in code and documentation.

Specification

The KEDA documentation is relatively free of non-inclusive language, but there are places that could be improved. Examples in KEDA:

• In concepts/scaling-deployments.md: "This value can be used to easily distinguish this specific trigger and its metrics ..."
• The use of "master" (as in "sentinelMaster") in scalers/redis-sentinel-lists.md. This might be impossible to change without changing the Redis scaler as well.)
• In deploy.md: "Deploying KEDA with Helm is very simple".

[tomkerkhove]

Thanks! Is this something you can contribute?

In terms of master I am afraid we can only change it once Redis has changed to to not confuse end-users more.

[zroubalik]

Hi, thanks for raising this issue. Unfortunately the Redis case is not something we can fix, as it depends on Redis itself.

I personally don't think the other cases are non-inclusive, there's nothing harmful or offensive in them. If so, we would need to change half of the website:

[dwelsch-esi]

@tomkerkhove @zroubalik I understand the need to mirror the parameter names used by Redis. In the text, you can reject the term "master" without losing clarity by using, for example, a parenthetical explanation. For example, you could rewrite this:

"- sentinelMaster - The name of the master in Sentinel to get the Redis server address for."

To this:

"- sentinelMaster - The name of the primary (still referred to as the 'master' in Sentinel) to get the Redis server address for."

In place of "master", you can use "primary", "main", "original", "source", "controller" or any other term that most accurately conveys the function of the referent.

I didn't do an exhaustive search for non-inclusive terms, but I didn't find any tier 1 terms outside the Redis scaler doc. Re terms like "easy" and "simple", these terms aren't in the inclusive naming lists, but they are mentioned in the CNCF assessment criteria. As I understand it, the goal is to avoid ableist language, especially if it sounds dismissive or patronizing, like "Adjusting the threshold is a no-brainer; just change the scaleThresh value in the config file."

While I can't categorically agree with you that this particular ableist language is inoffensive, its usage here doesn't seem egregious. I respectfully take issue with "... we would need to change half of the website" as an argument to leave it as-is. There are cost/benefit tradeoffs to any change; this argument is another way of saying that inclusiveness should remain a low priority. Again, CNCF wants to be a leader in adopting more inclusive language in code and documentation.

[nate-double-u]

To that point, the CNCF isn't mandating any of these changes—projects are always free to pick and choose which of the TechDocs analysis' recommendations to implement—but we do include a review of inclusive language as part of the process to help raise awareness.

[tomkerkhove]

I don't have concerns if you open a PR with those recommendations. @zroubalik?

[tomkerkhove]

Closed in #1389