Earlier quoted context omitted.
"There's a reason emotions exist and to lobotomise yourself won't make you a better business person." This. If the other party has identified you as a mark for their scheme, non-emotional professional haggling will result in the worst case in profit for the hostile party, and even at best will be a total waste of time for you and exhausting. I.e. it's "Excuse me sir I notice an acidic liquid flowing from your directi…
I find it fairly important to be “human,” in my interactions; professional, or otherwise. That said, I’m also responsible for keeping the tenor of my communication constructive. There will be mistakes (on my part, and on the part of others), as well as miscommunications, but they can be kept to a minimum, and addressed on a case-by-case basis. I’m a big believer in sincere, appropriate, apologies. They have been enor…
I'm sorry
241–250 of 277 posts
Re: I'm sorry
#242"Sorry I opened a PR and merged it without discussion" is not an honest description of what happened ( https://github.com/reactiveui/splat/pull/778 ), and therefore the apology seems very insincere. You can't apologize and at the same time minimize the thing you actually did. It's pretty much like ending your apology with a "but". And this (not really) apology is a big "but". More to the point though, this apology at…
Re: I'm sorry
#243I am not versed in all the details here, but it is clear there is a diverge of expectations between MS and some of the repo owners. This is just part of business. Legal agreements and projects are complicated. Not everything is going to be spelled out. In a good business relationship you acknowledge this and work in good faith to resolve differences when they occur. However, top comments make clear there is a dire ne…
Did you look at the Contribution License Agreement? It appears that the issue at hand was in fact "spelled out". Repo owners aren't unreasonable to interpret this action as bad faith. I would agree that their message would be better communicated with a more amicable tone.
Re: I'm sorry
#244Earlier quoted context omitted.
I think that was a good call. Most mob-comments on these things are not productive. And especially when done on the project's own infrastructure (unlike here on HN) it's like locking your normally-open door to prevent people coming into your house to berate you. Let the people upset write to their local paper, instead. I don't think the thread would be helped by 100 "who's here from HN?", "Congrats, you're on reddit"…
I think you’re right about making that decision, but the sarcastic description of the situation in the article comes across as condescending.
And I mean, it's their repo, if they want to restrict an issue/pr to contributors only and do so with a sarcastic message or some other rhetoric way, it's their full right to do so..
Re: I'm sorry
#245I am not versed in all the details here, but it is clear there is a diverge of expectations between MS and some of the repo owners. This is just part of business. Legal agreements and projects are complicated. Not everything is going to be spelled out. In a good business relationship you acknowledge this and work in good faith to resolve differences when they occur. However, top comments make clear there is a dire ne…
You should probably read the conversation in the PR: https://github.com/reactiveui/splat/pull/778
> there is a dire need for professional communications training among these programmers.
Maybe, but probably not why you think.
Once you've read the PR's conversation you'll see this isn't about someone just merging a PR which wasn't approved. This about someone submitting a PR, a maintainer asking for discussion before merging it, ignoring the maintainer and just merge the PR, the maintainer asking why it wasn't discussed and then making a snide remark to the maintainer.
So I agree that the "Sorry for merging a PR" isn't going to cut it here. The merging of the PR was the least of the problem. It's a hollow corporate-style apology where someone is allowed to be called out for. It's like saying: "Sorry I hurt your toe" after you pushed someone of a cliff.
Re: I'm sorry
#246I don't know anything about the .NET Foundation or much about this particular situation, but I know a little about open source governance. It appears that Novotny believed she was acting in her capacity as a (long-dormant) maintainer of the project when she merged the PR in question. It was clearly wrong to do so without following the process set down by the other maintainers, and she was right to apologise. However,…
Which is why those people in your hypothetical rightfully see CoCs as poison-pills meant to silently transfer ownership from themselves as owners/founders/copyright holders to corporate "contributors."
To which the obvious response is "if you want to own my assets, buy them, stop tip-toeing around contracts and trying to get them on the cheap."
Re: I'm sorry
#247Earlier quoted context omitted.
I don't see anything wrong with that quote. Can it be expressed more "softly"? Sure. But that person is expressing his opinion and I don't see any problem with that. You could also argue it lays the foundation for further escalation but that's on whoever chooses to engage in it IMO. There seems to be a more general trend going on, some think themselves or others must be protected from "harshness" (even though I consi…
> his arguments are typically sound Telling someone to kill themselves is not a sound argument under any circumstances.
Re: I'm sorry
#248Earlier quoted context omitted.
> his arguments are typically sound Telling someone to kill themselves is not a sound argument under any circumstances.
What if that person is Hitler? What if you work at Dignitas? What if you're Linus Torvalds, working at Dignitas, and the person is Hitler, and Hitler wants to merge a particularly bad pull request to add an NPM leftpad dependency to page_alloc?
But yes I think it's literally absolutely always wrong to tell anyone to kill themselves, no matter how evil they are. Personal abuse is always wrong.
Re: I'm sorry
#249A lot of people have ulterior motives and 99% of the "toxicity" I have observed to date comes from either trying to hide those motives or pretending like others couldn't possibly possess them.
Re: I'm sorry
#250Earlier quoted context omitted.
So, first of all I disagree. Just because something is not prevented by technical means doesn't make it allowed. That goes for all things in life, outside of a supermax prison. And after being asked twice by another maintainer (one of the two current maintainers (none of which are her), as I read it) to please follow the procedures, she tells him to fuck off and overrides him. And after all that she does actually wri…
Isn't this situation a counterexample though? Nontechnical ways to prevent behaviour were attempted, and failed. For distributed software development processes, the only thing that works are hard boundaries. No hard boundary -> implicitly tolerated. For instance, "the vast majority of behaviour" includes every line of code in a repo. The only viable way of preventing undesirable behaviour of a software system is to e…
Not really. Just like shoplifting isn't a motivator for putting everything behind the counter in a store. The cure could be worse than the disease.
> For distributed software development processes, the only thing that works are hard boundaries.
Definitely not true. Opensource has existed for a really long time without a two-key system. Many projects (besides this one) still have big sets of people with commit bits. I'd go so far as to say that almost all projects with a core team size greater than one has some amount of this, with very very few exceptions.
Not everyone needs protections as if they are covered by Sarbanes-Oxley (SOX).
And these projects work just fine.
In fact, it's not even desirable in most cases. You have to take development velocity into account, too. "It must never be possible to unilaterally commit to the main repo" is not the value the project brings to the world. It's a means to deliver the actual value. And it's not the only one. So there are always tradeoffs.
Having worked under mandated requirements (legal and contractual) such as this, I can tell you that it's not without big costs, costs that opensource projects would rather spend on other things. Especially since it's detectable. Preventable is usually not worth the extra costs.
> No hard boundary -> implicitly tolerated.
Of course that's not true. Not in any context. You don't go to someone's house and flip their furniture, and say that not only was the furniture not nailed down, it wasn't even part of the ToS for entering your house, and in any case the door was unlocked.
A project without a CoC is obviously not implying that you can be a nazi or sexually harass.
"What is not prevented is permitted" has never been true in the whole history of humanity, and there have always been repercussions for what you did.
I've been a sysadmin with root access. That doesn't in any way make it implicitly tolerated that I read people's emails and home directories.
> Merging changes without review shouldn't be possible.
Ideally yes. But it's more convenience than security. E.g. your example about having pre-merge testing decreases the toil of maintainers having to deal with test-breaking code being merged. I.e. having to roll it back, and deal with any merge conflicts during rollbacks.
But by your logic of "no hard boundary -> implicitly tolerated" this means I could change the code to detect if it's running in a test, and do something else. There's no hard boundary, but will obviously not be tolerated.