How to avoid using problematic language?
isaacs opened this issue · comments
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?
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.
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.
@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.
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).
@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 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.
@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:
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!
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.
@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
@thealphanerd but since that's just an online quiz, can't everyone theoretically 'pass' it? it's easy to cheat on those things :/
@sup did you read the article?
@thealphanerd the article before the quiz? I believe so, am I missing something really obvious here? 😨
cc/ @wooorm this might be relevant given the work you've done on Alex. Perhaps you have any thoughts on the matter?
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. :)
+100 to inviting @juliepagano on board officially 👍
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 
@juliepagano your internet wizard skills are on point
@juliepagano what's you're email address?
@nebrius julie.pagano at gmail
invite sent, let me know if you didn't get it
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/diversitychecks 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?
@wooorm: That actually sounds like a decent idea, and totally doable as well. +1
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.
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.
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.
👍👍 @mikeal. the conversation here is not to debate whether this is a problem, but rather already accepts that it is and seeks out solutions.
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.
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.
@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.
@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.
@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.
@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.
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
@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.
@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.
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
Back to #9 (comment)
(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.)
@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?
@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?
@jasnell I never suggested that we wouldn't. This is discussing ways they we might be able to extend something into the future.
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.
@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)
hostmay be insensitive, usepresenter,entertainerinstead
_http_client
- crazy (used in a comment in )
crazymay be insensitive, userude,mean,disgusting,vile,person with symptoms of mental illness,person with mental illness,person with symptoms of a mental disorder,person with a mental disorderinstead
** domain **
- stupid (used in comment)
stupidmay be insensitive, usefoolish,ludicrous,unintelligentinstead
- insanity (used in comment)
insanitymay be insensitive, userude,mean,disgusting,vile,person with symptoms of mental illness,person with mental illness,person with symptoms of a mental disorder,person with a mental disorderinstead
zlib
- stupid (used in comment)
stupidmay be insensitive, usefoolish,ludicrous,unintelligentinstead
url
- psychotic (internal variable)
psychoticmay be insensitive, useperson with a psychotic condition,person with psychosisinstead`
internal/repl
- disabled (part of a printout, would not break anything)
disabledmay be insensitive, useturned off,person with a disability,people with disabilitiesinstead
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
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.
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.
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
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.
@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.
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.
+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.
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.
@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).
@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.
@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.
@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"
Anyways, that's my last comment in this thread because I've already been the victim of this rising intolerance once before.
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.
@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!
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.
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?
@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.
+1 on closing and locking.
+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.
@malandrew 👍 NodeJS is about code and it's functionality. Not about subjective differences and discussions (including, but not limited to PC discussions.)
Hi @samis @malandrew , I'd like to reiterate #9 (comment): 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.
@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:
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.
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.
+1 on locking.
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.
+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.
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.
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.
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.
Back to the OP's question and #9 (comment), 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.
@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.
@wooorm Good catch and noted, although at this point I don't think it's a good idea to change that.
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?
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.
@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?
@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.