chore: make inclusive language truly inclusive

[Nytelife26]

While "blocklist" / "denylist" and "allowlist" / "grantlist" or other alternatives are quite commonly proposed, they are neglecting something - English is not the only language spoken on our Earth. In many languages, these fabricated alternatives have no direct translations.

For instance, Spanish. None of those alternatives have translations that make sense. Not to mention that "whitelist" and "blacklist" are already inaccessible in those languages due to their rarity. The most commonly used phrasing is, for instance, "list of blocked users" or "blocked user list".

We need to be mindful of this when creating guidelines for inclusivity. We need to be TRULY inclusive, and considerate of those that come from foreign backgrounds, otherwise, you are actively making the terminology less accessible to more people than you are helping.

This is not to create a flame or attack anyone on the V8 development team. I just truly believe that this hasn't been considered enough, and I do not wish to see the second wave of realization when people wake up to the fact that many people from other linguistic backgrounds will struggle to understand these alternatives. Software engineering should be accessible to all, no matter the abstract features of their background.

[google-cla]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[googlebot]

Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed (or fixed any issues), please reply here with @googlebot I signed it! and we'll verify it.

---

What to do if you already signed the CLA

Individual signers

• It's possible we don't have your GitHub username or you're using a different email address on your commit. Check your existing CLA data and verify that your email is set on your git commits.

Corporate signers

• Your company has a Point of Contact who decides which employees are authorized to participate. Ask your POC to be added to the group of authorized contributors. If you don't know who your Point of Contact is, direct the Google project maintainer to go/cla#troubleshoot (Public version).
• The email used to register you as an authorized contributor must be the email used for the Git commit. Check your existing CLA data and verify that your email is set on your git commits.
• The email used to register you as an authorized contributor must also be attached to your GitHub account.

ℹ️ Googlers: Go here for more info.

[Nytelife26]

@googlebot I signed it!

[googlebot]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[google-cla]

CLAs look good, thanks!

ℹ️ Googlers: Go here for more info.

[Nytelife26]

cc: @mathiasbynens (not sure who the relevant people would be but you seem to be an active maintainer so apologies)

[mathiasbynens]

cc: @mathiasbynens (not sure who the relevant people would be but you seem to be an active maintainer so apologies)

@RReverser and @surma are maintaining v8.dev. Could you PTAL?

[surma]

I like your additions, @Nytelife26. I would ask that you not remove “allowlist” et al from the list, tho. For English resources, they are completely valid and have somewhat become an industry-standard as replacements for whitelist/blacklist. Happy to merge afterwards :)

[Nytelife26]

I would ask that you not remove “allowlist” et al from the list, tho. For English resources, they are completely valid and have somewhat become an industry-standard as replacements for whitelist/blacklist

For English resources for native speakers that understand the language fluently, yes. The entire point here is accessibility. They should not become the industry standard because they are unsuitable replacements.

See a statement I authored for more information on that, and come back with your verdict. Do not let popularity be a reason, though - the amount of people doing something does not change its value.

[surma]

The industry is increasingly adopting “allowlist” and “blocklist”, despite the shortcomings you correctly point out. I worry that if we remove any appearance from “allowlist” and “blocklist” from the table, that people who are used to these terms are now confused because they don’t appear at all. How do you envision that being handled? To that extent, we need to at least consider the relative popularity of these terms.

I see your point and I like your suggestions, but I don’t decide what is and is not popular/commonly used in the industry, which is why I am trying to get your point reflected without increasing confusion.

[Nytelife26]

which is why I am trying to get your point reflected without increasing confusion.

It may be wise to link to an external resource on why we have not included them on viable suggestions, perhaps such as the links I have provided before and maybe a brief explanation then.

If you want me to implement that into this pull request, I can - just make sure you inform me to what extent, because I don't want to go overboard by accident.

[Nytelife26]

Following discussion with others from the inclusive naming initiative, it seems that exclusion list and inclusion list are likely the best solutions.

It:

1. Makes actual linguistic sense in English
2. Does not rely on native-speaker inference and can be translated properly
3. Lines up with software use cases nicely

On point 3:

include: [a, b, c]
exclude: [a, b, c]

That's quite a common configuration pattern, and it lines up nicely with inclusion / exclusion list.

Thoughts on this, anyone?

[RReverser]

I don't really see the value in excluding something from the list of suggested alternatives, especially if such alternatives are indeed already used in the wild. If any of the proposed alternatives don't work for a particular project, they can always choose another one.

[Nytelife26]

I don't really see the value in excluding something from the list of suggested alternatives, especially if such alternatives are indeed already used in the wild. If any of the proposed alternatives don't work for a particular project, they can always choose another one.

Because we shouldn't be suggesting those "alternatives", if they can even be called that since they are not viable. They are more harmful than beneficial, as we have stated, for many reasons - and as such, there is no reason to use them, especially when there are better alternatives.

[RReverser]

for many reasons

As far as I understand, the main reason is usage in other languages. As non-native English speaker, I appreciate that concern but terminology (or words in general) by design don't map 1:1 between different languages, and I assume that other languages would have their own tables.

