4 ms·

"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 https://githu

"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 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 attempt made it worse. It starts off with a dishonest apology, and then goes into a big policy and contract debate. Why would you conflate the two? Whatever point you're then trying to make about policy and ownership is tainted by both the personal misstep (I call it that unsarcastically) and by the insincere apology. It's needlessly ineffective. 1. It makes your apology sound like "I'm sorry, but I'm the dictator here" 2. It starts you off from a position of "I was wrong, admit I was wrong, but here's how actually I'm right" It's going to be hard convincing anyone if you start from a position of being wrong. And not just wrong but also really rude. It seems to me that it would be much more effective to just apologize for the obvious process mis-step and arrogant rudeness (it happens to the best of us), and let that sink in. And then start a new conversation about policy. Whoever raises "yeah, well weren't you the one who went around PR policies?" in that thread will be the unproductive one, and it won't go anywhere. As-is the policy points can't be taken at face value.

xwdv 5y ago
If this is not desired behavior it should be enforced by requiring a reviewer to sign off on the changes before merging. By not requiring this it means it is okay for pull requests to be merged without discussion, even if it is a rare occurrence. This is one of those occurrences.
- knorker 5y ago
  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 write something intended to look like an apology. So what does that mean? Either she disagrees with you, and indeed she should have followed procedures, or all she's apologizing for is "sorry you got so upset", which more of a taunt than an apology. No, actually. Contrary to what cryptocurrency people would have you believe, there are other and more effective ways to prevent undesirable behaviour than technical means, for the vast majority of behaviour.
  - jimnotgym 5y ago
    ..and further it is not possible to discern properly the relationship between a project and a contributor just because there is a time gap. If I wrote a project completely myself up to version 1.1 and then allowed other maintainers on to it who had taken it to version 1.2 I might feel I can merge whatever I like even after a gap. Not saying that is what happened here, just saying that it is impossible to discern from that discussion
  - pnut 5y ago
    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 enforce passing tests before merging. A mandatory technological safety net baked into the developer's workflow. All of these boundaries are to prevent human error propagating to production. Merging changes without review shouldn't be possible.
    - knorker 5y ago
      > 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.
- arusahni 5y ago
  > If this is not desired behavior it should be enforced by requiring a reviewer to sign off on the changes before merging. From what I've read about this specific incident, it seems this was enabled by the fact that this project had been moved to GitHub Enterprise without the maintainers' knowledge. One of the features of GitHub Enterprise is that some privileged users in the organization can bypass such restrictions. That may be what happened here.
sillysaurusx 5y ago
The ending of that was so unexpected: > Wow great conversation! Let's lock it to contributors just for a laugh and not because someone on Twitter just unhelpfully sent 27.3k Looky-Loos over to drop their $0.02 on my repo > @reactiveui reactiveui locked as resolved and limited conversation to collaborators 6 days ago Either I'm out of touch (quite probable) or sarcasm doesn't translate too well, since... I think they're unhappy with someone tweeting a link to this PR, but it also seems unclear why discussion was shut down.
- knorker 5y ago
  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", and such.
  - sillysaurusx 5y ago
    On reflection, you're right. I also realized that they probably had to delete a bunch of pile-on comments, which would've been annoying too.
  - ashtonkem 5y ago
    I think you’re right about making that decision, but the sarcastic description of the situation in the article comes across as condescending.
    - tlamponi 5y ago
      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..
MrBuddyCasino 5y ago
„Apologizing when you are caught to is never an apology, but an indication of submission.“ NNT - https://twitter.com/nntaleb/status/1427341684447264772 https://twitter.com/nntaleb/status/1427341684447264772
scns 5y ago
In one sentence: "Justification admits guilt."
jrochkind1 5y ago
Coming into this as an outside observer, I don't really understand the original infraction and can't judge it's severity. But reading the apology, I still had the reaction: Wow, they really don't understand community management if they think this is going to work for anyone, which they seem to be telling us is in fact their whole job?

xwdv 5y ago

If this is not desired behavior it should be enforced by requiring a reviewer to sign off on the changes before merging. By not requiring this it means it is okay for pull requests to be merged without discussion, even if it is a rare occurrence. This is one of those occurrences.

knorker 5y ago
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 write something intended to look like an apology. So what does that mean? Either she disagrees with you, and indeed she should have followed procedures, or all she's apologizing for is "sorry you got so upset", which more of a taunt than an apology. No, actually. Contrary to what cryptocurrency people would have you believe, there are other and more effective ways to prevent undesirable behaviour than technical means, for the vast majority of behaviour.
- jimnotgym 5y ago
  ..and further it is not possible to discern properly the relationship between a project and a contributor just because there is a time gap. If I wrote a project completely myself up to version 1.1 and then allowed other maintainers on to it who had taken it to version 1.2 I might feel I can merge whatever I like even after a gap. Not saying that is what happened here, just saying that it is impossible to discern from that discussion
- pnut 5y ago
  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 enforce passing tests before merging. A mandatory technological safety net baked into the developer's workflow. All of these boundaries are to prevent human error propagating to production. Merging changes without review shouldn't be possible.
  - knorker 5y ago
    > 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.
arusahni 5y ago
> If this is not desired behavior it should be enforced by requiring a reviewer to sign off on the changes before merging. From what I've read about this specific incident, it seems this was enabled by the fact that this project had been moved to GitHub Enterprise without the maintainers' knowledge. One of the features of GitHub Enterprise is that some privileged users in the organization can bypass such restrictions. That may be what happened here.

sillysaurusx 5y ago

The ending of that was so unexpected: > Wow great conversation! Let's lock it to contributors just for a laugh and not because someone on Twitter just unhelpfully sent 27.3k Looky-Loos over to drop their $0.02 on my repo > @reactiveui reactiveui locked as resolved and limited conversation to collaborators 6 days ago Either I'm out of touch (quite probable) or sarcasm doesn't translate too well, since... I think they're unhappy with someone tweeting a link to this PR, but it also seems unclear why discussion was shut down.

knorker 5y ago
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", and such.
- sillysaurusx 5y ago
  On reflection, you're right. I also realized that they probably had to delete a bunch of pile-on comments, which would've been annoying too.
- ashtonkem 5y ago
  I think you’re right about making that decision, but the sarcastic description of the situation in the article comes across as condescending.
  - tlamponi 5y ago
    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..

MrBuddyCasino 5y ago

„Apologizing when you are caught to is never an apology, but an indication of submission.“ NNT - https://twitter.com/nntaleb/status/1427341684447264772 https://twitter.com/nntaleb/status/1427341684447264772

scns 5y ago

In one sentence: "Justification admits guilt."

jrochkind1 5y ago

Coming into this as an outside observer, I don't really understand the original infraction and can't judge it's severity. But reading the apology, I still had the reaction: Wow, they really don't understand community management if they think this is going to work for anyone, which they seem to be telling us is in fact their whole job?