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?

[mikeal]

While this is certainly a historical problem I wonder if it is a current one. We have roughly 10x the number of active code reviewers we had when most of the current API was defined and they are from an incredibly broad set of language backgrounds.

[indutny]

I think the most effective way to do handle this is to have a LGTM from @nodejs/diversity on release PRs.

[indutny]

@mikeal the review takes two persons, so the commit may land without broad attention.

[mikeal]

@indutny while that's a good idea, the active level of engagement from this WG has not to date been enough to effectively review weekly releases. Also, we should be catching these in code review rather than release since we can now land semver-major code long before it is ever released.

[indutny]

@mikeal I totally agree with you that catching it early is ideal case. However LGTMs on releases from the diversity WG should be a very good start. We can always cancel release, or change the version number if there are any serious problems.

[ashleygwilliams]

hi! i am interested in volunteering time/effort/labor to improving this. how can i help? would be very happy to do review. i know there is a diversity WG. i hear it might need some more diversity on it...

[therebelrobot]

@mikeal I think there's a good reason to have @nodejs/diversity be kind of the failsafe for releases, though catching them in code review would be ideal. I'd be willing to chip in for those reviews as well.

[junosuarez]

@thealphanerd asked me to post this here: https://github.com/wooorm/alex

This is a tool for linting English for sensitive terms- they have a fairly comprehensive list of checks and theirs issues threads always have good conversations and insights.

[mikeal]

@therebelrobot that might sound good but the reality of the release process makes this kind of process a poor fit. we've actually optimized the development process to take care of all of these kinds of guarantees so that releases can be produced with little to no additional process.

however, we could explicitely document these guidelines in the contribution policy and note that the process for flagging something problematic would be to @ the diversity wg?

[Qard]

It might also be good to train existing collaborators on terminology sensitivity, so we're aware of what sorts of terms may be offensive to some people. Not all collaborators speak English natively, and may not understand the importance of particular uses of words.

[therebelrobot]

we've actually optimized the development process to take care of all of these kinds of guarantees so that releases can be produced with little to no additional process.

Fair. +1 to adding to the contribution guidelines.

[mikeal]

@jden wow, that's cool :) As long as we have a way to only send new diffs through it as we're sure to trip it up on all the underlying terminology we essentially proxy.

[MylesBorins]

There are NLP related linting tools that can be used for problematic language... although I doubt we are going to want to fix the current problems (such as the words master, host, etc...)

What can help is on boarding more people into collaborators who have an active passion to see this kind of stuff be better.

Right now I'm following every issue / PR via email... it may be quite a bit of work, but with enough eyeballs ....

edit: missed jden's response above... but we totally could write a CI tool based on this

[mikeal]

@Qard so, I think it's a good idea to stay away from putting this kind of barrier to entry on contributions. As @isaacs noted quite well, you can tell the difference between deliberate and non-deliberate violations and as long as we have a strong enough review process to correct this it's better than adding barriers to non-native-english speakers prior to their contributing.

[ashleygwilliams]

busting in here, again. let's get some diversity in the reviewers, i think that's gonna help a lot.

empower the people who care. it'll go a long way.

[mikeal]

There are NLP related linting tools that can be used for problematic language... although I doubt we are going to want to fix the current problems (such as the words master, host, etc...)

Remember that the Node.js project is much more than core, we could adopt these linting tools on the website with little to no existing issues (the API docs are in a different repo).

[nebrius]

@ashleygwilliams invite sent for the diversity WG, let me know if you got it.

[ashleygwilliams]

@nebrius yup!! thxx

[therebelrobot]

@nebrius, I'd love to assist with the diversity team as well, if there's still room.

[mikeal]

Quick note for whoever ends up tackling this documentation.

We need to get a lot better about making the project accessible to non-native english speakers. Using words that are english metaphors for behavior does not help. Using unnecessary big words in documentation also does not help. Ideally we could produce a set of guidelines that are easily understood and also easily translatable.

[Trott]

I'd encourage anyone expressing interest in the Diversity WG more broadly to also look at https://github.com/nodejs/diversity/pull/7 and comment.

[jasnell]

Before attempting to put too much policy into place, let's be sure to at least take a look at whether it's actually that wide spread of a problem. In the cases where certain questionable terms (like suicide) appear, there may not be a good technical argument to make for changing the terms but there's also no good reason not to change them. So long as we follow our existing processes for reviewing commits and resolving conflicts, the overwhelming majority of issues can be caught.

[jasnell]

@nebrius ... hmmm. Truthfully, we can never have too many people who want to help with diversity issues. Your comment is not really how participation and membership in these working groups is supposed to be determined. You're absolutely right that we need broad, diverse and inclusive participation -- particularly from individuals who would be the most impacted and benefiting from an increased focus on diversity -- but your comment comes off quite counter to that goal.

[Trott]

I'd add that this WG doesn't actually exist yet, technically. So, currently, no one is a member, truthfully. Per the website:

A Working Group is established by first defining a charter that can be ratified by the TC. A charter is a statement of purpose, a list of responsibilities and a list of initial membership.

We don't have that yet. Go over to #7 and make this group happen!

[mikeal]

I'd add that this WG doesn't actually exist yet

"doesn't exist" is a little harsh :) The working group process assumes that a working group first runs in an "un-chartered" state while it figures out its processes and how it's getting things done.

[Trott]

@mikeal True and an important correction/clarification to what I wrote. Thanks for that.

[mikeal]

@jasnell the process the WG is using is still being refined and has some limitations other WGs don't have as some of the issues they tackle are magnets for internet trolls. However, there's issue #8 which I think addresses some of your concerns.

[jasnell]

@mikeal :+1: so long as there's not a process for explicitly determining who shouldn't be involved, I'm good with #8. The truth of the matter is, "cis white guys from SF" is as much an unwelcome stereotype as anything else, and as @therebelrobot rightfully points out, perspective can come from anywhere. Let's keep the conversation heading in the right direction

[MylesBorins]

I like this document

--> http://juliepagano.com/blog/2014/02/26/bad-ally-quiz/

Perhaps the WG should have to pass the quiz

[ghost]

@TheAlphaNerd but since that's just an online quiz, can't everyone theoretically 'pass' it? it's easy to cheat on those things :/

[MylesBorins]

@sup did you read the article?

[ghost]

@TheAlphaNerd the article before the quiz? I believe so, am I missing something really obvious here? :fearful:

[yoshuawuyts]

cc/ @wooorm this might be relevant given the work you've done on Alex. Perhaps you have any thoughts on the matter?

[juliepagano]

As if summoned by linking to my post, let me know if it would be helpful for me to participate in the WG. Would be happy to help out especially since I'm using node a bunch these days. :)

[jasonrhodes]

+100 to inviting @juliepagano on board officially :+1:

[jedireza]

As if summoned by linking to my post, let me know if it would be helpful for me to participate in the WG.

Yes please :shipit:

[MylesBorins]

@juliepagano your internet wizard skills are on point

[nebrius]

@juliepagano what's you're email address?

[juliepagano]

@nebrius julie.pagano at gmail

[nebrius]

invite sent, let me know if you didn't get it

[wooorm]

Thanks for the pings, @yoshuawuyts and @jden! I’ll promote alex a bit (hope you don’t mind)

I never intended alex to be used in CIs. It highlights a lot (by design), and humans smarter than it should choose whether its too sensitive or whether it highlights valid points.

However, I like the diff-only approach someone mentioned above, that might actually work. For example, in the below flow:

• A CI would pass the additions of a PR through alex;
• alex finds stuff in the additions, and fails that CI task;
• A member of nodejs/diversity checks it out and merges it anyway (because alex is overly sensitive) or halts the PR.

The good part about this is that this flow has some part automation (removing human ego), and some part human (removing dumb automation).

Thoughts?

[ghost]

@wooorm: That actually sounds like a decent idea, and totally doable as well. +1

[yoshuawuyts]

@wooorm that sounds like a pretty good workflow.

[thefourtheye]

I spend most of my time on code reviews in the main repo. So I guess I also can contribute to the workflow which we define here.

[HiPhish]

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?

You are wasting your time because any word can be "problematic/distracting/triggering/offensive" to someone. Let me ask you, have any of you actually been oppressed and driven to the point where every moment of your life was disgusting you? Because if you had you would not be thinking you can be some white knight for people.

Here is the fact: words have no power, they are just words. People who are stressed out by mere words are either a) unter too much to perform any serious work or b) attention grabbing spoiled brats who made up a problem. I have been in position a) and it doesn't matter how much you change the wording, you would not have gotten anything useful out of me either way.

Do you want to know what is really problematic in this issue? Privileged people who think they know better than everyone else and what to play moral arbiter. Anyone who has been down is better than this, we know that words cannot hurt us and we do not want you to speak for us. The idea that you somehow have to protect us because we are so weak that words will destroy us is purely disgusting.

---

A word should be chose so that it conveys its meaning as precisely and simply as possible. Take for instance kill: killing a process means forcefully ending it immediately. Even my mother could understand that. Replacing kill with stop would cause confusion: is it stopped immediately? Is it told to stop at the next opportunity? Does it have to honor the request? None of this is clear from the term. See how much confusion you have added in your righteous quest to?

Words need to be evaluated individually. If someone were to troll by adding a rape command that should not be tolerated. Not because it's a "problematic" word, but because raping a process does not convey any meaning.

[mikeal]

any word can be "problematic/distracting/triggering/offensive" to someone.

This simply is not true, and is the basis of your entire argument so I'm going to ignore the rest. There is a very small subset of words in any language that are offensive to some people. Those may be more words than are offensive to you but that doesn't really matter because removing words that are offensive to other people will not effect you as a user of this software.

It is not productive to tell people not to be offended by something they find offensive. The way to include them is to remove the things, when possible, that offend them as doing so only increases the number of people who can enjoy using the software.

[ashleygwilliams]

👍👍 @mikeal. the conversation here is not to debate whether this is a problem, but rather already accepts that it is and seeks out solutions.

[HiPhish]

This simply is not true, and is the basis of your entire argument so I'm going to ignore the rest.

Let me show you how it reads:

Shut up non-American minority, I as a white American know better what's good for you.

I'm going to ignore the rest because you clearly don't care about people with actual lived experiences.

[ashleygwilliams]

p.s. "even my mother could understand that" is not cool. it perpetuates the idea that moms are dumb and bad at computers.

however, moms are cool and smart. dont be rude.

[mikeal]

@HiPhish I'm advocating that language people find offensive be removed. That is not every word on earth, and you know this. I'm also not suggesting that I am the person to provide that list, and if you based on your own lived experiences have words or statements that you find offensive in the software they can also be removed. That is what is being suggested.

However, the argument that removing words that are offensive to a group of people is somehow an attack on those who don't find it offensive is an absurd argument. We're not suggesting that people who unknowingly include problematic words be attacked in some way or driven out of the project, we'll simply correct those words in the review process as we would any other style issue. You claimed that people "choose to be offended" by words, regardless of their lived experience, while at the same time you yourself are choosing to be offended by the removal of these words which have no deep meaning to you.