Some engineers had ideas to begin brainstorming alternatives to what’s presented in the diff. Please comment here if you have any more suggestions how else we could choose to migrate this. Thanks!
Please don’t just blindly switch everything to using “soundness”, since that has special meaning in Rust (similar to how UB has special meaning) that goes beyond what “sanity checks” usually mean:
Basically something in Rust is sound if you can’t cause UB by using it from Safe Rust.
3 Likes
What about “sanitizer”, is the intention to rename that too?
1 Like
I don’t see why. “Sanitize” means “make sanitary” (i.e. clean), not “make sane”.
3 Likes
Even outside of Rust, the dictionary definition of “sound” as an adjective goes beyond sanity checks. I agree that this is not the word to replace sanity checks with.
5 Likes
Thank you for the proposal. Before merging your PR, I believe we should explicitly state in Code of Conduct about inclusive language and a list of words that should not be used.
I think It could be hard for non-native English speakers to naturally use inclusive language, so the list would give some guidelines (like it is done in Swift CoC).
1 Like
I do appreciate the intent, doing some research, because I don’t have a strong position here there are some existing discussions out there, the suggestions are all over the place although soundness does come up. As noted Swift folks seem to suggest soundness but I can see how some see it as vague.
It feels like we need to have a slightly larger discussion about what we want as alternative phrases in general. So we don’t keep having these one off discussions for each case.
“reasonableness check” sounds good to me though a bit long.
1 Like
I think there are strongly diminishing returns here. The more obviously problematic terms (master vs. main, blacklist vs. blocklist etc.) have been addressed, and the next “most problematic” remaining terms need to stretch further and further to make a compelling case for change. At some point, the next word-to-be-replaced will not be worth replacing over whatever constructed offence it may give. Perhaps a majority will consider that “sanity check” crosses that bar, but I have my doubts.
The question you linked states:
This is oxymoronic on the face of it, as an illness is a negative (“something wrong”) by definition. Of course that doesn’t mean that the person should be discriminated against. Still, even for people that are affected, overcoming (or mitigating) mental illnesses – moving towards sanity – is considered an unalloyed positive, and not something that diminishes their identity.
So I consider it quite a reach to claim that a statement for contextualising the positive intent of a technical condition is related to, let alone offensive to, an actual person[1]; much less a whole group. There are countless places in programming where code refers to “health” or “health checks”. Are these next up for replacement, because they discriminate against people with any illness whatsoever?
Ultimately, if someone wishes to find a way to be offended, they’ll be successful (and doubly so if they’re looking on someone else’s behalf). While we should strive to be empathic and inclusive, that doesn’t mean that preemptively forbidding any and all such cases by policy is a sane approach either.
and not just a hypothetical one ↩︎
16 Likes
I don’t disagree with you in general here, I think litigating each suggested wording change in a discourse thread is not a good use of our time and we should come up with a larger policy umbrella and a better way to figure out when this makes sense.
+1: seems reasonable to have a page linked off the Code of Conduct with language to avoid and recommended replacements instead. We can then discuss each term and, once agreed, do smaller PRs into the codebase to replace uses.
Looking through the PR, a big find-and-replace doesn’t seem like the correct approach. There are many places where a vaguer term like “reasonable” fits better over a specific term like “sound”. Some places we may want to rewrite to state the invariant that’s being checked.
2 Likes
What about just quick checks? Since the idea is the checks are quick and make sure you are not doing something wrong. Soundness and reasonable still a connection to one sanity while quick describes what the tests are doing.
I completely agree. Everyone is trying too hard to define what a “sanity check” means, and instead the focus should be on what it is. It’s just a bunch of checks that run fast and are expected to catch obvious problems early.
1 Like
For developers in countries where English is not their native language or there is no such political correctness, it is difficult to avoid such problems. Perhaps we need to clearly point out the inclusive language in more official way. This seems to be a community governance issue.
1 Like
I think it’s important to be careful when crafting an inclusive language policy to avoid creating an insider-only dialect that ends up creating barriers for new project contributors. I think it’s easy to come up with a well-intentioned list of recommendations that creates more policy that new contributors have to be mindful of before they can land their first contribution, and that can do more to harm project inclusivity than it does to improve it.
As has been pointed out, this is a concern for many non-native English speaking community members. So far as I’m aware, we don’t yet have an inclusive language guide, and I think that’s where I’d start before landing this PR.
If we had such a policy in place, I would accept the cost of some imprecision in meaning to get our codebase into compliance with the policy. Reviewing the ~447 file change line-by-line is probably not a good use of maintainer time.
1 Like
I am surprised by this take actually, this is making the sensitivity of the people concerned about the use of a word like “sanity” above the correctness of the documentation of the codebase. The latter to me is a very important aspect of the codebase accessibility and maintainability: reading comment and documentation that does not accurately describe what the code does is hindering newcomers to get more easily familiar with the code, as well as long term maintenance of the code in general.
I’m not opposed to a guideline that would say “avoid the use of the word ‘sanity’ and consider these alternatives depending on the context: …”, but that’s not a license for mass-replacement without consideration for correctness IMO.
6 Likes
I think it’s a tough call. There’s another tradeoff between the value of precise communication, reviewer time, and the cost of the ambiguity created by the gaps between project policy and reality. Perhaps a practical approach to future mass edits would be to break the change down along subproject lines and let maintainers exercise discretion and choose the right tradeoff for them.
What about we just grandfather whatever is in the codebase and touch it on a case-by-case, not through mass-replacement?
After all we have rejected mass-replacement for many other things that are in the policy / coding-standard because these changes don’t pull their weight in comparison to how detrimental they are.
And in comparison to what you’re proposing: these changes are not making the codebase worse (by inserting incorrect meaning), we rejected them just under the reasoning of “churn”.
3 Likes