-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace whitelist/blacklist terminology with allowlist/denylist #1116
Replace whitelist/blacklist terminology with allowlist/denylist #1116
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not convinced. These replacements seem a little weird.
I'm also not convinced that there is anything wrong with "blacklist" and "whitelist", just because they contain the words "black" and "white". Those are just colors after all and I don't think they have any racial origin.
Take "whitebox" and "blackbox" for example. One let's light through (white), the other not (black). That's probably a physical origin.
Wikipedia also doesn't mention anything about the term not being inclusive or anything like that. It does however mention "blocklist" as an alternative.
I've had this conversation several times at several different jobs. I've made my peace with it by acknowledging that while I myself may not attribute any unexpected connotations to these words, that speaks to my privilege and that others can and do. It is a simple enough thing for us to substitute alternatives and avoid the issue altogether. |
For what it may be worth, I've filed a similar issue (and PR) against HashiCorp Consul: hashicorp/consul#7901, and they acknowledge that several of their products have intentionally moved away from this exact terminology but Consul has not, yet. (I filed issues against Consul and this repo because we use these two repos as dependencies in our own codebase). |
Fortunately, we don't use the terminology in public APIs. This PR doesn't break backward compatibility and doesn't make inconsistency between code and document. So I'm OK for this change if the document is clean and readable. |
The variables for the launchEditor feature were kept consistent with Create React App so it's probably a good idea for them to change them too: https://github.com/facebook/create-react-app/search?q=WINDOWS_FILE_NAME_WHITELIST Prior discussions on this topic: - hashicorp/consul#7901 - styled-system/styled-system#391 - go-sql-driver/mysql#1116 - lagom/lagom#2532 - grafana/grafana#18841
https://twitter.com/vercel/status/1267650234236252161 The variables for the launchEditor feature were kept consistent with Create React App so it's probably a good idea for them to change them too: https://github.com/facebook/create-react-app/search?q=WINDOWS_FILE_NAME_WHITELIST Prior discussions on this topic: - hashicorp/consul#7901 - styled-system/styled-system#391 - go-sql-driver/mysql#1116 - lagom/lagom#2532 - grafana/grafana#18841
Thanks, all! |
https://twitter.com/vercel/status/1267650234236252161 The variables for the launchEditor feature were kept consistent with Create React App so it's probably a good idea for them to change them too: https://github.com/facebook/create-react-app/search?q=WINDOWS_FILE_NAME_WHITELIST Prior discussions on this topic: - hashicorp/consul#7901 - styled-system/styled-system#391 - go-sql-driver/mysql#1116 - lagom/lagom#2532 - grafana/grafana#18841
…ql-driver#1116) * Replace whitelist/blacklist terminology with allowlist/denylist * Add myself to AUTHORS * PR feedback * Denylist --> denied * Update denied --> rejected
…ql-driver#1116) * Replace whitelist/blacklist terminology with allowlist/denylist * Add myself to AUTHORS * PR feedback * Denylist --> denied * Update denied --> rejected
Description
Promoting inclusive terminology by replacing outdated terms with more sensitive equivalents.
Checklist
Closes #1102