[elderlydoofus]

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

[not2b]

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.

[Arnavion]

Yes, I do this for my own OSS projects. The standard approach of giving feedback and waiting for the user to fix something is fine, but for a small change it's easier to just expedite the process and do it myself.

But if my version of the code has substantial changes (ie changes beyond just whitespace, small tweaks to the code, changing the commit message), I push it to a branch and ask the PR author to review and approve it first. Only after they approve it do I merge it into master and close the PR.

I also retain the GIT_AUTHOR of the original PR so that they still get credit; my user is only the GIT_COMMITTER. And I add a "Closes #" ref to the GH PR in the commit message so that it can be tracked later. git also has a de-facto standard of having multiple authors for a commit via `Co-authored-by:` lines in the commit message. This is useful for when my contribution is large enough to be equivalent to the PR author's.

Note that this doesn't work for workflows that require signed commits. If you have such a workflow, you have to go back to giving feedback and waiting for the PR author to make changes.

[lmas]

Thank you for all of these tips!

I've lately been feeling bad, and thinking I must look like an ungrateful asshat, about closing lower quality PRs (IMHO) with valid bugfixes but which introduces some new, possibly subtle, bug instead. Or having to close abandoned PRs because the submitter gave up before that last polishing to match the standard of my own repo. :(

Now I feel better knowing that I can do that final polish myself, while keeping the submitters original contrib!

[saurik]

> Note that this doesn't work for workflows that require signed commits. If you have such a workflow, you have to go back to giving feedback and waiting for the PR author to make changes.

While everyone else who uses the project suffers with the bug that was being fixed as they wait for the person who contributed the patch to go through some hazing process involving code formatting that they (hopefully: I realize some people are in it mostly for the GitHub gamification credit of being a "contributor" on their landing page and thereby will do absolutely anything to get exactly and precisely the author credit on the commit) didn't sign up for. No: please for the love of everyone you are responsible for just commit the fix and thank the person later.

[Arnavion]

Well, I wasn't talking about GH OSS repos specifically in that point. In any case, I imagine that any repo that requires signed commits is also corporate-enough that it'll have a CLA requirement, so if the PR author is unresponsive the maintainer could take the code and commit it as themselves anyway.

[scatters]

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]

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]

Yap and that's when you start feeling that OSS burnout creeping up on you.

[elderlydoofus]

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]

GitHub's "support" for this is the difference between a commit credit and an author credit, which is a mechanism in git that has particular meaning with respect to cherry-picks and rebases. It should be considered awkward to attach someone else as "author" on a commit they might only sort of recognize.

Maybe instead of "taking the time to submit a PR" you should first submit an issue and only work on substantial code changes you are going to become emotionally invested in after you've negotiated the correct path forward with the maintainer? Open source used to be about communication and collaboration, not cowboy coding.

[not2b]

The commit log could still credit the bug discoverer even if that person's proposed fix isn't used.

[smcameron]

No, not cool. If you modify a submitted commit, set the Author field to the original author and add a Signed-off-by field with your email. Then you BOTH appear.

[kangalioo]

On GitHub you can push commits to the PR branch. I use that to fix up rough edges myself and then merge the PR.

[lmas]

Oh wow never realised that was possible! Thank you!

That will save so much time and energy having to deal with back-and-forths or abandoned PRs

[lowercased]

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.

[saurik]

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.

[lowercased]

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

Having your name in the credits brings some of your reputation to their project. Having 'name brand' contributors is a benefit all its own for many projects.