Skip to content
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

Merged
merged 1 commit into from
Oct 13, 2021

Conversation

logankilpatrick
Copy link
Contributor

I also have a PR open here: JuliaSparse/SuiteSparse.jl#36

@Gnimuc
Copy link
Member

Gnimuc commented Jun 22, 2021

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.

@johnnychen94
Copy link

johnnychen94 commented Jun 22, 2021

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.

@logankilpatrick
Copy link
Contributor Author

@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.

@KristofferC
Copy link
Contributor

KristofferC commented Jul 2, 2021

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).

@logankilpatrick
Copy link
Contributor Author

Not sure this PR is the right place for a discussion like this @KristofferC happy to chat elsewhere

@KristofferC
Copy link
Contributor

KristofferC commented Jul 2, 2021

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.

@logankilpatrick
Copy link
Contributor Author

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.

@oxinabox
Copy link

oxinabox commented Jul 2, 2021

When renaming to avoid these terms it is also worth aiming to end up with something more clear.
As such this change is best done by someone experienced with the code-base (not me).
It seems like many of the places that say blacklist would be clearer being called
files_to_skip, always_treat_as_mutable, never_treat_as_mutable, treat_as_function,
forbidden_idks.

To make this nonbreaking, one should introduce a way of using the removed keys still.
Something like the following works, though alternatives exist.

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

@comath
Copy link

comath commented Jul 2, 2021

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.

@prrao87
Copy link

prrao87 commented Jul 3, 2021

@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.

@johnnychen94
Copy link

johnnychen94 commented Jul 3, 2021

https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms-like-blacklist-and-slave/

The Linux team did not recommend any specific terms but asked developers to choose as appropriate.

The new terms are to be used for new source code written for the Linux kernel and its associated documentation.

The older terms, considered inadequate now, will only be allowed for maintaining older code and documentation, or "when updating code for an existing (as of 2020) hardware or protocol specification that mandates those terms."

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.

@kescobo
Copy link

kescobo commented Jul 3, 2021

because I don't think it worths the effort; people here are already busy enough to deal with multiple packages.

@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.

src/generator/passes.jl Outdated Show resolved Hide resolved
@Gnimuc Gnimuc merged commit bacacb4 into JuliaInterop:master Oct 13, 2021
@KristofferC
Copy link
Contributor

denylist makes absolutely no sense here. Nothing is being denied. exlusion_list perhaps.

KristofferC added a commit to KristofferC/Clang.jl that referenced this pull request Oct 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants