-
Notifications
You must be signed in to change notification settings - Fork 1.9k
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
Change the "Blacklist / Whitelist" nomenclature #1483
Comments
Hey - just noticed that this was on the roadmap for 1.3 yet it's marked "breaking." The body of this issue does describe what's happening but if you just look at the roadmap it's alarming to see "breaking" on a minor release. Can we remove that tag? |
@stockholmux I think we want the non-breaking changes in 1.3, so for now I removed breaking instead. |
Waiting for official english dictionary to remove "black" and "white" colors from it due to "excluding people on the basis of gender, sexual preference, age, race, ability"… How the hell "whitelist" and "blacklist" can even be excluding to anyone?! Don't you know the physics thing called "shadows"? It makes things invisible… dark… (shouldn't even mentiond "black" because someone will kill me in a second because of that!). I just really want to understand the reasoning for this. And reasoning should be reasonable! Not some imaginary problem (you obviously have here). |
|
@dblock "may be offensive to some people" is not explanation. You can cover anything behind this sentence just for sake of not answering this question. I'm asking about real explanation, who and how is offended by this? |
I have offended Engineers on my teams over the years by using non-inclusive language in technical conversations. I've referenced race, gender and sexual orientation, physical and mental ability. I am not going to ask these individuals to explain here how they were offended, or make a list of who they are. But I've been asked directly, 1:1, to change the words I use, therefore I support this change. Other people's experiences matter to me. |
This seems kinda weird for software engineer… every change I do in my software or infrastructure is made because of some reason which I have to understand why something happens and make clear decision based on circumstances. Based on what you said… you don't even know why you want to make this change.
Well, that's your problem that you were a bad person to others, not mine and not other people in community. I don't see why your personal problems should reflect to software. Not to mention that "blacklist" and "whitelist" don't refer to "race, gender and sexual orientation, physical and mental ability" at all. |
Hi @morsik, thanks for expressing your concern here. We definitely don't make breaking changes lightly, and I hear your feedback that every change has a cost. We're committed to avoiding noninclusive language throughout the project. I recognize some members of the community may be encountering this perspective on "blacklist" and "whitelist" for the first time. Sometimes the realization that a familiar term is actually not the best can be surprising, and curiosity or skepticism about that is totally rational. "Blacklist" and "whitelist" are recognized as noninclusive terms pretty broadly: this isn't a concept that originated from this project, and our intention is to recognize and respect this rather than to re-debate it. In this case, I think this change has the benefit of making this terminology more accurate and understandable: as the lists are of things that are allowed and denied, not lists of things that are colors. |
This issue came up in the community meeting yesterday. It sounds like the plan is to remove the terms "blacklist" and "whitelist" in 2.0. The It's good that the new fields will come soon in 1.3 so that developers can start making changes soon. But, removing the field from APIs in 2.0 will make migration harder. |
Let's start by implementing a backwards-compatible change and we can decide the deprecation -> removal separately. |
@dblock Regarding these changes for the plugins, do we have an ETA on when OpenSearch and OpenSearch-Dashboards will rename their references? Alerting, for example, is referencing Painless and NodeListeners which have things like |
@tlfeng ^ |
Hi @qreshi 😄 Such class/method names that in OpenSearch Java libraries will be renamed in a future major version. At least in version 3.0, but depends on the public acceptance. It is tracked in issue #1683. I will keep updated. |
@tlfeng Got it, so it's safe to say that these issues being tracked for the plugins don't need to be closed out by 2.0 preview or GA? Since this issue is currently tagged as |
@qreshi That's a reasonable suggestion! I will add more detail to disambiguate the current process. Thank you! 😁 |
This issues spans several changes, some of which are not in scope for |
Our society has a serious problem with intellectual honesty: biased by ultra-minority political opinions from people who just yell loudly. It's even worse here: OpenSearch engineers, only witnessing their close surrounding is bothered by this "black/white terminology", are totally disrupting the roadmap with a change that will take them months to make. Have you conducted an scientific survey on this alleged problem ? |
With 2.4 release, we have deprecated all non-inclusive usages (i.e. master, blacklist and whitelist) and we are planning to remove those deprecated usages on 3.0 release. |
Closing the issue |
Goal of the enhancement
Coming from #2589
Replace non-inclusive terminologies "blacklist" and "whitelist" throughout this repository with inclusive ones.
Context
What is “inclusive language”?
Inclusive language is designed to avoid excluding people on the basis of gender, sexual preference, age, race, ability, etc. By using language that avoids expressions which imply or express ideas that have prejudice to any particular group of people, we aim to create a more equitable community.
Why using “inclusive language” is important?
Using inclusive language helps build an inclusive environment, which accepts diversity and ensures any individuals and groups feel welcome, respected, and safe. Diversity does contribute to create a fair and strong organization, and also leads to diversity of ideas, which change into creativity and innovation.
How to apply “inclusive language” in a software program?
Replace “objectionable language in code bases and documentation. It involves assessing existing code bases and documentation, identifying potentially problematic language, then replacing terms with more preferable language.
Solution
Overview
To solve the issue, breaking changes will be introduced to OpenSearch, which requires backwards compatibility. The exclusionary terms exist in APIs and configurations, which will impact the compatibility with previous versions of OpenSearch and its third-party clients and tools.
We will support both and new APIs or configurations for a period of time, to let users get used to the breaking changes gradually. Considering OpenSearch follows Semantic Versioning, we are going to include the new API and configuration in current minor versions, while continuing to provide support for the previous APIs and configurations for a period of time, then remove support for the old ones in a next major version.
Substitute for the exclusionary terminology
Our proposed preferable terminologies:
Location for the terminologies:
Versions to introduce the change
Explanation:
Procedure for the replacement
1. Replace the exclusionary words that won’t impact the compatibility.
(source of the idea)
Replace all the exclusionary words in the following location:
2. Deprecate old usages that having exclusionary words and impact the compatibility, then create alternative usages with the inclusive terms.
(source of the idea)
This step includes the following effort:
@Deprecated
annotation), console output and logs.The location that will impact the compatibility when changed:
3. Add tests to check both old and new usages - in Settings.
(source of the idea)
Adding new unit tests to check the both old and new names have got the same functionality.
4. Replace the exclusionary words in log messages and update documentation.
This step includes the following effort:
5. Replace the exclusionary words that will impact software programs depend on OpenSearch Java libraries - in Java APIs.
Replace the exclusionary words in all Java APIs, including field, method, class, and package names.
The "Java APIs" refers to those packaged in Java libraries and are published to Maven (https://search.maven.org/search?q=g:org.opensearch https://mvnrepository.com/artifact/org.opensearch)
Impact of this step:
All plugins, clients and tools that use OpenSearch Java APIs from OpenSearch Java libraries which contain non-inclusive terminologies have to make corresponding changes to call new APIs, if they want to upgrade the dependency to a future major version of OpenSearch.
6. Remove the deprecated settings in a future major version.
Sub-issues
Appendix
Location that contains the exclusionary terms and will impact the compatibility when changed
Settings
1
reindex.remote.whitelist
(static)Code: https://github.com/opensearch-project/OpenSearch/blob/1.0.0/modules/reindex/src/main/java/org/opensearch/index/reindex/TransportReindexAction.java#L60
Location that contains the exclusionary terms and will impact software programs depend on OpenSearch Java libraries
API of Java library
1 Painless SPI - multiple classes with name “Whitelist”
Code: https://github.com/opensearch-project/OpenSearch/tree/1.0.0/modules/lang-painless/spi/src/main/java/org/opensearch/painless/spi
Javadoc: https://opensearch.org/javadocs/1.0.0/OpenSearch/modules/lang-painless/spi/build/docs/javadoc/org/opensearch/painless/spi/package-summary.html
Related issues and PRs
Existing PR before the issue created: #744
Related issue: #472
Issues for other repositories in the organization:
The text was updated successfully, but these errors were encountered: