The first thing you should always do is create a ticket. There you can discuss if its worth spending time on a patch and what the best implementation could be. Pull requests that come up out of nowhere usually end up in the end of maintainers' queue. Or you can continue calling people who maintain free and open source projects in their spare time douchebags and neckbeards.
Personally, I think ticket description is more important than code, so I always create a ticket first. Unfortunately, github's issue tracker doesn't allow attachment, and thus it inadvertently promotes this "pull requests from out of nowhere" behavior. Call me old fashioned, but I still like ticket + attached patches way more than anything else. Recently, I stumbled upon a Google Code project with several defect issu…
"Refs #XXX" in the description (PR or any commit) ?