This table is in English and is describing alternatives used in English language, and since those words are already used in the wild, removing them is worse and would cause more confusion than keeping.

[Nytelife26]

As far as I understand, the main reason is usage in other languages. As non-native English speaker, I appreciate that concern but terminology (or words in general) by design don't map 1:1 between different languages, and I assume that other languages would have their own tables.

Terminology doesn't map 1:1, sure. But there are no translations for such words. Not to mention they don't even make sense in their language of origin - blocklist, denylist, et cetera, are not valid in English.

They are less clear, they are invalid, they do not translate well, and others. I would implore you to read the statement I linked to in this pull request if you need any further reasoning.

This table is in English and is describing alternatives used in English language, and since those words are already used in the wild, removing them is worse and would cause more confusion than keeping.

That's why I proposed adding a note below the table as to why certain examples were omitted, so we can explain the decision or link to other resources. Objectively, the present alternatives are not sufficient, and if we have the opportunity to use better, as engineers, we should steer for the better choice.

[surma]

I understand your point and I want to add your additions. However, we can’t just remove terms, as we are also trying to align with the Inclusive Chromium Code guidelines, for example.

Please add the removed terms back to the table so we can merge this.

[Nytelife26]

That defeats the entire purpose of the pull request. The point is these terms do more harm than good. If I must make a pull request there too prior to this so things are consistent, I will, but I'm not doing half a job here and leaving this to continue happening.

If I have to explain why these terms are not present in the document, that's fine - but I will continue to drive this point until I am either proven wrong or people begin to realize the situation.

Thank you for understanding, and I appreciate that you want to work with me here rather than against me, but I simply cannot drop the movement behind this just because "standards". I have discussed with members of other projects, including employees of IBM, and further discussion is in progress. If you wish to participate, you may do so here. If not, I'll keep going until this is all resolved :)

Once again, thank you. I appreciate your time and consideration.

Edit:
I cannot propose changes to the documents as they are based on internal documents accessible exclusively to Google employees. If someone here can help me reach the relevant people and get this discussion to a point where it has been considered by the necessary employees, that would be fantastic.

[Nytelife26]

Status, anyone?

[surma]

I can not really change anything from my last statement. I don’t control the Chromium Code guidelines and don’t know who has the power to change them. I am assuming there is a whole lot of process involved.

I respect your willingness to metaphorically die on this hill, but I won’t be able to merge this unless the previous terms get added back in.

[Nytelife26]

I can not really change anything from my last statement. I don’t control the Chromium Code guidelines and don’t know who has the power to change them. I am assuming there is a whole lot of process involved.

There most likely is. And that's what I'll do. It seems to me that they don't accept pull requests from GitHub, much like v8 itself, so I'll have to do some more investigation on their Google-hosted source and make the relevant communications in any mailing lists.

[Nytelife26]

Found it. I am unable to post on the issues tracker for the Chromium project, including for the respective issues, so if someone could forward the following message via issue or contact on my behalf (the file is located at HEAD/styleguide/inclusive_code.md on the googlesource page so associated committers will be useful mentions).

I am submitting this as I cannot comment on the current issue, #842296. As
a result of a discussion in v8 (https://github.com/v8/v8.dev/pull/537) and
the Inclusive Naming Initiative with employees of Google and IBM
respectively (https://github.com/inclusivenaming/website/pull/45), which
can be seen for context, "blocklist" and "allowlist" are not suitable
replacements in any circumstances and should be removed from the inclusive
code guidelines (I am raising this issue here to bring broader attention
to it and to enable this change to take place elswhere within Chromium's
organizational structure, v8 included). Instead, things like "inclusion
list" or "exclusion list" (just examples) would be better. The primary
issue with current proposed alternatives is translatability and the fact
that they do not work within the English language and so have no direct
translations and are very difficult to pick up from a perspective with
lack of knowledge of English given that they can only be derived and
interpreted correctly with nuance, and also fail when ran through
translators, including Google Translate.

Thank you for your time and attention. This is not an attack on th epeople
who proposed those originally, but there are better ways to go about this,
given that those alternatives pose more harm than good overall. As
engineers, we should strive to do our best, and I do not wish to witness
a second wave of realization when we have to correct all of our
corrections if they are to go further.

For more information, see the linked PRs GitHub-side.

Thank you in advance.

[surma]

I’d recommend opening a new issue instead and reference that one

[Nytelife26]

I’d recommend opening a new issue instead and reference that one

I tried, wouldn't let me as aforementioned unfortunately, which is why I'm asking if a Googler can assist me with making this happen :)

[surma]

The issue tracker is open to the public. You can create a new issue via crbug.com/new.

[Nytelife26]

Turns out it allowed me to today. If anyone wants to participate or follow the discussion, here

[Nytelife26]

The lack of engagement with the Chromium issue is, to say the least, disappointing. I'd like to hope that an organization like Google wouldn't just sed -i with linguistics to avoid accusations of racism without caring about any of the actual implications, but it's starting to seem that way.

It has become evident that these changes were made for virtue signalling and nothing more. I'll be working closely with the INI, now, until this gains some actual internal attention from a Chromium team member - because plenty of them are interested in avoiding exclusion, but none of them are interested in engineering a real solution.