Open eed3si9n opened 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.
We might try writing a script to feed the whole codebase through ChatGPT for inclusive language as a good start point.
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!
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.
Steps
See https://dotty.epfl.ch/docs/internals/best-effort-compilation.html
Problem
This is a friendly reminder about Inclusive Language Guide - https://docs.scala-lang.org/contribute/inclusive-language-guide.html
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!