I am a PHP developer with works especially using Zend Framework. From August 2012, I started became a Zend Framework Contributor, now as top 4 Zend Framework 2 contributor listed here : https://github.com/zendframework/zf2/graphs/contributors .
There are many open-source contributors/maintainers out there. Some of them may look not seem like "patient people", closing issues without comment, or not replying at all. There are reasons behind it: this may not be a priority, they may be busy in another project (which is paid), or your problem can be marked as "feature request" which will take another maintenance burden, and possibly open new bug(s), or, you simply did not follow the contribution guidelines.
Apart from all of these reasons, the maintainers are still human, and we need to respect it. Here are some suggestions for effectively requesting assistance from maintainers:
Don't blindly create issues unless you want them to be closed blindly too. OSS usually have documentation, and if it is available in any capacity, you should read it before creating an issue or asking help.
Or any other "I need it today" statements. Remember, unless you pay for it, they do not owe you anything. Never. Act. Like. A. Boss.
Always wait for a few days. If you really need a fix, you can write better statements, like:
Yes, you should always say thank you, even if it is never merged. And if the person you asked for help is back and tried to help you, say thanks again. Well, for merged pull request, saying "thanks" to maintainers can fill up his/her inbox, so consider it for issues primarily.
While waiting for the merge, you can do fork the repository and use your fix temporary in your project until it merged. Remember, it is open-source.
Your issue can be another person's issue as well, so, unless it is a security issue, you should ask it publicly (issue, irc, forum). While the maintainers don't have a chance to answer, other contributors may can.
Always be active, provide a reproducible code/repository, a clear explanation about your issue, and/or a failure test case. If you don't provide them, it will be very hard to get good feedback.
I got mention in twitter from @apr that this article misses a link to Eric Steven Raymond's document. While I didn't read that before, and I didn't pull anything from that, I can say that the document is very good and I think you need to read that.