If only these drive-by contributors would be around to maintain the stuff like secretaries that would be a dream. As it is, I think you may have the roles reversed: the maintainers are not there to merge your patch and look after it in perpetuity.
The entire purpose of these responses is to repel the drive-by contributor who invariably generates clerical work for the full-time maintainer. It's just a sad fact about the nature of this work that it's often done by volunteers who are massively overloaded, and "contributions" are often so minuscule or low quality that they are actually just additional time-demands on already-overworked maintainers.
Repelling drive-by contributors usually pertains to people who want to dump massive amounts of feature creep into existing FOSS. There's a legitimate place for not adding Bobs massive feature list all at once because you don't know if Bob will be around after 2 years and you end up cutting most of them because you can't figure them out.
The last place biting drive-by contributors should apply is for bugfixes. Bugfixes are one of the most common ways beginners/newcomers are incentivized to contribute (and keep contributing), especially to FOSS. Even Stallman, who otherwise is someone who I would not consider a good example for any kind of communication, implicitly acknowledges that if you're a maintainer, you should try to work with people submitting patches to get them merged rather than antagonize them because of your possible maintenance burden[0].
[0]: https://stallman.org/stallman-computing.html (see the how to learn to program section, which while largely bad advice on actually learning how to program, does have the nugget that "fixing bugs is a great way to get into FOSS dev" and "most maintainers will be happy to receive your patches and work with you to get them formatted and correct", which is imo implicit advice for maintainers to be kind to new contributors.)
Generally the value that you would bring with your fix is not worth the burden you put on everyone else. There are many hobby projects with a more open attitude specifically for this reason, because they are willing to take this burden for the sake of having people feel good about contributing. Try Serenity for example. Most open source projects obviously will not have such an attitude.
I mean, we're not talking about contributors who implement a whole new feature which you hadn't planned and want you to merge it, we're talking about bug fixes, which are generally short, and their value should be easy to gauge?
Would you simply accept a random persons PR fixing a bug without basically re-doing all the work?
I know I wouldn't.
Even a simple line change (especially in huge projects like the kernel) can have unexpected consequences. Your fix might fix the bug in question but cause others down the line. It can make the code harder to maintain, not fit style guides, etc. There are numerous issues caused by these "drive by patches".
Unless you actually maintain a project or is heavily involved, it's easy to miss the forest from the trees.
Ironically, the person sending the patch is most times being paid by a company to do so (since they are fixing an issue they found) while the maintainer is most likely unpaid/underpaid.
I've had a very small experience maintaining a library and already had to deal with "bug fixes" that take huge swaths of your time and simply cannot be merged. So I empathize with the maintainer here much more than the Cisco employee that was allowed days of paid work to poke around the issue and tried to fix it. The maintainer very likely had to reproduce the bug and consider any implications of the fix beyond what the author would have by the simple fact he actually maintains that project.
Personally I think a co-authored tag wouldn't hurt, but I cannot blame the maintainer for not having that in his mind when he's focused in doing his job (which is, again, most likely unpaid/underpaid).
But I can't help but feel disgust from a paid Cisco employee bashing an open source maintainer simply because his ego got slightly bruised.
I don’t know that seems like a good way to make sure no one knows how to maintain these things after the core contributors die. I’ve seen PR ping pong mentioned elsewhere and it’s odd because “PR ping pong” is part of how I became an effective member of my team and eventually eased some of the load for everyone else.
The entire purpose of these responses is to repel the drive-by contributor who invariably generates clerical work for the full-time maintainer. It's just a sad fact about the nature of this work that it's often done by volunteers who are massively overloaded, and "contributions" are often so minuscule or low quality that they are actually just additional time-demands on already-overworked maintainers.
There is a good book about this: https://www.amazon.com/Working-Public-Making-Maintenance-Sof...