Live data from Hacker News

I'm sorry

github.com

241–250 of 277 posts

Re: I'm sorry

#241
post #193

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 agree the part about the low expectations of the foundation isn't constructive, but I feel like some open display of emotion is necessary after a person openly refuses to have an honest discussion. In the PR she repeatedly ignores the maintainer to push her changes. Then in the 'apology' she doesn't really apologize and isn't really straightforward about what really happened. In the PR the maintainers were pretty reasonable in their communication and it didn't really change the directors approach. I feel like when communicating with someone who repeatedly works in bad faith at some point all you can do is walk away. This emotional poster is doing that but before doing so making sure it is clear to others that this is not okay. I think that's better than saying "I repectfully disagree" because that makes it seem like it's just a slight misunderstanding rather than someone working in bad faith.

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…

In one sentence: "Justification admits guilt."

Re: I'm sorry

#243

I 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.

I don't see why you think people should respond in an amicable tone to an employee of a corporation blatantly attempting to seize ownership of assets which currently do not belong to them.

Re: I'm sorry

#244

Earlier 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.

What you do not see is any deleted messages that already happened before that comment, it can well be that a bunch of twitter/reddit/hn/... users already thought it'd be helpful to invade and post some probably not so well-thought-out nor useful stuff.

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

#245

I 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…

> I am not versed in all the details here

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

#246
post #168

I 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,…

> For example, I saw one where a maintainer politely declined to give the Foundation access privileges required to enforce the Code of Conduct, instead saying that the maintainers would enforce it themselves. Sorry, but I don't think any foundation could accept that. One of many reasons for joining a foundation is that it gives contributors confidence that there is a CoC backed up by an independent organisation, and that can be enforced even (especially) against powerful members of the community such as project maintainers - potentially even all of a project's maintainers. This is one of many ways that Foundations help build contributor confidence, which is one of the major benefits for a project of joining a foundation, and all of them rest on the credibility of the foundation to act as a circuit breaker and assert some kind of control should dire circumstances crop up.

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

#247

Earlier 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.

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?

Re: I'm sorry

#248
post #247

Earlier 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?

These aren't sensible suggestions worth debating.

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

#249
Total waste of everyone's time. I suspect if the word "Microsoft" were not in this equation, this HN thread would not exist and no one would give a shit.

A 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

#250
post #236

Earlier 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…

> Isn't this situation a counterexample though? Nontechnical ways to prevent behaviour were attempted, and failed.

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.

Post reply on HN