-
Notifications
You must be signed in to change notification settings - Fork 29.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
replace suicide as a verb #3721
Comments
Where does it say we shouldn't use it? In the same vein, one could say |
I'm 👍 on replacing problematic terminology gradually, with aliases. For the Sadly, the whole unix process model is overridden with terminology related to violence and slavery... 😞 |
Don't forget the sexual overtones: mount, touch, finger... Back on topic, we can't remove the |
I'm -1 on |
Yeah IMHO I'm not seeing the benefit of changing the wording here when there would be backwards incompatibility. The word is short and to the point. As @silverwind mentioned, this is a slippery slope and in general, deviating from traditional UNIX/industry word usage (e.g. renaming I'm -1 as well. |
Can you re-scope this to just be about suicide rather than opening up the potentially endless bikeshed about every verb in the code base? |
-1 for aliasing unless the reason for doing that is very serious. That term Also, It's already there, non broken, and is purposely exposed. It's also not a security nor a bugfix. That would make deprecation a |
The whole point is that we can do this in a reverse compatible way without breaking any code, so this is just not true. I think that this verb is particularly meaningful in that a member of our community killed himself not that long ago and those of us that were close to him would rather not be reminded of it every time we use this API. |
Going back and changing everything that is potentially unfortunate or problematic is likely not worth the effort. The comment I made that kicked this conversation off in the first place was due to my forgetting that |
At some point it would be removed though and if other parts of our API have been any indication, not everyone updates their code for things like this and sometimes we end up being "stuck" with past decisions.
While that is tragic, to me it's important to separate technical, personal, historical, etc. contexts here and the suicide term as we use it in node.js is used in a purely technical context. I'd be much more open to changing the wording if for example the word was not an accurate description of what it was representing. Also, as I said, changing this one particular instance leads to a slippery slope because then we would have to evaluate the entire code base and somehow objectively determine the "offensiveness" of each word we use because of the large diversity of negative things that exist in the world. For example, what about a female coder that had an abortion and has an issue calling sub-processes, "child processes" because the world "child" reminds her of her abortion and to add insult to injury, node's built-in module is also called Deviating from existing technical terms used throughout common computing platforms and the computing industry in general because a separation of contexts cannot be made on an individual level will IMHO cause more problems that will outweigh any benefit that may come of it. That's my 2 cents. |
@mscdex There's a big gap between potentially offensive verbs we are using, and will in all likelihood continue to use, because they are adopted from the layer below us (like |
Only if nobody is using it anymore, the cost of keeping the compatibility code there is basically zero. |
There is no such thing as zero cost code. |
"basically zero" == "as close to zero as a few lines of code can get, but definitely not literally zero" :) |
Possible options: http://www.thesaurus.com/browse/terminate |
I'm personally for |
What if you change the word but not the people thoughts? |
I'm -1 for making the change at all. However, if a change is made, I'd like to use a term like |
Not a contributor, but -1 as a node user. This renaming potentially offensive terms is getting out of hand in the open source community. These unix terms have been around for years and they are fine. Who is even getting offended? |
Can someone show me where suicide is a commonly used unix term? I can't find any evidence of this yet it is continually asserted as being true. |
+1 for replacing. How about |
While I agree with |
I support changing it. There is no downside to changing it. Mental health is a very real issue for many people and small notions can make a difference. People commenting about "who is getting offended" please ask yourself why you are spending energy arguing in this thread? |
± for replacing. If we do replace, suggested replacement: |
+1 for replacing. Asking for people to step up and say "I am the one getting offended by this," with a tacit, unstated "so we can talk you out of it", is not productive. If it's being broached here the person broaching it probably has a good reason in mind, and it's a sensitive topic so they may not want to share it. If you don't personally have negative connotations with that word — if it's just another verb to you — that's totally fine and OK; but it means a lot to others, and we should be mindful of that. We lose nothing in changing it (a semver major, maybe, which we've long since figured out how to pull off in a repeatable fashion), and make other folks lives slightly easier. Isn't that what OSS is supposed to be all about? |
💯 on the change. i like suggestions that involve including whether it is voluntary or not, as well. understood that it needs to be an alias for now for backwards compatibility, but let's mention in the docs that the terms are also, i'd like to say that the people who have taken this thread as an opportunity to make jokes should take a serious look at their motivations for doing so. does the suggestion that this change be made make you uncomfortable? this is not a joke, and is a worthy issue. i don't believe those comments have a place here. |
+1 for the change, with alias to avoid breaking backwards compat. |
I like Being welcoming (and understandable) in the words our code uses can only do good in growing the node community. We can keep aliases when necessary, though our release process should better enable the deprecation of older APIs over time. |
+1 from me to change it. There are far more important things to be doing instead of bikeshedding words. If a term makes someone uncomfortable and can be easily aliased I don't see the issue with doing so to make the codebase more accessible. Nobody is losing anything here. |
Let's keep things calm on all sides of the discussion. The majority of folks who have weighed in appear to be in favor of making the change and deprecated the previous term so that's likely what should happen. For the folks who feel that the change shouldn't be made, please just keep in mind that it doesn't hurt any to be sensitive and existing code should not break with appropriate aliasing/deprecation. |
👍 for |
At this point I think we have a very wide variety of opinions and a PR #3743 is already in. I'd like to suggest locking the thread |
+1 to locking, @thealphanerd |
+1 to locking as well @thealphanerd |
I think it is never a bad idea to remove offensive words from the API. Ideally it would be great if we could catch such naming mistakes earlier, before they will go into release. Is there anyone who could volunteer for this? Maybe we should have a WG for this? |
Oh, @isaacs, you locked it just when I posted a question. |
@indutny perhaps we should start a thread about this in @nodejs/diversity? |
@thealphanerd makes sense! |
@indutny I doubt that this verb would have made it past the review process we have in place already. This API was added when things were very different and I don't think we're at risk of adding new APIs that lack this sensitivity. |
@indutny @thealphanerd nodejs/inclusivity#9 @mikeal feel free to point to those review processes if you think they're adequate moving forward. |
I'll just say that, as someone who has merged a few PRs to node before, I was not instructed on any sort of terminology review process when invited to be a collaborator. Not sure what the experience was like for later rounds of new collaborators. |
Well, as the person who raised the initial concern (#3720 (comment)) I'm happy to see this being addressed. I don't think we need any kind of formal process around this but as a best practice we should, in general, try to be incrementally better at this kind of stuff. |
@jasnell you wrote the dev policy and the contributing docs, is there an obvious place to note something like this in the contribution guidelines? |
It's a little better now, but not that specific. See: https://github.com/nodejs/node/pull/3726/files#diff-c00e7ffdc40896f8ff6567c07f9eb43cR15 (And other spots), but it could be better and clearer still. Keep in mind this is only a rough draft me and @chrisdickinson have been working off of. We need a place for high-level project values, including this one. |
Ah, cool. That looks like a big improvement from where I came in. 😄 I definitely would like to see a |
@mikeal ... I can take a look. One thing to note, however, is that while we have documented practices for contributing we don't actually have documented practices for reviewing those contributions. What are the things to look out for? What are the best practices for mentoring new collaborators? @Fishrock123 recently just started working on onboarding docs (#3726), perhaps that would be the best place to cover this? |
@jasnell I think that the process for reviewing is essentially making sure the contribution passes our contributing guidelines. TBH, these documents are so large it's not reasonable to expect every contributor to understand every inch of them, that's why we have a review culture that brings PRs inline with the contribution policy and through the review process is how most people learn the guidelines. |
@mikeal ... yep, we should work on simplifying them. However, much of this can be helped by setting clear expectations during the on-boarding process and by encouraging the existing base of collaborators to lead by example. |
I should say, however, that the process for reviewing contributions does go beyond just making sure the contribution guidelines are followed. There's an art to it. If I see a PR that includes a change that I disagree with, I can choose to respond in a number of ways: (a) I could choose what I believe should come to be known as The Torvalds Method, (b) I could use sarcasm to ridicule the basis for the change, (c) or I can take the time to present a logical argument against the change without resorting to either of the previous two options. The choice of response has a definite impact. Further, for any proposed change that I may disagree with, I have to ask myself if there's really any harm in making the change -- even if I think the change is pointless or just "churn". How you review a PR is just as important as ensuring that what is being reviewed passes muster. |
@jasnell can we move that to the onboarding PR? :) |
There's also the case where a reviewer finds the contribution should "obviously" not make it in and uses that as the basis for their review, which is almost never true. Maybe something like "the intention of every review is to educate the contributor through the review process" |
Also just noting here that my local goverment had GitHub banned over IP at ISPs level for several days for the file Things like that could be overdone. To anyone sure that we need a deprecation/removal and one more potential ecosystem breakage over that — please, keep that in mind. Even soft deprecation means imposing some amount of work over the ecosystem. Is a non-technical reason a good enough excuse for that? Edit: to anyone who read the first part incorrectly or did not understand why I mentioned it — that was an example of an unreasonable reaction to solve a minor issue ( Also, I'm not calling the «suicide» issue negligible, but I hope that it does not worth an immediate ecosystem breakage. |
@isaacs please be consistent with your judgments. #1854 (comment) I'm not trying to upset anyone, but a lack of strict policy on deprecating things, varying procedure of doing so, and the potential ecosystem breakage bothers me. |
Folks, var cluster = require('cluster');
if (cluster.isMaster) {
cluster.fork()
.on('exit', function() {
// this.suicide is false here!
});
} else {
process.exit(0);
} The above code is an example of what most humans would regard as a voluntary exit. However, in it the I'll kick off this off again with the suggestion of |
@sam-github Could you also mention that in #3743? That's where the current discussion is located. |
Closed via 4f619bd Thanks |
As discussed with @mikeal and @jasnell in #3720
What word should we use instead?
Content warning: some discussions of suicide in the comments below. --@isaacs
The text was updated successfully, but these errors were encountered: