I generally take the approach that I fix the issue, add a comment and ask if they want a pull request and don't do anything else unless the maintainer expresses interest. If they do express interest, I'll go pretty far in trying to clean up my fixes to make them suitable, as long as they still solve my problem. If they don't express any interest, oh well, my fork will be there and a comment will be there to point other people to a viable solution.

A lot of the time the response is very welcoming. E.g. I recently provided a substantial patch to Beaneater (Beanstalkd client library for Ruby) and the maintainers were all over it immediately, and we got it merged in quickly.

The benefit of taking the effort is to be able to keep up with upstream without having to reapply patches. But that benefit is limited (often I will prefer to stay with an "old" known entity rather than tracking upstream, as long as security concerns don't force me to upgrade), and so I don't spend a lot of time pursuing it.

I strongly believe code speaks louder than words in this kind of situation, and often shipping code will be more likely to get acceptance than engaging in discussions.