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

Inclusive language on internal terminology #21988

Open
eed3si9n opened this issue Nov 20, 2024 · 4 comments
Open

Inclusive language on internal terminology #21988

eed3si9n opened this issue Nov 20, 2024 · 4 comments
Assignees
Labels

Comments

@eed3si9n
Copy link
Member

Steps

See https://dotty.epfl.ch/docs/internals/best-effort-compilation.html

One of the goals of this feature is to keep the maintainance cost low, and to not let this feature hinder the pace of the overall development of the compiler. Because of that, the tests can be freely disabled in compiler/neg-best-effort.blacklist (testing TreePickler) and compiler/neg-best-effort-from-tasty.blacklist (testing TreeUnpickler).

Problem

This is a friendly reminder about Inclusive Language Guide - https://docs.scala-lang.org/contribute/inclusive-language-guide.html

blacklist/whitelist

While the etymology of these words has no relation to racism, their use suggests an association between the color black and some form of badness or exclusion, and between the color white and some form of goodness or inclusion. Prefer alternatives when possible. Several alternatives have been proposed but none sticks as “the one”. We suggest using the pair denylist/allowlist or the pair excludelist/includelist, as these are generic enough to replace most uses of blacklist/whitelist.

Expectation

Thankfully, the term seems to be mostly limited to GitHub issues and testing, so I'd appreciate it if we could switch to something like excludelist. Thanks!

@eed3si9n eed3si9n added itype:bug stat:needs triage Every issue needs to have an "area" and "itype" label labels Nov 20, 2024
@dwijnand dwijnand added itype:enhancement and removed stat:needs triage Every issue needs to have an "area" and "itype" label itype:bug labels Nov 20, 2024
@Gedochao Gedochao added area:documentation itype:meta Issues about process/similar labels Nov 20, 2024
@Gedochao
Copy link
Contributor

While we're at it, we can take the opportunity to audit the whole codebase, focusing on usage of inclusive language.
Optionally, we could even have a script to check for words we should avoid automatically.

@Linyxus
Copy link
Contributor

Linyxus commented Nov 20, 2024

We might try writing a script to feed the whole codebase through ChatGPT for inclusive language as a good start point.

@jchyb
Copy link
Contributor

jchyb commented Nov 20, 2024

While adding the aforementioned exclusion lists I considered changing the name, but all of the other exclusion lists in compiler/test/dotc already had that standardized naming scheme - I feared breaking out of that would unjustly paint those past additions a certain way, which I wanted to avoid. I didn't think about having to mention these in user-facing documentation, which ended up happening here (I apologize!). Having all of those files in compiler/test/dotc changed all together at once seems like a great solution I fully support!

@eed3si9n
Copy link
Member Author

I feared breaking out of that would unjustly paint those past additions a certain way, which I wanted to avoid.

As an aside, I think we should be unafraid to correct courses especially if it makes our own or peer's past decisions less informed. Otherwise, we're now making an informed mistake. See also "Pimp my library" terminology being used, long after it was considered passé among some circle.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants