He was also asked to tweak the second patch because of a minor style issue (which I also understand). A third try at submitting the patch hasn’t been attempted as of this writing."
I've been there. I understand both sides, but it's a bit frustrating from the "outside contributor" standpoint sometimes.
For example, I use git quite a lot, but not GitHub. As a result, a pretty simple "couple of lines" fix I tried to contribute remains uncommitted because I wasn't able to format things in a way that made the target project folks happy. The pull request remains sitting there. Though I still occasionally get "thank you" messages from people that accidentally find and use it.
So, some number of folks lose out on a good fix roughly because what would take me several hours, but take someone else a few minutes, just doesn't get done.
Some sort of web based "force this minor tweak for a pull request" feature might have a decent upside.
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@example.com: 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 :)
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.
Like, why should every attempt start from scratch as people lose interest?
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:
However, that is now done:
Thank you for the report.
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.
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.
If you set this, you could just ask the maintainers to push their changes to your PR and be done with it
Why not ask one of them to make a pull request using the proper formatting?
While I don't have a personal use for AppleTalk support, it makes me happy that support for old protocols lives on.
It's easy to bypass, as the article shows, but also sad that this user-hostile practice has spread to Linux. I'd expect this for Windows or Mac, but not Linux.
Do you consider signing keys in apt packages to also be user hostile?
I have a Macbook but smb seems kinda shady there.
Case in point : recently, tested using a Hackintosh and a hand-built high performance NAS (100 TB), 10GigE ethernet.
Running Windows 10 on the Hackintosh, SMB protocol : ~900 MB/s read/write
Running MacOS on the same machine , SMB protocol : ~200 MB/s read/write
Running MacOS, AFP protocol : ~1 GB/s read/write.
The kernel module implements the stuff described in the sections on EtherTalk and AppleTalk phase II on this  wiki page.
When the article mentioned AppleTalk I envisioned a way to get files off of my old SE using something that hooked into the ADB networking ports.
For your SE you could get an ethernet adapter that plugged into the SCSI port or a PDS card to go inside the case.
The blog author might want to look at a recent pkgsrc patch to netatalk 2.2 that makes it work with current CUPS.