-
Notifications
You must be signed in to change notification settings - Fork 68
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
Remove "blacklist" and "whitelist" in favor of neutral terms #302
Conversation
Sorry, I'm not a native English speaker, and I don't know what's the point here. Is it ok to support both of those options? so we don't need to update those scripts in the downstream packages. |
I'm against this not because it's not "right", I'm against this because I don't think it worths the effort; people here are already busy enough to deal with multiple packages. If it's dealing with new code, 100% great. If it's renaming the old codes in a breaking way, that's not a good option. If we want to recommend these new terminologies, I think what's needed to be done first is to update the community standards first. |
@Gnimuc the point is to move away from terms intertwined with race and racism (I.e. whiteness being "good" thus is allowed and blackness being "bad") happy to PR the CoC as well. |
What do white and black have to do with race? This is pretty much a purely American thing in that you guys have separated up your population into these two distinct "classes" and use these terms to define them. If anything the problematic part. Not that the word "black" is used for the absence of something where the obvious origin, that black/dark things are due to a lack of light, or inability to reflect light, is used all over the place (black hole, dark matter, blackout, etc etc). |
Not sure this PR is the right place for a discussion like this @KristofferC happy to chat elsewhere |
Sure, it is kinda problematic to open PRs where the content of them cannot be discussed therein though. Doesn't feel very open-source style. |
For some additional context: https://www.zdnet.com/article/uk-ncsc-to-stop-using-whitelist-and-blacklist-due-to-racial-stereotyping/, https://9to5google.com/2020/06/12/google-android-chrome-blacklist-blocklist-more-inclusive/, https://thenextweb.com/news/github-plans-to-replace-racially-insensitive-terms-like-master-and-whitelist, etc. Not sure it's fair to say that the terms white or black are a US thing, it seems pretty generally accepted from leaders in the tech space that when at all possible, we should move away from terms like this. I have no appetite to argue about this though. |
When renaming to avoid these terms it is also worth aiming to end up with something more clear. To make this nonbreaking, one should introduce a way of using the removed keys still. function get_with_deprecation(collection, new_name, old_name, default; combine=append!)
haskey(collection, old_name) && Base.depwarn("the key $old_name has been deprecated in favour of $new_name", :general_ops)
return combine(get(collection, new_name, default), get(collection, old_name, default))
end |
Forgive me for I'm from outside the julia community, but I wanted to give my perspective. I work in security and the we make heavy use of allow and deny lists. So I've seen the switch happen elsewhere. Basically, @oxinabox brings up a very good point, and I think that approach has lead to better code than reusing using the same overloaded terms everywhere. When done well it'll work like curb cuts, meant to help some people but end up helping everyone. |
@KristofferC I'd like to point out that along with everything @logankilpatrick has said, the term 'blacklist' originated in colonial times to deny certain people (mostly the colonized, who were people of colour), access to various things. It's definitely not reducible to just being an 'American thing'. It's 2021 now, and we can all agree that we want to live in a world where those folks whose ancestors might have been through so much, also feel just as included in the community as those to whom this issue doesn't matter as much. A lot of other languages and platforms have made the switch, and it would be great for the Julia ecosystem to become more supportive of the nomenclature in general. Granted, it causes breaking changes for a lot of downstream packages and is a LOT of work for maintainers, but that's a totally separate issue from the one where we fail to recognize that we can all do better. |
It's very clear to me that blacklist/whitelist belongs to the "older term" category and it's somehow breaking to update it to the new terminology. And it's very clear to me that none of us intends to associate it with race. Even if we want to use the new terms in Clang.jl, we should introduce a phase that both sets of terminology work; we can't just hard switch to the new one. |
@johnnychen94 Good that you raised the issue of cost and value - no one would argue that a change like this has no cost, the question is really "is the cost worth it?" And part of that calculation is what is the cost of keeping things the same. I gather @KristofferC thinks that cost is minimal, for example, so it makes sense that he wouldn't thing the change is worth it. It won't be me paying the maintenance cost, and I'm not someone that's adversely affected by the old language, so I don't have much of a vote here, but it seems to me that, regardless of the origins of the words, and regardless of anyone's current intent when using them, if a bunch of communities and companies are paying those maintenance costs for the sake of being more welcoming, and others aren't because they don't think it's worth the effort, some future black developer might draw a reasonable inference that the latter groups aren't as interested in their contributions. |
|
I also have a PR open here: JuliaSparse/SuiteSparse.jl#36