How to avoid using problematic language?

[isaacs]

Node.js is a very popular project with a huge international audience. While the API terminology is primarily in English, like most open source software projects, we accept a lot of contributions (including user-facing API design) from people of many different linguistic backgrounds.

I think it's safe to assume positive intent in most cases; ie, if someone sends a PR full of inappropriate language, ok, they're a troll, and the correct action is to ban them. But there are cases where a word choice seems perfectly reasonable to one person, but is very difficult for many others to stumble across in the codebase. Changing these word choices after the fact is probably the right course of action, but comes at a cost of disrupting existing users of that API.

Are there any processes that can be put in place to avoid situations where a word choice can be problematic/distracting/triggering/offensive to users?

[ashleygwilliams]

@HiPhish can u elaborate on the experiences of being a non white non american that u think are relevant here? we do care about that perspective.

what @mikeal is referring to is that u made an appeal to an argument that is common in these spaces and is not constructive. specifically, the idea that any word can be offensive to anyone. we, and many others, have not found this to be the case.

you might be afraid that changing some words means we might end up changing all words and muddying up the API. that's a valid concern, but is highly unlikely. instead, it is bery likely to improve the inclusivity of our community, thus improving diversity and all the great things that come with that.

[jasnell]

@HiPhish ... please consider this a first warning. @mikeal's comments were quite clearly directed at your argument and could not be reasonably interpreted in the manner you suggest. Further comments of this nature will be interpreted as "trolling" and you will be blocked. You are obviously welcome to your own opinions, and there's no expectation that everyone should agree, but please keep your comments constructive and on topic.

[HiPhish]

@ashleygwilliams My mother is computer illiterate and bad at computers. I never implied that she was dumb. Being computer illiterate doesn't make you dumb, just as not knowing the intricacies of plumbing does not make you dumb.

instead, it is bery likely to improve the inclusivity of our community, thus improving diversity and all the great things that come with that.

What does that mean? People who are under stress cannot code, because they cannot think rationally. That's simply a consequence of being under stress. And people under stress are the only ones affected by just words. Therefore the entire discussion is based on a false premise.

[ghost]

And people under stress are the only ones affected by just words.

i wouldn't just limit it to only that. i know a few people that are very emotional and can get hurt by using the wrong choice of words against them, even if they're not under stress

[ashleygwilliams]

@hiphish i think we need to end this convo because i am now very confused also i am on an airplane that is taking off.

that being said im stressed often but still code well. i dont understnad your point.

[mikeal]

@HiPhish umn no, you don't get to use the phrase "Even my mother could understand that" and then claim that you were not making reference as to "mother" being "dumber" than the subject. That was the entire point of the phrase.

Your insistence on turning this into a narrative in which you are the victim is disturbing and quite distracting from any substantive comments you might be trying to make.

[ghost]

