I've experienced similar (not in the kernel, but a high profile OS project), making an initial contribution is interpreted as an offer to become the personal secretary for one of the project full timers. I politely backed away.
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...
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.)
It works! I'd rarely file a bugfix to a high-profile project now I know how contemptuous some of the maintainers are.
I just did. Because the burden of dealing with an annoying contributor outweighs the value of their contribution
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.
(Unless you mean literally personal secretary and dealing with their personal life or setting meetings up and stuff, I assumed you meant tell you what bugs are worth looking at etc)