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:
Always Read Contributing Document
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 for help.
Never tell "Please fix/merge it, urgent!"
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:
- Is there anything I can do to get it merged? Thank you.
- Any other information about the issue you need? Thank you.
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.
Avoid asking for help privately
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.
Be Active
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.
P.S
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.
Latest comments (2)
Also important to mention is that they're not there to teach you how to code or to fix your code. If the docs are poor then fine, mention that the docs are poor but don't post your code and ask how to fix it.
I maintain a promise wrapper for MySQL and often get issues raised by people who either don't understand promises or don't understand MySQL.
Thanks for this post - I think it's especially helpful for new contributors to be aware of this etiquette.