Ensure inclusive language is used in SS

[n8-dev]

I would be great to ensure we're using the best language we can.

i.e Making changes like this

old	new
master	main
master	dispatcher
slave	responder
blacklist	blocklist
whitelist	allowlist
blacklist	denylist
whitelist	acceptlist

Obviously these changes can be wide reaching, (effecting private, property names and more) so it makes the most sense to incorporate this into the major release of CMS 5/6 etc.

Thankfully it doesn't seem to be a lot present in here.

Searching the above on 5 branch only turned up 72 hits for whitelist mostly in comments.

Shouldn't be too hard to fix.

Companion Issue for silverstripe-cms https://github.com/silverstripe/silverstripe-cms/issues/2848

[GuySartorelli]

I'm going to close https://github.com/silverstripe/silverstripe-cms/issues/2848 for now as a duplicate to focus discussion to a single issue - we can reopen it based on the outcome of the discussion.

I suspect (without having checked myself) that a lot of the usage of this language is in the names of methods, configuration properties, classes, or method parameters. For those scenarios, we can't make changes without introducing breaking changes (with exception to any non-configuration scoped private) - and the window for new breaking changes in CMS 5 has passed.

Any comments which refer to the above we also can't change, because then the comment will use different wording than the API which could lead to confusion.

It might be best to leave this for a time when we can introduce breaking changes again, which is whenever we start work on CMS 6. That said - are there a lot of instances of non-inclusive language which, if changed, would not introduce breaking changes or confusion?

[maxime-rainville]

Honestly, I have always been a bit sceptical of the value of "inclusive language". My impression is that this is more performative inclusivity and that the vast majority of the population doesn't attach any special connotation to words like "blacklist" or "master".

Can someone point to any actual research that this kind of changes measurably impact the motivation of potential contributors?

[andrewandante]

Some decent reading and so on here: https://inclusivenaming.org/faqs/

I think it's pretty hard to measure things that aren't happening, if you know what I mean. I can't see how this is anything but a positive change - granted it's likely a breaking one unless you convert a whole pile of methods in to "proxy" methods with deprecation warnings i.e.

public function getWhiteList()
{
  Deprecation::warning('Will be gone in CMS6'); // or whatever the syntax is
  return $this->getAllowList();
}

but to that end, if people are asking for it I think it's worth pursuing.

[lianna-blanca]

Very late to the party, but I definitely support these naming changes. Even if I (white CIS woman) am not in a group that feels the echoes of those words as strongly - and I do feel deeply uncomfortable with "slave", and to a lesser degree "master", "black/whitelist", etc - even if the majority of people who see these terms aren't, it's still a good thing to do to avoid quietly hurting people, in so much as is practical without turning the codebase into knots.

[mooror]

Very much in agreement with Maxime on this one. There is industry jargon that is very well established and well understood by the programming community and has been for a long time. If people want to get up and arms about what connotations they might read into those terms that is on them.

[GuySartorelli]

Lets not turn this into a discussion about who is responsible for the meaning or interpretation of various words or phrases, please. This is a discussion about the feasibility and value of making the proposed change.

I will speak to your point which was on topic though:

There is industry jargon that is very well established and well understood by the programming community and has been for a long time

Terms like "allowlist" and "denylist" are just as easy to understand as (if not more so than) "whitelist" and "blacklist". Regardless of connotations, I'd support changing these terms because "allow" and "deny" are immediately better at conveying their purpose without requiring a previous understanding of industry jargon.

A lot of the terminology in our industry is used because it has been used, and doesn't get examined to check whether it's understandable to someone coming in from the outside. We should seek for the terminology we use to be easily understood by anyone who might have cause to understand it. This is a good opportunity to do that.