How to avoid using problematic language? #9
Comments
|
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. |
|
I think the most effective way to do handle this is to have a LGTM from @nodejs/diversity on release PRs. |
|
@mikeal the review takes two persons, so the commit may land without broad attention. |
|
@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. |
|
@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. |
|
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... |
|
@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. |
|
@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. |
|
@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? |
|
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. |
Fair. +1 to adding to the contribution guidelines. |
|
@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. |
|
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 |
|
@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. |
|
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. |
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). |
|
@ashleygwilliams invite sent for the diversity WG, let me know if you got it. |
|
@nebrius yup!! thxx |
|
@nebrius, I'd love to assist with the diversity team as well, if there's still room. |
|
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. |
|
I'd encourage anyone expressing interest in the Diversity WG more broadly to also look at #7 and comment. |
|
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 |
|
@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. |
|
I'd add that this WG doesn't actually exist yet, technically. So, currently, no one is a member, truthfully. Per the website:
We don't have that yet. Go over to #7 and make this group happen! |
"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. |
|
@mikeal True and an important correction/clarification to what I wrote. Thanks for that. |
|
@mikeal 👍 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 |
|
I like this document --> http://juliepagano.com/blog/2014/02/26/bad-ally-quiz/ Perhaps the WG should have to pass the quiz |
|
hi @malandrew and @wooorm . thanks for your comments, we'll consider them in future discussions. for now tho, this thread is not for the discussion of specific words that could be hypothetically brought up as issues, but rather general strategies. when/if those words (i.e. host) are brought up as problematic in the node repository, these comments would be useful. until then, please do not continue to address specific words here. continuing to do so will be considered derailing. thanks! |
|
My suggestion then is to not worry about this and deal with words on a case by case basis. If no one objects to a word, it's not a problem. To do anything else is premature optimization. AFAICT, we have exactly two concrete examples of things we want to change, What I would like to suggest is that we stop this lexical witch hunt that I've seen in other threads. Unless a sufficient number of individuals independently claim to be offended by a word, it's not an offensive word. I want to emphasis the need for these to be independent claims of offense. Provide a form where people can submit a specific line of code that contains something offensive and when enough people highlight the same line independently, we can address it. The people claiming offense should be people actually reading the code. The litmus test for people actually reading the code are people contributing issues and pull requests. I can't see any reason for anyone to be reading source code besides debugging a problem to provide a detailed issue or intellectual curiosity with the intent of participating in the community. These problem words should be sufficiently rare that someone likely has already contributed before they actually encounter one. The process should be somewhat resistant to people trying to game the process for their political goals, such as recruiting many people to pile into an issue to ban a word. Honestly, anyone bandwagoning into a thread like the one about the use of the word |
|
thanks for your feedback @malandrew. however, we are keeping this issue open. |
|
@ashleygwilliams that's fine, I didn't suggest "+1 on closing this issue". Would be nice if you actually considered my suggestion instead of dismissing it as merely a "+1 on closing this issue". I didn't write it for nothing and it did include suggestions of what might be added to a process/policy. |
|
@malandrew, be aware that some people participate in these threads via email, and those email threads don't update when you edit a comment. The original email I got for your message ^^^ 3 up was just the first paragraph, which could have been construed as a "+1 on closing the issue". That being said, I'll go back to lurking. |
|
@malandrew The comments about this being a witch hunt are not constructive or productive. This is a polite request for you to focus on constructive feedback while participating in this repo. Your suggestion for a form where people submit concerns about language in the code is noted. |
|
Could someone please explain to me why it is an important use of time and effort to obsess over and change the names of things in the code of a javascript runtime, rather than actually improving its functionality? |
|
What would you call it when people are out actively looking for words which might under some really suspect circumstances cause offense to some imagined person without any real person actually taking offense and bringing up the offense themselves? I'm open to a different term than witch hunt. Would love an alternative suggestion for identifying this common scenario if you have one. |
|
The purpose of this issue is to discuss ways to address potential language changes, not to bikeshed over whether the WG should address them or not. If people would like to continue discussing that, please create another issue to do so instead of continuing to attempt to derail this discussion. |
|
further continuation of this line of argument will result in deleted posts. |
|
I would make another issue, but it would probably be deleted, knowing the past of this repository. |
|
New issues that follow the node code of conduct and are on topic for the working group will not be deleted. If you are concerned about an issue being deleted, I recommend reviewing the code of conduct and the work-in-progress group charter for context about what is appropriate here. |
|
@Wysaard your comment employed harrassing language and has been deleted. feel free to restate your comment in more constructive language. |
|
@ashleygwilliams Please enlighten me on what was 'harassing' about my comment, so I won't make that mistake again. |
|
you could have used the word complaining instead |
|
I made a new issue. Also, in response to the above post: why does it matter what word is used? The point still got across, and the word was used to show the poster's frustration. I don't see how the comment was more than an effective use of language. Silencing people because you don't like the way that they talk is hilarious irony considering the purpose of this repository. |
|
There is a huge semantic gulf between those two. Some complaints are legitimate and should be considered (i.e. the person who is actually offended by something "complains" so that others can consider whether or not there term is broadly offensive or merely something that offends one individual). Some complaints are not complaints at all (i.e. "I found this word in the source code that in a completely different context may offend people. Since we want to purge the English language of all words that might cause offense even in an unrelated context, I'm nominating it for inclusion on the list of words that will not be missed. They'd none of 'em be missed. They'd none of 'em be missed!"). |
|
Here's an attempt at something that doesn't hurt anyone's feelings: I suggest dealing with 'problematic language' in the following way: I don't even want to be involved in this entire discussion really, but I don't want to see things like this, which I consider a solution looking for a problem, spreading. And it's spreading quickly. @thealphanerd Right. If this wasn't some big project I would've seriously thought you were joking. Is there anyone here who has serious trouble dealing with a comment that uses 'bitching' instead of 'complaining'? My use of words should reflect on my immaturity if anything, but I can't see how I'm not even allowed to say such a thing. I'd also like to object to my language being harassing. Calling 'complaining about choice of words' 'bitching' does not constitute harassment as far as I'm aware, but maybe that's just because I'm not a native speaker and I haven't a clue what I'm talking about. Having said all that, I think this is my last comment on this issue. I'm sick of this whole thing, and we're not getting anywhere anyways. Happy hacking, have a good one. |
|
Regardless of what your intent might be, you should try to be more considerate of how the tone of your writing could be interpreted. I, and seemingly many others, have found several comments in this thread to sound aggressively dismissive and minimizing. Personally, I'm a bit offended that one would push so firmly against allowing the community to show some empathy for each other by simply being considerate of what terminology we choose to use. Some words are more problematic than others. Personally, I don't feel like many people would be offended by "host" but I definitely feel "suicide" could be troubling terminology for a number of people. That having been said, if the community disagreed with my assessment that "host" is not really that offensive, I would listen to what they had to say and try to accommodate their view. That's how you empathy good; you work to understand and accommodate the needs and views of the people around you. In this case, I see some people have the view that code clarity is more important than avoiding problematic terms. Maybe we're both right. Maybe it's all important and, if we work together, we can figure out the right balance? That's the whole purpose of the inclusivity group: not to be word police, but to help guide the node community toward being even more friendly and inclusive. |
|
@Qard I identify as fiction-kin vulcan and feelings of any kind are offensive to me, so please me mindful of your language as well. |
|
Can we separate out what we might deem as problematic language (what this thread keeps derailing into), and the idea of somehow checking PRs for it (whatever problematic may be) (as the OP intended)? |
|
@Fishrock123 ... I very much dislike the idea of any form of automatic CI-integrated checking. The review process for PRs is the right time and place to look for and catch those kinds of issues. On the off chance someone finds something existing in the code currently we can deal with it quickly as we've done with the To answer @isaacs original question, "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?", the answer is simple: do what we're already doing. After all, that's exactly how the |
|
+1 @jasnell |
|
@jasnell Thanks, I think you're probably right. I'm fine with closing this. I think the OP question has long since been answered. |
|
Closing then. Thank you @isaacs |
|
funny how this thread keeps coming back to life a month after it was closed |
|
Maybe there is a reason for this? |
|
@stuntguy3000 i'd presume it's because of a thread on some other website pointing to this one |
and others
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?
The text was updated successfully, but these errors were encountered: