GitHub has a feature for this: https://docs.github.com/en/github/collaborating-with-issues-...

The implementation is, if you enable this option when making a pull request, people with write access to the target project also get write access to your branch, so they can grab it, make some fixes, git commit (perhaps with --amend), git push -f to your fork, and then merge it from your pull request, and you keep authorship and the pull request gets resolved like normal.

For what it's worth, the Linux kernel community has a process for this too - a subsystem maintainer can absolutely grab someone's patch and git commit --amend. Usually it's considered courteous to add a "[[email protected]: fixed style]" line at the bottom of the commit message. I'm a little surprised the maintainer didn't do that in this case but I bet life got in their way too :)

Ahh... that's enlightening and helpful. Reading up now. Thanks for sharing.

When I first started contributing to open source projects on sourceforge using cvs or svn, it was normal to send patches to the mailing list and for the maintainer to say something like "thanks, I've applied it with a few small changes". I feel that the workflow that GitHub pull requests encourages is that a maintainer will often make detailed comments and it's up to the contributor to fix every last detail, which can often be difficult if they're a new contributor.

In some of my projects, when a new contributor submits a first patch, I've started to do something similar to what people did for me in the past. I will work with them to make major improvements if needed, but if there are a few small things (fix some styling, improve a test, etc), I will just make those changes myself in order to get the PR merged. I understand that this isn't always possible on all projects, and depending on people's spare time, but I think that it's a nice way of showing people that their contributions are welcome without getting bogged down in rules about whitespace or naming.

Is there some kind of cultural reason in the process of submitting patches to linux that someone else couldn't come along and, while giving due credit, do the style fixups on one or the other of the patches themselves and submit that as a v3/v2?

Like, why should every attempt start from scratch as people lose interest?

That's exactly what I was mulling over in my head today (I'm the author of this blog post). If there's some way to simply provide a v3 of this patch while leaving the credit with the original author, I'd love to do it. I just didn't want to step on anybody's toes, and I don't know the etiquette. I think this kind of thing happens more often than we realize. I've seen similar situations before on other drivers.

Download the raw patch from lore.kernel.org, apply it with "git am", fix up the commit message with "git commit --amend", add your "Signed-off-by" below the existing one, submit with "git-send-email" or "git format-patch" + "msmtp".

That way the commit author remains the same because "git format-patch" includes a "From:" line in the message body which "git am" will interpret as the commit author when the maintainer applies the patch.

Your Signed-off-by is necessary to keep the DCO chain intact: https://www.kernel.org/doc/html/latest/process/submitting-pa...

However, that is now done: https://lore.kernel.org/netdev/086b426f44bc24360cc89476fe18d...

Thank you for the report.

Thank you! That is very useful to know for the future.

Honestly, fuck the ettiquite. Reubsmit the patch with fixedup styling and attribution to the original author. If it ruffles some feathers ? Who cares. Hopefully it shakes things up.

Yes, that's roughly the jist of my comment. There are often people with the skills to fix stuff that want to contribute back. But, there's typically a line for them. They fixed it for their own purposes, but are only willing to invest so much time in learning and aligning to project wishes and practices.

I get there are opposite examples of contributors just being contrary and rude, but some sort of workflow to quickly make good, but standards-flawed fixes compliant has merit.

Your idea of a simple way to let someone else take over a pull request seems good.

In general, a lot of contribution workflows are fairly daunting to newcomers–when I tried to submit a fairly small patch to the Linux kernel it took me a while before I figured out what to do, and even then I messed it up and it didn't end up going in. (Full disclaimer: I commented about it here and someone was extremely kind in sending me resources on how to actually do this. I haven't yet followed that advice, sorry!) But even with this, it's still really complicated to figure out how each project does things. I understand many don't really care about one-line patches, but it would be nice if this kind of thing (which I personally consider "outreach") was better supported.

Bravo. Sometimes those one-line patches are gold. I still use a one-line patch for a popular Perl serial/rs-232 module that some kind soul tried to contribute, but failed to get accepted. It's been that way for 10 years or so.

I have heard the other side, which is that many one-line patches require significant time from maintainers because it's often "hand-holding" to get them to where they need to be and often they are not really correct or have some other issues. But even with that I think the case of "maintainer abandoned this patch" or "maintainer is actively looking for new contributors but does not make it easy to get your foot in the door" is the more common one.

When submitting a pull request upstream on GitHub there’s the option (I believe enabled by default) to allow members of the upstream repository to push to your branch, presumably for just this reason of it needing a few tweaks.

In cases like this where a new contributor has a patch with a minor style issue, the code reviewer should probably just accept the patch and repeat it themselves. Or have a group of intermediate contributors who can clean up or shepherd patches across the finish line.

That feels like a pretty easy "shephard" feature that GitHub and/or GitLab could implement.

I don't think there's generally a cultural reason. It just doesn't happen all that often because the "someone else" coming along probably isn't familiar with the project workflow either so they don't know the right way to do it.

What does happen more often I think is that one of the maintainers or regular devs will make minor fixups as part of accepting the patch. (I do this for the project I work on for new contributions at least some of the time.) But that does take time, and usually the people working regularly on the project have a full todo list of stuff they care about or are paid to care about already. So if the patch is for an obscure and unloved area of the codebase (like, say, support for a networking protocol used only by ancient Macs) it's more likely to fall through the cracks simply because nobody working regularly on the project cares about that area. Niche use-cases which have users but no developers are fundamentally in trouble long-term, I think.

This is a case study in why people get discouraged from contributing to open source. When I maintained a linux driver, I absolutely dreaded dealing with the netdev mailing list. I used to delegate that to linux fanatics in the company when I could.

> Though I still occasionally get "thank you" messages from people that accidentally find and use it.

Why not ask one of them to make a pull request using the proper formatting?

Edit: clarification

Honestly? Apathy and Laziness.

Github actually has a "Allow maintainers to modify this branch" option.

If you set this, you could just ask the maintainers to push their changes to your PR and be done with it