scala / scala3

The Scala 3 compiler, also known as Dotty.
https://dotty.epfl.ch
Apache License 2.0
5.89k stars 1.06k forks source link

Inclusive language on internal terminology #21988

Open eed3si9n opened 5 days ago

eed3si9n commented 5 days ago

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!

Gedochao commented 5 days ago

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 commented 5 days ago

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

jchyb commented 5 days ago

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 commented 5 days ago

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.