6 ms·

I thought this might be something different. Have seen this happen multiple times over the years - even once just last week. Colleague files an issue with a P

I thought this might be something different. Have seen this happen multiple times over the years - even once just last week. Colleague files an issue with a PR. Project owners close it, say 'no, not a bug', then... commits the same thing themselves as "fixed!". Saw this years before in cvs/svn, and... at least in the GH world there's some evidence of the original PR author having done the work in the first place (vs being invisibly cut out).

jamjamjamjamjam 5y ago
The owner of huey does this. He closes PRs and submits the code himself
- elderlydoofus 5y ago
  I had this happen on a small PR I submitted within the past year. I didn’t think anything of it at the time, but your comment led me to glancing through the past PRs and it’s comical how many are closed with a “thanks, I’ve committed an equivalent patch” comment. One the one hand, it’s his repo and he’s free to do whatever he wants. I actually admire how ruthless the maintainer is on closing issues, must be great for staving off OSS burnout. On the other hand, I don’t love how antagonistic it is to outside contributors. Litestream[0] is an example of open source-closed contributions, but at least it’s upfront about that in the README. (And the policy has actually changed to open for bug fixes.) I would open an issue/PR on Huey suggesting adding a similar disclaimer, but it’d probably be closed, ha. [0] https://github.com/benbjohnson/litestream#contribution-policy https://github.com/benbjohnson/litestream#contribution-polic...
  - not2b 5y ago
    In many cases this is the right thing for a maintainer to do: a contributor produces a PR and a proposed patch, but often that patch doesn't solve the whole problem, or clashes with the coding style, or isn't very efficient, so the maintainer does their own fix, because that is faster than getting the contributor to produce a modified version.
    - lowercased 5y ago
      it can be, yes. there's chicken and egg issue of trying to help other people be more proficient in making those mods, learning about larger parts of the system, etc. there's also the issue of being told "no, that's not a bug" or "no, WONTFIX", then... hours or days later... producing the same code patch as your own. Definitely a jerk move.
    - scatters 5y ago
      The polite thing is to fork the contributor's PR branch back into the project repo, make changes preserving history, and then merge or squash merge the result.
      - hombre_fatal 5y ago
        It is a bit awkward though. Some projects by nature attract high quality PRs. Others, like a game I built, have the unfortunate curse of attracting PRs with such low quality that it's kinda heart-breaking to shut them down. It's one thing to read a good feature request in a Github issue and build it yourself. It's a whole other thing to modify a low quality PR in a polite way, see what they were trying to do, clean it up, refactor it. It can easily be 5x the work of just doing it from scratch as the project maintainer. This experience, especially after your hundredth time, can jade you in a way and make you seem rude when you decide it's not worth the courtesy nor charity.
        lmas 5y ago
        Yap and that's when you start feeling that OSS burnout creeping up on you.
    - elderlydoofus 5y ago
      Yeah, I get why this happens. And to be clear, I didn't dig in to the all the PRs and compare them vs the maintainer's commits, so I have no idea of the difference in code quality between the two. I'm sure it's frustrating when maintaining a fairly popular OSS tool to receive a PR that's 95% of the way there. Having to go back and forth to coach someone on getting that last 5% (or the contributor just dropping the PR then ghosting) vs just doing it yourself, I totally get it. However from the contributor's point of view, when GH has support for co-authored commits, it comes of as a bit of jerky move when you take the time to submit a PR to not at least get credit via a co-author commit message.
  - saurik 5y ago
    The alternative is way worse: it turns into this culture of forcing people who just tried to help with something minor to suddenly be bullied asking for updates to code they were done with. I gave you a fix. It was a potential fix. It was one of many possible fixes. It is your project, and you should figure out what you actually want to commit. And yet way too often the maintainer spends more time trying to explain to me what they don't like about my patch or what other relevant work needs to be done in order to commit the patch than it would take for them to just do it themselves now that I showed them what to do. I am following a ton of issues on projects like Flutter and Cargo that are somehow steeped in this culture and it frankly just seems like nothing ever gets fixed. In some cases pull requests are open for years as people bike shed back and forth arguing over some extremely minor point in a patch, letting thousands of other developers suffer waiting for a patch that to them would work exactly the same either way, because of some weird culture that has been built up surrounding "maintainers may only click commit or leave comments while contributors type all of the code", and if the person who made the patch doesn't want to--or simply can't as they grok the requirement--satisfy some procedural process the world now has to wait for someone else to step up and submit themselves to this process with a new pull request, despite the maintainers having clearly all spent hours typing comments nitpicking on what at the end of the day is often literally a 30 line patch they apparently refuse to just re-type themselves. In some sense I frankly think this is an entitlement issue on both sides: the maintainer isn't entitled to the continued time and effort of the person who submitted the patch--and certainly isn't committed to them doing exactly what the maintainer wants--and nor is the submitter entitled to some weird GitHub-specific contributor "credit" on the maintainer's project and the requisite control over the patch and how it gets applied that getting that would have to imply. Should the patch submitter get some love? Yes! Is the bug tracker sufficient? Maybe! (I will say for myself this is absolutely sufficient: unless I am fixing some world-shaking bug--which does happen given what J do--the most important thing to me is going to be getting the feature or fix I wanted landed with minimal delay and preferably the least effort from me, not a very specific form of control over a commit.) If not, is having a file somewhere of "helpful people" enough? I want to say "yes", and I'll up it to "certainly" if it includes a mention of why. But like, I really do think there is something super core going wrong with the open source world here, and this "pull request" model from GitHub with "contributor" status is to blame :/. In addition to the obviously-evil gamification of the codebase (from the badges) I think one reason people get this feeling of entitlement over their patch is that they put way too much work into it before it even gets presented as they go for this completed pull request model. 99.99% of the time what I want as a maintainer isn't someone who spent a month working on a patch that they are now going to argue with me about: I want a single paragraph a month earlier with an explanation of what is needed and maybe I could have solved it in a few hours or explained why the concept won't work or would conflict with planned effort. On the other side, I then think the UI--combined with this inferred expectation from the patcher--forms that brutal entitlement from many maintainers that they maybe never have to touch code again and can just armchair quarterback / long-range pair program other people into getting some exact result. This is what chases away the quality contributors, as the quality contributors know that reformatting code is easy but predicting how someone else wants code to be formatted is nigh-unto impossible, and they also appreciate that the hardest part of a patch is knowing what worked or didn't work to fix the problem, not typing the code. Meanwhile, the people who matter to your project want what's best for the project, not what's best for their GitHub contribution scores, and I dare say that if the maintainer is in a good position to be man-handling all the code that's the right way to go about the problem. So like, concrete example: am I proud to be listed in the AUTHORS file of v8? Sure! But do I care whether whatever patch I had provided actually has my Author: on it? So much not to the point where I can't remember if it happened or not. Would I still be proud of my marginal work on v8 even if I weren't in the AUTHORS file? Yes! And would I have minded if they didn't put me there? No, and honestly I almost find it weird sometimes that they did... I certainly didn't ask.

