replace suicide as a verb
MylesBorins opened this issue · comments
As discussed with @mikeal and @jasnell in #3720
we could alias 'suicide' to another word in the codebase to maintain reverse compatibility while moving to the new word and updating the docs. then it's a feature rather than compat break and stays semver-minor. @mikeal
What word should we use instead?
Content warning: some discussions of suicide in the comments below. --@isaacs
Where does it say we shouldn't use it? In the same vein, one could say kill is bad, which is an universally used term in the Unix world.
I'm 👍 on replacing problematic terminology gradually, with aliases. For the kill and suicide terms, it seems to me like stop and stopped actually makes more sense, especially across language barriers. The master and worker terminology could also be parent and child, which seems a bit friendlier.
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 .suicide property because of backwards compatibility. I'm -1 on aliasing it, that's just more surface area for bugs and confusion.
I'm -1 on kill because it's documented that way in syscalls so this would add a lot of confusion, same for anything else that is documented as such far below the node.js layer. suicide is purely part of our own abstraction and should be changed. This goes back to the Node.js is fun principal: seeing suicide in my code bums me out and is decidedly not fun.
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 kill to stop) is likely to just cause more confusion.
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 suicide there is not directed onto someone, and without that, words are just words. You can see that word in any dictionary, in Wikipedia, in some book, etc. — it doesn't make the dictionary, Wikipedia, or the book bad.
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 semver-major change, I guess. And I doubt that it will go away in the forseeable future.
Yeah IMHO I'm not seeing the benefit of changing the wording here when there would be backwards incompatibility.
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 suicide was already a term in use in the code. I'd rather not add to the problem by introducing new stuff. However, if we we have the opportunity to make improvements as we go, then we should likely do so, but we shouldn't bikeshed on it too much or try to solve everything all at once.
Yeah IMHO I'm not seeing the benefit of changing the wording here when there would be backwards incompatibility.
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.
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.
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 child_process, requiring her to see the word every time she goes to start a subprocess? What about child.kill()? What about process.kill()? The list goes on...
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 kill) and those that we are adopting in APIs that are entirely Node.js. In this case, we actually own this abstraction, we are not perpetuating the use of a common term, in the case of suicide we've actually chosen it for an API. This term isn't even common, I've never seen it anywhere else, a quick google for "suicide API" found no technical pages and a lot of depressing real stories, so I'm not seeing the case for persisting this verb when it's easily in our ability to move past it without negatively impacting users. You're making a good case for several other verbs, just not this one.
At some point it would be removed though
Only if nobody is using it anymore, the cost of keeping the compatibility code there is basically zero.
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 adjourn.
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 voluntary or intentional (as opposed to just a synonym for suicide) to show that the process was intentionally killed.
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?
These unix terms have been around for years and they are fine.
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 voluntaryExit since the docs state that it is set when the worker voluntarily exists
While I agree with kill being a universal unix term, suicide is worthy of a change. I've never seen anything in unix using that term.
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: seppuku
+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 deprecated so there's a projected road-map for eventually eliminating them. (happy to help with this communication/documentation)
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 voluntaryExit. It's more descriptive, and also not callous like the current term is. Terming anything suicide is quite frankly disgusting.
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.
+1 for change but backwards compatible friendly. +1 for voluntaryExit .
Scoping: this issue is only about suicide and not about other terms in the node codebase or other open source projects.
Question: What is a suitable replacement word?
Proposal: deprecate suicide and alias with another term, such as terminated
Cost: minimal. it's an internal messaging abstraction in the cluster module
Benefit: promotes an inclusive node community, demonstrates sensitivity, and recognizes that people matter more than code
To my 👀, this is an easy decision
💯 for the change. And as far as people being offended, well put me in that group if you really need to lump someone in. Stuff like this is a constant battle for me and seeing words used in APIs is triggering and makes me reticent to get involved.
"That's how we've always done it." isn't a good argument for not fixing broken language. I like the idea of aliasing in node the kill, master, worker, slave terminology until Unix can do it at that level.
+1 for voluntaryExit
really glad to see support pouring in. I'm doing a first pass at this right now with voluntaryExit being used.
+1 for voluntaryExit. The term "suicide" doesn't even make that configuration option very clear. This one is much more clear.
<3<3<3 @thealphanerd thanks for kicking this off.
+1 for voluntaryExit or similar. This directly affects me. Saw messages in my mailbox last night about 'suicide' and that was distinctly unpleasant as that is a thing that happens in my community weekly and often requires I drop what I'm doing and help someone out.
Programming node can be really fun for me. As somebody who has attempted suicide, seeing suicide come up in code occasionally takes away that fun and brings back some painful memories. Sometimes such language is unavoidable (like historical) or has changed due to context and can't be avoided. This looks like an abstraction exclusive to node according to @mikeal, so a name change to voluntaryExit with a backwards compatible alias seems great.
Thanks to @thealphanerd for bringing this up.
💯 to making the narrowly scoped change.
It’s never a bad thing to push a change and think to yourself, Now there is at least one person whose life will be a little less painful. Sometimes we do that with a fancy algorithm that speeds a task up, sometimes we do that with a cleaner UI that makes a task a little easier, and this is a place where we can accomplish that honorable goal by changing a single word.
+1 for voluntaryExit.
± for replacing. If we do replace, suggested replacement: seppuku
This is not helpful, @rennat. This is a serious issue that deserves to be treated with thoughtful consideration and respect.
I already made my opinion on this issue known on Twitter, but I'm strongly +1 for making a backwards-compatible change to a less loaded term like voluntaryExit, with a clear deprecation strategy in place, as @ashleygwilliams and @chrisdickinson suggest. There are many members of the Node community who have been directly affected by suicide, which makes the level of callousness displayed at the start of this thread especially disgusting. Big thanks to @thealphanerd for bringing this up.
Furthermore, I'd like to +1 the idea of sanctioning individuals who feel the need to contribute disruptive/harmful comments to this thread.
As someone who's lost many family and friends to suicide, I'll put myself out there as someone who's offended.
I am not against any of the naming changes regarding words like suicide, master and slave. I am just curious as to why these are deemed so important to change. Obviously these terms are like any other subjective to the context in which they are used. I.e. You could say that killing a person is wrong, but how would that apply to killing a process?
+1 for changing the name of this API.
The "suicide" API name is not based on any long-standing Unix-ism. (And yes, I of course know that many of those are rather problematic, but here we are.) In this case, it was a "cute" choice to indicate that the process terminated normally, rather than receiving a fatal signal from the parent. Anyone claiming otherwise, citation needed.
As @bnoordhuis points out, there is a non-zero cost of every line of code. There is also a non-zero cost to using offensive terminology in code. It is clear to me which cost is higher here.
Compatibility layer prevents any backwards-compatibility breakage. This lowers the cost of change even further.
I am the one getting offended by this. See the other comments pop in, I'm not alone. I'm happy to share the details of exactly why this is offensive to me, and I'm sure anyone with an ounce of humanity will see exactly why there is no way that I'll ever not be offended by this, but it's a very tragic and triggering story that does not need to be left here as an emotional land-mine to anyone who might be reading this thread. Ask offline if you care to know.
Thank you, @thealphanerd for bringing this up. I don't understand why this is even controversial.
i think @emilyrose makes a good point here. people need to be held accountable. jokes on this thread certainly violate the nodejs code of conduct AND npm code of conduct (included because it is clearer about enforcement)
+1 to show my support for replacing suicide with voluntaryExit and having a clear deprecation strategy as has already been stated by many.
+1 to support @emilyrose and @ashleygwilliams with the need for the code of conduct to be upheld.
Another +1 to this change.
Like many have said before me: the change is adding an alias, which is backwards compatible. The change has an incredibly small cost, which is easily handled by semver. This is not changing already baked in Unix terminology (which is a totally different conversation) but something specific to node, and it provides an immense benefit in being more inclusive to the community as a whole.
If you are somebody who is not offended (or affected at all) by the current terminology, why would you even care about this, better yet in a way that makes expending your energy here worthwhile?
Thinking about possible new terms but want to clarify. The docs say "The boolean worker.suicide lets you distinguish between voluntary and accidental exit". So are "voluntary exit" and "accidental exit" two different statuses and if so, would naming it voluntaryExit be the right term?
Another (less emotional, purely pedantic) argument in favor of the change: suicide is being used as a boolean state, and in english it's either a noun or a verb, but not an adjective. It's a confusing API at best, and changing it would be an improvement even for those who are not reminded of unsettling tragedies.
It is unfortunate that the verb "to stop" is ambitransitive in English. In Japanese for example, there is the transitive 止める (tomeru, to stop something) and the intransitive 止まる (tomaru, to stop oneself (this is not exactly true, but would fit here I think)). There would be a distinction which would naturally solve this problem.
I'd suggest selfDestruct.
I think voluntaryExit is the right choice since that is what it is supposed to be a boolean for. selfDestruct carries a lot of similar mental health connotations to suicide. Many folks dealing with these issues are often engaging in self destructive or self harm behavior before reaching a point of suicide.
+1 on voluntaryExit
Also, I want to echo what @emilyrose and @ashleygwilliams have said. Some of the conversation in here most certainly does violate the code of conduct, and this is absolutely unacceptable.
We can talk about how effective or not various CoCs are for creating safe, welcoming spaces, but at the end of the day, it doesn't matter how good the CoC is if it's not enforced. An unenforced CoC is worse than no CoC at all.
+1 voluntaryExit
mental health issues shouldn't be taken lightly
+1 voluntaryExit makes sense. It's a property. This is more descriptive than suicide (which is at best strange wording).
Yes github should be a safe space for all those involved. I'm going to change my view to +1. It doesn't hurt anything.
+1 on voluntaryExit, but it still doesn't sound boolean. Perhaps voluntarilyExited if that's important (the original didn't sound boolean either, so it may not be).
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 voluntaryExit. it both removes the emotional impact on those affected by suicide and is more clear and descriptive of what actually happened from a technical standpoint.
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?
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
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 core-values.md or something like that too.
@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? :)
or I can take the time to present a logical argument against the change without resorting to either of the previous two options
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 suicide.txt in some repo (well, actually for it's contents).
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 (suicide.txt file on a GitHub), causing a bigger one (GitHub outage in a country).
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, voluntaryExit is not acceptable as a replacement for suicide:
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 .suicide (edit: aka voluntaryExit) would be false! Ouch.
I'll kick off this off again with the suggestion of expectedExit.
@sam-github Could you also mention that in #3743? That's where the current discussion is located.
Closed via 4f619bd
Thanks