Remove use of blacklist and whitelist

[serena-ramley]

Summary

Could you update your API terminology for id-whitelist and id-blacklist to be more inclusive? This could be a breaking change or you could immediately accept additional properties alongside the existing ones and phase them out at the next scheduled release.

I'm not sure whether users need to use these terms in order to use your API, but I see them in the changelog and in the code.

Motivation

The Code of Conduct says to use welcome and inclusive language and there's certainly more inclusive language that could be used for this part of the api. In addition, you're in the position of setting an example with the terminology that you choose to use. This post does a good job of detailing why the terms derive from prejudice: https://www.ncsc.gov.uk/blog-post/terminology-its-not-black-and-white

Additional Context

If id-allowlist and id-denylist don't fit exactly, alternative API properties could be excluded-ids, permitted-ids

Please note, this is my first issue request on a public API

Thank you for your understanding of the significance of this issue

Prior conversation on other repositories:

rails/rails#33677
FullHuman/purgecss#428
getsentry/sentry-javascript/issues/2640

[kaicataldo]

Thank you for bringing this to our attention. We should change this terminology where it exists in our project (in a backwards-compatible way so that we don't break existing configs). In doing a search of our codebase, I'm not seeing these terms used anywhere except in the id-blacklist rule.

Thoughts on an alternative name? disallowed-id, maybe?

It would be great if we as a team decided on alternative terms to use going forward. "allow list" and "deny list" (as suggested in the article shared by the issue author) seem like good terms to me.

Edit: I actually think we should rename it to id-denylist. As mentioned above, this would make it clear this is an intentional choice.

[Shinigami92]

I'm making this change in another repo right now
We use blocklist, this has the advantage that only the a has to be exchanged with the o

[kaicataldo]

@serena-ramley Hi! Curious why you closed the issue. I have a PR open and it seems like the team is behind this change.

[kaicataldo]

@blacklistisnotracist You've made your point. Words matter, and I think it's abundantly clear on face value why we, as a community that says we're inclusive, would want to make this change.

[nzakas]

Marking this issue as accepted.

[Alhadis]

Oh. My. God. Did you really just force users to update their ESLint configs because an English compound word happens to include the word "black"…?

Look, your Code of Conduct is your thing and all, but introducing a breaking change because the use of a particular word could potentially offend people who don't understand what the word actually means? That's going too far.

I know this comment will be 👎 'd to hell because this area of cyberspace is dominated by people who're super PC and all, but for the love of God, at least provide links to precedent cases of ostensibly "problematic" language actually causing problems. Please.

[kaicataldo]

There were no breaking changes introduced by this and existing configs will not be broken.

[Alhadis]

Wait, you added an undocumented alias for id-denylist that still accepts the previous name? That's... not really obvious, especially to users reading the change-logs who expect the now "unrecognised" id-blacklist rule to cause a Definition […] not found error.

Under normal circumstances, that's something that should probably be explained in the rule's documentation… which I'm guessing isn't an option here…

[kaicataldo]

@Alhadis You aren't blocked by me or the ESLint organization, so not sure what you're referring to in your PR.