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.