jamjamjamjamjam 5y ago

The owner of huey does this. He closes PRs and submits the code himself

elderlydoofus 5y ago
I had this happen on a small PR I submitted within the past year. I didn’t think anything of it at the time, but your comment led me to glancing through the past PRs and it’s comical how many are closed with a “thanks, I’ve committed an equivalent patch” comment. One the one hand, it’s his repo and he’s free to do whatever he wants. I actually admire how ruthless the maintainer is on closing issues, must be great for staving off OSS burnout. On the other hand, I don’t love how antagonistic it is to outside contributors. Litestream[0] is an example of open source-closed contributions, but at least it’s upfront about that in the README. (And the policy has actually changed to open for bug fixes.) I would open an issue/PR on Huey suggesting adding a similar disclaimer, but it’d probably be closed, ha. [0] https://github.com/benbjohnson/litestream#contribution-policy https://github.com/benbjohnson/litestream#contribution-polic...
- not2b 5y ago
  In many cases this is the right thing for a maintainer to do: a contributor produces a PR and a proposed patch, but often that patch doesn't solve the whole problem, or clashes with the coding style, or isn't very efficient, so the maintainer does their own fix, because that is faster than getting the contributor to produce a modified version.
  - lowercased 5y ago
    it can be, yes. there's chicken and egg issue of trying to help other people be more proficient in making those mods, learning about larger parts of the system, etc. there's also the issue of being told "no, that's not a bug" or "no, WONTFIX", then... hours or days later... producing the same code patch as your own. Definitely a jerk move.
  - scatters 5y ago
    The polite thing is to fork the contributor's PR branch back into the project repo, make changes preserving history, and then merge or squash merge the result.
    - hombre_fatal 5y ago
      It is a bit awkward though. Some projects by nature attract high quality PRs. Others, like a game I built, have the unfortunate curse of attracting PRs with such low quality that it's kinda heart-breaking to shut them down. It's one thing to read a good feature request in a Github issue and build it yourself. It's a whole other thing to modify a low quality PR in a polite way, see what they were trying to do, clean it up, refactor it. It can easily be 5x the work of just doing it from scratch as the project maintainer. This experience, especially after your hundredth time, can jade you in a way and make you seem rude when you decide it's not worth the courtesy nor charity.
      - lmas 5y ago
        Yap and that's when you start feeling that OSS burnout creeping up on you.
  - elderlydoofus 5y ago
    Yeah, I get why this happens. And to be clear, I didn't dig in to the all the PRs and compare them vs the maintainer's commits, so I have no idea of the difference in code quality between the two. I'm sure it's frustrating when maintaining a fairly popular OSS tool to receive a PR that's 95% of the way there. Having to go back and forth to coach someone on getting that last 5% (or the contributor just dropping the PR then ghosting) vs just doing it yourself, I totally get it. However from the contributor's point of view, when GH has support for co-authored commits, it comes of as a bit of jerky move when you take the time to submit a PR to not at least get credit via a co-author commit message.
- saurik 5y ago
  The alternative is way worse: it turns into this culture of forcing people who just tried to help with something minor to suddenly be bullied asking for updates to code they were done with. I gave you a fix. It was a potential fix. It was one of many possible fixes. It is your project, and you should figure out what you actually want to commit. And yet way too often the maintainer spends more time trying to explain to me what they don't like about my patch or what other relevant work needs to be done in order to commit the patch than it would take for them to just do it themselves now that I showed them what to do. I am following a ton of issues on projects like Flutter and Cargo that are somehow steeped in this culture and it frankly just seems like nothing ever gets fixed. In some cases pull requests are open for years as people bike shed back and forth arguing over some extremely minor point in a patch, letting thousands of other developers suffer waiting for a patch that to them would work exactly the same either way, because of some weird culture that has been built up surrounding "maintainers may only click commit or leave comments while contributors type all of the code", and if the person who made the patch doesn't want to--or simply can't as they grok the requirement--satisfy some procedural process the world now has to wait for someone else to step up and submit themselves to this process with a new pull request, despite the maintainers having clearly all spent hours typing comments nitpicking on what at the end of the day is often literally a 30 line patch they apparently refuse to just re-type themselves. In some sense I frankly think this is an entitlement issue on both sides: the maintainer isn't entitled to the continued time and effort of the person who submitted the patch--and certainly isn't committed to them doing exactly what the maintainer wants--and nor is the submitter entitled to some weird GitHub-specific contributor "credit" on the maintainer's project and the requisite control over the patch and how it gets applied that getting that would have to imply. Should the patch submitter get some love? Yes! Is the bug tracker sufficient? Maybe! (I will say for myself this is absolutely sufficient: unless I am fixing some world-shaking bug--which does happen given what J do--the most important thing to me is going to be getting the feature or fix I wanted landed with minimal delay and preferably the least effort from me, not a very specific form of control over a commit.) If not, is having a file somewhere of "helpful people" enough? I want to say "yes", and I'll up it to "certainly" if it includes a mention of why. But like, I really do think there is something super core going wrong with the open source world here, and this "pull request" model from GitHub with "contributor" status is to blame :/. In addition to the obviously-evil gamification of the codebase (from the badges) I think one reason people get this feeling of entitlement over their patch is that they put way too much work into it before it even gets presented as they go for this completed pull request model. 99.99% of the time what I want as a maintainer isn't someone who spent a month working on a patch that they are now going to argue with me about: I want a single paragraph a month earlier with an explanation of what is needed and maybe I could have solved it in a few hours or explained why the concept won't work or would conflict with planned effort. On the other side, I then think the UI--combined with this inferred expectation from the patcher--forms that brutal entitlement from many maintainers that they maybe never have to touch code again and can just armchair quarterback / long-range pair program other people into getting some exact result. This is what chases away the quality contributors, as the quality contributors know that reformatting code is easy but predicting how someone else wants code to be formatted is nigh-unto impossible, and they also appreciate that the hardest part of a patch is knowing what worked or didn't work to fix the problem, not typing the code. Meanwhile, the people who matter to your project want what's best for the project, not what's best for their GitHub contribution scores, and I dare say that if the maintainer is in a good position to be man-handling all the code that's the right way to go about the problem. So like, concrete example: am I proud to be listed in the AUTHORS file of v8? Sure! But do I care whether whatever patch I had provided actually has my Author: on it? So much not to the point where I can't remember if it happened or not. Would I still be proud of my marginal work on v8 even if I weren't in the AUTHORS file? Yes! And would I have minded if they didn't put me there? No, and honestly I almost find it weird sometimes that they did... I certainly didn't ask.