i gotta agree with @ashleygwilliams that we should end this convo because i see typing mistakes popping up everywhere (& that's never a good sign), and i can't really follow the discussion anymore

[Fishrock123]

Back to https://github.com/nodejs/inclusivity/issues/9#issuecomment-155759123

(CI for this idea-ish)

I think this would be best implemented as a separate CI that automatically runs on PRs and delivers a GitHub status. I think we could work with that kind of thing.

Integrating it into regular CI runs unfortunately isn't so nice since we already get a lot of failures for various (mostly hardware and jenkins) reasons and it's already hard to sort though those.

(Also: full CI runs have to be activated by a collaborator due to certain security concerns regarding the build machines and code run on them. This task would not have that issue.)

[jasnell]

@Fishrock123 .. before we get too far down the road of automating it, can we do a one time manual pass over the existing code to see if there are any existing issues that ought to be looked at first?

[HiPhish]

@ashleygwilliams I don't mean stressed as in "I have an appointment in five minutes, I still have three months of bills to pay" kind of stressed, I mean an actual stress state. You know where people's flight-or-fight instinct has been triggered.

@mikeal I am not trying to paint myself as a victim. I had been through tough shit in my life, I have been through good things in my life. The point I am making is that people do not need to be shielded for what an arbiter decides to be "triggering" content. Coping with what happened to you is the first step to getting better, and yes, that includes being abled to get exposed to words and images. It takes time, but people who have been under actual shock are in no condition to contribute to a software project anyway.

Shielding yourself from words is doing yourself a disservice and such a practice must not be encouraged. Even if you mean well you are actually harming people more that way. To make a blunt analogy, imaging if someone fell down the stairs and got hurt really bad. Would you keep that person away from stairs or help them get used to stairs again?

[Fishrock123]

@jasnell I never suggested that we wouldn't. This is discussing ways they we might be able to extend something into the future.

[mikeal]

I am not trying to paint myself as a victim. I had been through tough shit in my life, I have been through good things in my life. The point I am making is that people do not need to be shielded for what an arbiter decides to be "triggering" content. Coping with what happened to you is the first step to getting better, and yes, that includes being abled to get exposed to words and images. It takes time, but people who have been under actual shock are in no condition to contribute to a software project anyway. Shielding yourself from words is doing yourself a disservice and such a practice must not be encouraged. Even if you mean well you are actually harming people more that way. To make a blunt analogy, imaging if someone fell down the stairs and got hurt really bad. Would you keep that person away from stairs or help them get used to stairs again?

As a software project we don't have the ability to change how certain words effect individual people and thus exclude them from our project. What you may believe is the best way for them to deal with their feelings is moot, whether we agree or not, because we simply don't have the ability to change people on that level. As such the only way we can include them is to remove the language, which in many cases is quite simple.

You can disagree with that approach but doing so means that you're valuing your prescription for how they should deal with these issues over including them in the project.

[MylesBorins]

@jasnell / @Fishrock123 I have done a pass at lib/ and here are some of the highlights... I am avoiding categorizing or ranking but I am removing false positives

• host (used through code base in many files)
  • host may be insensitive, use presenter, entertainer instead

_http_client

• crazy (used in a comment in )
  • crazy may be insensitive, use rude, mean, disgusting, vile, person with symptoms of mental illness, person with mental illness, person with symptoms of a mental disorder, person with a mental disorder instead

\ domain **

• stupid (used in comment)
  • stupid may be insensitive, use foolish, ludicrous, unintelligent instead
• insanity (used in comment)
  • insanity may be insensitive, use rude, mean, disgusting, vile, person with symptoms of mental illness, person with mental illness, person with symptoms of a mental disorder, person with a mental disorder instead

zlib

• stupid (used in comment)
  • stupid may be insensitive, use foolish, ludicrous, unintelligent instead

url

• psychotic (internal variable)
  • psychotic may be insensitive, use person with a psychotic condition, person with psychosis instead`

internal/repl

• disabled (part of a printout, would not break anything)
  • disabled may be insensitive, use turned off, person with a disability, people with disabilities instead

docs The words "host", "illegal", and "disabled" come up many times in the docs... those are the only warning. "disabled" could be easily replaced with 0 consequence as they are not making reference to the api.

src/node.cc

• stupid (used in comment)

src/node_crypto.cc

• disabled (used in comment)

src/node_i18n

• disabled (used in comment)

test

Not going to list them all.. but once again a combination of disabled, host, and crazy (or something to the same effect). There was also some examples of gender pronouns.

TLDR to follow below

[therebelrobot]

You can disagree with that approach but doing so means that you're valuing your prescription for how they should deal with these issues over including them in the project.

I would add to that, the goal of this endeavor is not to "heal" or "shield" people of things that have hurt them. If someone needs healing and shielding, there are trained professionals who can assist with that, who are much more qualified than anyone here. This project does, however, concern itself with 1) good code, and 2) getting as much good code as possible through inclusivity. This, then, is a recognition that certain words will drive off some developers, and if those words can be avoided, it means they can help in the project. End of story. Not to decide authoritatively what is triggering for all, but to collaborate and determine as a community what would be a reasonable trigger for a large portion of the user base, and remove them so those affected can feel like they can contribute as well. That's why a diverse team is needed for @nodejs/inclusivity, so that it's not just cis/het/white males in SF that decide that. If you don't count yourself among those affected, and do not wish to review the code for these changes, then you don't have to. On the flip side, if you feel like you want to add your perspective to the inclusivity of the project, you can contact/apply to the inclusivity team to assist in deciding measures going forward.

[MylesBorins]

So it seems as a project node is doing fairly well based on the quick pass with alex. The majority of our flags are for the words "host", which has historical context is is not likely to change.

Aside from that term there are a handful of instances, in documentation only where we could choose to use words that are just as effective.

It would be best, imho, to treat this subject with the true pragmatism that developers are known for. If a change has the potential to make the project more inviting to any human being, and the technical risk is low (in the case of changing suicide), or none (changing the words disabled and stupid in the comments), then there should be no reason not to.

[therebelrobot]

If a change has the potential to make the project more inviting to any human being, and the technical risk is low (in the case of changing suicide), or none (changing the words disabled and stupid in the comments), then there should be no reason not to.

+1

[MylesBorins]

The one thing I do think that we need to be cognizant of is that being inclusive of everyone does include being inclusive and understanding to those who are not neurotypical. Our industry and community is made up of many outstanding and brilliant individuals who's brains genuinely function differently, and do not see this problem the same way.

We need to make sure that we treat those who are contributing with the respect they deserve, and make sure to not attack those that may just need some guidance or compassion when trying to navigate the landscape of node.

[mikeal]

@HiPhish this isn't the place for your comments about words that do not even appear in our code. This is about a specific code base with specific language which we are changing to be a more inclusive software project. Also, if you think the project's strategy of attracting many contributors is a poor one that should be another issue entirely, because that is broadly the strategy for the entire project and foundation and has been since the foundation was formed.

[juliepagano]

One of the goals of the inclusivity WG is to get people from the impacted demographics involved, precisely so that this isn't the strawman of the privileged making decisions for the marginalized.

[juliepagano]

+1 on being pragmatic about this. Trying to re-word very commonly used computing concepts (e.g. host, kill) is a bit much. Comments seem like the easiest low-hanging fruit to address as a starting place and guidelines can hopefully help keep them in a good state moving forward.

[andrewdeandrade]

I mentioned this on #17, but I find the focus on language semantics and visceral negative reaction to those that use language in culturally insensitive to also be very unwelcoming to those that either are non-native speakers or who have a strong command of English, but by virtue of also viewing the world through the semantics of a second language might accidentally offend.

I would much rather see a tolerant community form that learns to work together DESPITE our differences instead of this highly anglo ethnocentric direction discussions are taking. The English usage we are tolerant of should be English as the common language used by software engineers from anywhere in the world regardless of accident of their birth location or whether or not English is their first or second language. It should not be native English and all the cultural baggage associated with it that Americans (or the British) carry with them.

I would hope that anyone who has ever misused a word in a language that isn't their native one will appreciate this point.

I would also hope that people be aware that the connotation of a word are also aware of the etymology of a word before they project their own cultural baggage upon that word and demand that language usage change because they are offended when the actual etymology of a term causes no offense. This is a path towards tolerance and acceptance. One example I've seen mentioned somewhere was someone claiming that the Finger protocol has sexual overtones when the actual origin of that computing term comes from "snitching" as in "fingering (pointing out) someone from a police lineup".

FWIW, native English speakers comprise a mere ~5.52% of the world's population. You're making this community unsafe and unwelcoming to a LOT more people than you're including by fostering intolerant semantic pedantry among native English speakers that are already among the most privileged in this community.

[junosuarez]

@malandrew for the sake of the scope of this thread, which I see as focused more on process (eg how do we make sure this happens) vs policy (eg what should be the strategy), perhaps it would be better to open a separate issue to discuss how @nodejs/inclusivity can address being inclusive of non-native-English speakers (and people with limited- or no- english proficiency).

[mikeal]

@malandrew your assumption is that this language will be punitively policed when in reality it will be enforced the same way code style is enforced which is to correct during review in a non-punitive manor whenever the author is not intentionally offensive.

[andrewdeandrade]

@jden My point is that this thread is solving the wrong problem. We shouldn't be trying to avoid problematic language because doing so fosters intolerance and creates and environment hostile to those that don't see language as problematic because they aren't native English speakers that grew up in the US or Great Britain.

A better question is "How do we create an environment where tolerance among community members is rising instead of decreasing?". This entire discussion promotes intolerance and serves as an example of intolerance being a new cultural norm.

As one of the weird nerds growing up, this growing environment of intolerance (of which this thread is an example) and victimhood is frightening.

[andrewdeandrade]

@mikeal You and I both know that that hasn't been representative of what has happened in our community. Today it might be 999 times out of 1000 that things quietly are dealt with via code review. How about that occasional event like with BN where professional reputations were at stake? Tolerance in this community is declining, not rising, so while today it's 1/1000, tomorrow it could be 1/100. All it takes is one person who likes to incite a mob to take something to twitter and then the peanut gallery shows up. The leadership I've seen has yet to step in and stop the peanut gallery (in fact, several have actively participated in it).

"It is better that ten guilty persons escape than that one innocent suffer"

[andrewdeandrade]

Anyways, that's my last comment in this thread because I've already been the victim of this rising intolerance once before.

[HiPhish]

@malandrew

A better question is "How do we create an environment where tolerance among community members is rising instead of decreasing?".

You don't https://www.youtube.com/watch?v=0OzL0tGygso

This is something that will sort itself out. If people talk like edgy teenagers they code like edgy teenagers as well. Just ignore them and the problem will solve itself.

[juliepagano]

@malandrew @HiPhish We'd like to try to keep issues on topic. I've created an issue (linked below) to discuss your specific concerns. If you'd like to continue the discussion, please take it over there. Thanks!

https://github.com/nodejs/inclusivity/issues/19

[tracker1]

Perhaps PRs that include changes to the public API should be flagged for review by @nodejs/diversity ... Not all changes have. While I agree with @malandrew in terms of people generally being overly sensitive and spreading new kinds of intollerance, there could be some issues with terminology that are poor design choices, such as the issue the @isaacs mentions towards the top of this thread.

While I am not suggesting that we change the past, or revert prior design choices. I also feel that keeping in line with common technology terms are usually more appropriate. I am in line with the suggestion that future changes should probably be looked at more proactively. There are times where society needs to adapt, and there are times individuals need to adapt. Context is everything.

[950c]

The word "disabled" (as opposed to "enabled") for a setting is now a bad word? Along with "host" and "illegal"? Are you guys shitting me?

[jasnell]

@Fishrock123 ... at this point, I'm -1 to introducing any kind of automated checking as part of CI. A check through the code does not highlight any other obvious potential issues that cannot be handled on a case by case basis as necessary. Documenting a best practice as part of the contributor guidelines to watch for things that potentially could be problematic is fine.

I recommend closing this issue.

[MylesBorins]

+1 on closing and locking.

[andrewdeandrade]

+1 on ending all PC discussions (from both those in favor and those against) and focusing on only issues that actually impact how the NodeJS source code functions.

Inviting all this discussion in the first place has been one of the most toxic things I've ever seen in the open source community. 99.99% of open source projects get by just fine without any of this discussions. There's nothing inherently special about the scale of NodeJS that suggests that it should be run any differently that any of the projects of smaller scale.

Code is neutral and should be managed like Switzerland when it comes to PC issues. There are plenty of forums to have such discussions without poisoning this well with bikeshedding discussions (which is exactly what any PC issue is). We should acknowledge that all this is bikeshedding and banish it in favor of issues that actually have to do with features, bug fixes and other objective improvements to the NodeJS codebase.

[samis]

@malandrew :+1: NodeJS is about code and it's functionality. Not about subjective differences and discussions (including, but not limited to PC discussions.)

[ashleygwilliams]

Hi @samis @malandrew , I'd like to reiterate https://github.com/nodejs/inclusivity/issues/9#issuecomment-156541929: The question of whether or not we care about language is not currently up for debate in this issue. This issue seeks to explore solutions on how to implement this care.

The working-group has already decided that people and language and feelings and inclusivity matter. If you'd like to discuss ways to handle that, then we welcome your participation. However, further claims that code is somehow "neutral", somehow not about people or their feelings, etc, will be considered derailment.

[andrewdeandrade]

@ashleygwilliams In another thread @jasnell stated that the inclusivity working group doesn't even have an official charter and is up to debate, so stating that that ship has sailed and it's not up to debate misrepresents the facts:

https://github.com/nodejs/inclusivity/issues/19#issuecomment-157184766

That said, I'm not saying that language doesn't matter (as someone who identifies as pomosexual, I'm as careful about avoiding gendered pronouns as anyone I've ever had discussions about gender with). What I'm driving at is that the working group should be aware of the intolerance ramifications of fostering an increasingly politicized atmosphere that is exclusive of those who wish to avoid politics and focus on code. I am not debating the merits of such things. I agree with you. I am debating the merits of making the NodeJS community of forum for political agendas, because politics does alienate people.

[junosuarez]

I'd like to repeat the call to close and lock this thread, as multiple good process and tooling suggestions have been offered to the OP and we don't seem to be covering new ground.

[andrewdeandrade]

+1 on locking.

[ashleygwilliams]

there's no need to close or lock the thread. we will close it when we decide on a solution and then ship that solution. you are, however, welcome to stop commenting or participating whenever you would like.

[juliepagano]

+1 to keeping the thread open. We need to codify how the working group is handling issues and write it down for clarity, but the current expectation is that threads stay open until an issue is resolved or deemed that it won't be resolved. Neither has happened here, so it shouldn't be closed.

[Meai]

Ok regarding the "kill vs. stop" debate: I actually think it's very problematic to change this because there were some guys battling and fighting to figure out how to end processes in a reliable manner for good and when they found the final solution to this problem they named it. You all come from a place of privilege regarding this matter, having not figured this stuff out for yourselves and enjoying the fruits of the labor so I suggest we drop this matter and keep the name as intended by the people who fought for this problem in the first place. Checking your privilege is one of the main things we have to do here.

[Meai]

TRIGGER WARNING: @ashleygwilliams uh and regarding your "don't be rude" comment.. I actually think that's really offensive of you to imply that he was being rude, he was probably UNAWARE of his privilege and pointing this out to him without a trigger warning is actually problematic. I suggest you check your privilege ashley.

[Lambdara]

@malandrew

What I'm driving at is that the working group should be aware of the intolerance ramifications of fostering an increasingly politicized atmosphere that is exclusive of those who wish to avoid politics and focus on code.

Well said. I'm not involved with Node.js in any way, (and never will be, probably) but I have been viewing these discussions from a distance and am concerned. Everywhere I go, things are getting more and more politicized. It really puts me off and I'd never work with people who are so hypersensitive. Often not even about things said to them, but just the possibility of offending some other person in some group they think deserves protection.

Being Dutch, this concept of politicizing everything is somewhat foreign to me, but I can see it creeping in, everywhere. I had the illusion that the coding community would just care about coding, but I'm afraid I'm wrong. Forums on programming are littered with identity politics, and even in Node.js we are asked to watched our words. I just hope all this political bs will come to an end very soon.

I'd never work with a team which takes the attitudes prevalent here. I just hope there will be plenty of teams where this will never be the norm.

[Fishrock123]

Back to the OP's question and https://github.com/nodejs/inclusivity/issues/9#issuecomment-156554098, I think it is most reasonable to take a look at words that we ourselves use that aren't apart of another layer / common outside terminology. Like, suicide is our mess, host and disable / enable are not.

Aside: I don't understand how Host is possibly insensitive? http://www.merriam-webster.com/dictionary/host & https://en.wikipedia.org/wiki/Host

Edit: I guess:

Host (psychology), "personality" as emphasized in treating dissociative identity disorder

But that's the far less common usage.

Aside no.2: English is terrible and doesn't have enough words for types of things.

[wooorm]

@Fishrock123 Alex catches host because it is (depending on its use) masculine (hostess being feminine, Wikipedia). Similar to steward and stewardess. Opting for a different word (presenter or entertainer, and in the other example flight attendant) doesn’t have this gendering / binary-thinking.

Of course, the word is used differently in networking, but some people would still prefer an alternative because of this connotation.

[Fishrock123]

@wooorm Good catch and noted, although at this point I don't think it's a good idea to change that.

[Lambdara]

I hope you are sane enough to not be that oversensitive right? host is offensive because it's masculine? You gotta be kidding me.

Is this a case of poe's law or something?

[juliepagano]

There is near consensus here that it doesn't make sense to "fix" words that are common programming language terms (e.g. host, kill). Considering that, let's focus the discussion on avoiding the addition of new apis/comments/etc. that add new terminology that is unnecessary/unwelcoming/etc.

[Lambdara]

@juliepagano Please help me understand this, because I don't get it at all. What could possibly be 'unwelcoming' terminology? Are you guys working on the gofuckyourself API or something?

[juliepagano]

@Wysaard The issue linked near the top of the thread is an example of unwelcoming terminology that does not have a preexisting basis in programming terminology. It's not a common occurrence, but it would be nice to minimize these sorts of things being added to the codebase in the future.