-
-
Notifications
You must be signed in to change notification settings - Fork 8
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
NonInclusiveLanguage sniff #59
Comments
This is a great initiative. Thank you for taking it up! I've found this list of disability terms with negative connotations a helpful resource. |
@joemcgill Thanks, though the credit should also go to @jdevalk. Thanks for the link. I've had a look through the list, but there are only a few words there which I can imagine people would ever use in a code-context, but maybe I'm wrong ? Please tell me if I am ! The only ones which sprung out at me from that list (other than those already listed above) were:
And possibly
Specific words to search for with suggestions for alternatives are most helpful to get this off the ground. @vavroom would you care to comment ? |
Very happy y'all are looking at this kind of thing :) On the term disabled, I wouldn't be too worried. While for a very long time there's been a push to use "person with a disability", instead of "disabled", there's also been a massive push for using just disabled, by disabled folks. If you look on twitter for the #SayTheWord hashtag, you'll get a feel for it. Also, the idea of ableist language is using a medical/disability related word in a negative context. A disabled button is pushing that envelope a bit. I'd not be too worried about it. Then again, I would hesitate to use disabled buttons but that's a story for another day :D @jrfnl points out correctly that dimming the screen is very different from calling someone dim. Again, I wouldn't worry about it. I'd be curious to know what blind folks think of "double-blind testing". I personally don't view it as objectionable, but then I'm not the target market of that kind of potentially ableist language. |
@vavroom Thanks for taking the time to give feedback. Much appreciated. |
This is a great initiative! I was also wondering about the terms disabled/enabled. It feels unnecessary when there are terms like inactive/off/deactivated/restricted that do the job just as well... But I'm not disabled, so I don't think I can speak with any authority. Thanks for your input @vavroom |
I think there should be room to add words that don't have suggested replacements, brazenly outright innapropriate words, such as the N word, or other derogatory terms, such as calling people with downs syndrome the M word, or the P word. |
Really glad to see this. Thank you! |
This is a good idea!
In code there is no alternative to that string, much like when spellcheck trips over |
@tomjn Good idea and those words which really shouldn't be used, should probably be an error. Is it ok if I approach you privately to verify that I interpret the letters you mention correctly ? Or ping you to review the sniff to make sure I have added the right ones ? |
Sure, but it's hardly an exhaustive list, and the P/M words might be more used in the UK than internationally. Happy to review |
If the sniffer is going to sniff for a list of naughty words, https://github.com/LDNOOBW/List-of-Dirty-Naughty-Obscene-and-Otherwise-Bad-Words aims to have comprehensive lists. |
I think there's a difference between 'naughty' words and exclusionary language. For example, I can see a bunch of anatomical and sex related words on those lists which aren't necessarily used in a demeaning and derogatory way; it's less clear cut - and could end up being exclusionary in and of itself. |
Honestly we should probably make that sniff a separate issue and just go for the main goal here. |
I will add my honest opinion that will get a lot of downvotes i guess - people and their behaviors are racist, ethnocentric, abilist etc, not a words themselves used in totally other context. But yea, if it won't be enabled by default using this package or included in core ever then why not? Someone wants to use then feel free i guess. Otherwise idea is pretty cool because i understand that whitelist/blacklist is not really great naming, allowlist/denylist is much more self explanatory - but creating it as NonInclusiveLanguage and due to racist is just wrong - because those words are not racist themselves, people using them in wrong context are. You could combine word black with many other nouns - which if said in wrong context can be racist and offended as well, not only At this moment i am offended by this issue and description of it because of this:
So you are telling that if i currently use blacklist/whitelist i am racist and you suggest that i can have hostile work environment? Idea for this sniff is great, but explanation why it's needed is wrong. This description should be changed honestly. |
@Jurigag The thing with racist words, or ableist words, is that it's about the people who are on the receiving end of those words. For example, I run https://ableist.is, a site to help make people aware of their own ableist language. I sometimes point people to that site. I am regularly told things like "I didn't mean crazy in a bad way, I'm not ableist". And it doesn't matter at all what they meant. What matters is that there are a lot of people for whom that word evokes really bad stuff. The fact that you are offended that the language used in projects could create hostile work environments indicates that you are not likely part of one of the groups that are routinely discriminated against. The words you use, the actions you take, do not mean that you are racist (or sexist, or ableist). But it's not about you. It's about people that these words hurt. With all due respect, your intentions mean very little. I did not intend to drop a glass but I did and my wife stepped on broken glass bare foot and got hurt. My intentions there mean very little. End result is my wife got hurt. It's a similar thing with racist words, or ableist words, or other words. And when words like that are used in projects, people may feel, consciously or not, that it creates a hostile environment. Everytime I hear people use words like "cripple", "lame", "crazy", it feels like yet another micro-aggression. I deal with these things several times a day, every day. Each instance isn't particularly bad. Just like one paper cut isn't particularly bad. But if you add them up at the end of the day, the week, the month, the year, it takes its toll. Check your privilege. |
How blacklist is hurting anyone? The origins of this word are not related to skin colors/race, we as people recently added this racist implications to it. Then why not ban whole |
Nobody said you were racist/sexist/ableist; we said the language is. You've been informed and you have a choice. Make of that what you will. |
Yea you said that language is, but also my work environment can be hostile due to those words and that's why i feel offended. |
So don't use them? |
This issue is concerned with the implementation and details, it isn’t the
venue to air personal political opinions, let’s keep the issue focused,
constructive, and move forward.
|
Why? Those words are not racist for me in the context i use and i will keep using them. Words are not racist, people using them and their behavior to offend other people is.
I agree, then change description about things like hostile work environment or that those words without any context are racist. First post here has already air personal political opinions, that's why i am concern about this, i agree about the idea, but i feel this is yet again some kind of attack to other people like |
I can only repeat what I said earlier. It's not about you. It's not about your intentions. It's about how people can react to these words. Using racist or ableist words don't necessarily make you racist or ableist. You may not intend to create a hostile work environment. Nobody is saying you are racist. But. It's not about you. Check your privilege. |
And i just disagree with this, because this way we will just go to ban whole This issue and feature would be great - but without racist implications and suggesting that someone has hostile work environment because they use them. There are many other to explain why we should not use blacklist/whitelist in programming, like they are not self explenatory - allowlist/denylist are much more. |
Check. Your. Privilege. 'nuff said. |
And i checked, currently there is freedom of speech, and i can use any words i want. And anyone has privilege to it. Ideas like this are trying to remove some words from use/vocabulary and to reduce freedom of speech, because someone suggests that they have racist implications. You still didn't answer why not ban You are currently saying that no matter what words i use and what i mean - if someone of other color of skin feels offended by it - i am racist. This logic is just wrong. |
@Jurigag I'm going to ask you kindly to remove yourself from this discussion.
Please regard this as a formal warning. |
Is this just for American English, or will there be region-specific sniffs for other countries' dialects of English? Is there a significant non-English-speaking PHP community that would justify creating a set of sniffs for non-English languages? The reason I ask these questions is because separating sniffs by region or language may be easiest to implement from the beginning, rather than adding afterwards once people have integrated the first-contributed sniff into their workflow. |
A downside of region-based or language-based sniffs is that it would result in code duplication across sniffs where different cultures share some noninclusive words or phrasings. To reduce code duplication, would it instead make sense to have separate sniffs for each separate sort of noninclusive language, allowing sniff-runners to choose which noninclusive language sniffs apply to their situation? As an example, having a sniff for |
@benlk Thanks, that's useful input and actually something I have been thinking about, though I haven't taken a decision yet. My current thoughts are along the following lines:
Code duplication won't be much of an issue as that can be prevented by using an abstract sniff and/or traits for the shared code. |
You've reminded me of the ignore comments, and while I agree that those work in some situations, I'm not sure that they're the right option for inclusiveness sniffs. Having one monolithic NonInclusiveLanguage sniff implies that there is One True Way™ to do Inclusiveness™. Including by default a sniff for gendered language would be anti-useful to an organization whose practice of inclusiveness involves gendering people by their desired gender. (Anecdote: As they/them is increasingly used for a third gender role in English-language discourse, the more people I see who reject its indiscriminate application to everyone as a form of mass misgendering, each instead desiring for themself he/him or she/her.) If such an explicitly-gendered organization wanted to add inclusiveness sniffs, requiring them to add comments around all their gender-someone-correctly code would be an obstacle to incorporating all of the other inclusiveness sniffs. I've already said my piece on cases where a sniff for Separating the inclusiveness sniffs into separate sniffs cuts the Gordian Knot of competing access needs by allowing each sniffer to use the sniffs that suit their community's needs, without requiring defensive commenting against the sniffs that satisfy other communities' needs. There's precedent for splitting out sniffs: this repo has contradicting sniffs for the PHP short list syntax; it doesn't package a monolithic ListSyntax sniff. |
I can foresee that adding a choice of pronouns on a user profile would be caught by the sniff as originally proposed. Is there a mitigation that can be applied? Such as restricting to code comments, or testing for conditional structures or pronoun selections in surrounding code? |
AFAICS, the sniff as proposed would not be triggered on that as those would be contained in text strings and the proposal does not cover those. |
|
That is simply a lie. Black-and-white dualism has a loooong history of being used as a metaphor. It's traceable to 4th century BC and is connected with the day cycle when after the day comes the dark night. It goes back to "Table of Opposites" by Pythagoras (yes, the same Pythagoras). Like you said, please, next time, educate yourself and don't create your own theories. As it goes for blacklist/whitelist it is overused in tech world and sometimes there are better alternatives for names that say more for the rest of programmers. Is it a role of CodeSniffer to check on that? I am not sure. A lot is lost without context and I think that sniffer won't ever work properly. |
I have a problem with such accusations. A lie generally implies intent to deceive. Perhaps the information @jrfnl found isn't accurate - but it is "common knowledge" that is floating around a LOT and I wouldn't blame anyone for accepting it as making sense. |
It's probably beyond the scope of this sniff to suggest specific alternatives to blacklist/whitelist and master/slave, because what the functions labeled with those words actually do varies by project. However, a sniff for those words could link to lists of suggested alternatives, such as https://tools.ietf.org/html/draft-knodel-terminology-01#section-1.1.1 for master-slave and https://tools.ietf.org/html/draft-knodel-terminology-01#section-1.2.1 for blacklist-whitelist. Those two links are from a draft RFC that never made it past the draft stage, but I'm sure there are similar yet authoritative lists from standards bodies that can be referenced in the sniffs' messages. |
Choosing a specific perfect replacement for master/slave or whitelist blacklist shouldn't be necessary, there are lots of alternatives that fit various contexts while remaining inclusive. |
We should just straight up use 1984's Newspeak to be 100% sure no-one is offended by anything. |
I thought I lost all faith in humanity, but if the above poster missed my sarcasm , then I lost that one bit of faith in humanity I didn't know I still got. You people are so paranoid about racism x-phobias and 'oppression' even if we all were Dr. Who identical Cybermen you'd still complain. You stop disenfranchisement of minorities by stopping seeing them as fragile minorities in need of help but as your equal. You stop racism by ignoring race, not making everything about race. And censoring half of the damn language to try and make offensive language impossible is, ironically, impossible itself. TL;DR Chill the *** out everyone. |
This is a professional setting. Juliettes warning was not an invitation to
express personal political beliefs. The question of wether this has any
impact on people is not the purpose of this issue ( and has been thoroughly
answered elsewhere, and with firsthand examples here ).
Let’s move forward constructively and respectfully.
|
Is disagreeing with the change altogether constructive and respectful? |
@Foxar No, that's not helpful and outside of the scope of this issue. Nobody is forcing you or anyone else to use this sniff once it is created, so if you disagree with the principle of it, just don't use it. It's as simple as that. This issue is open to allow people who are interested in using this sniff to voice their opinion about the proposed implementation, nothing else. |
Saw passlist / stoplist as suggestions here: https://twitter.com/dan_abramov/status/1272242325029257223?s=21 |
@JapanYoshi Yes, weird could be a good alternative. Depending on context, wild could also be used. There are several possibilities. |
I want to believe that this is a joke... |
Democracy and freedom of speech are not welcome here. |
for word lists have a look at https://alexjs.com/ |
also just removing belitteling word https://github.com/OskarStark/doctor-rst/blob/master/src/Rule/BeKindToNewcomers.php |
A sniff to examine code and comments for the use of non-inclusive language and throw a warning when found.
Specifically, the sniff should look for sexist, racist, ablist or ethnocentric language, which can contribute to a hostile work environment.
Initial word list
Input requested and very welcome !!!
Particularly on:
What to examine:
Search for these in:
For constructs, report on these only when the construct is declared, not when used, as usage cannot be changed until the declaration has been changed.
Additional notes:
$white_list
,whitelisting
etc.sheer
should not matchshe
, whilemaster
should not matchmastering
.External references:
The text was updated successfully, but these errors were encountered: