NOOOOO. No thank you. There's a mailing list, a gitter.im channel, a Stack Overflow tag, and my email address, all of which can be found in the README file you see first thing. Don't abuse Issues for asking questions.
NOOOOO. No thank you. There's a mailing list, a gitter.im channel, a Stack Overflow tag, and my email address, all of which can be found in the README file you see first thing. Don't abuse Issues for asking questions.
I don't bother with mailing lists, and when I post an "issue" on the site, the system mails you on your preferred mailing list. Then You reply to the mail with your preffered client and it shows up for me in the issue thread on github?
Questions in an issue tracker are like rocks in my shoes. You have to work around them, and they bug you (the developer), not the person who put the rock there. When can a maintainer close a question-issue? Never - because whether a question has been resolved is up to the person asking, not the person answering. As a maintainer, if half the open issues in an issue tracker are questions, my "open issues list" is suddenly completely useless. And this is really common because lots of people asking questions will disappear and never never close the issue once the question has been answered.
User questions are important, but the github issue tracker isn't the right place for them. If you want to take notes but the only paper you can find is my todo list, its still not ok to take notes in my todo list. Github issues is the same.
If you can't be bothered to send an e-mail or submit to a mailing list, why should he/she be bothered to deal with your preferences? He/she is delivering the value, not you.
An issue feels, on the receiving end, like an accusation. The word says you did something wrong, and you've inconvenienced/harmed/let down someone, who is now waiting for you to make them whole again.
Answering a question gets you a thank you–you've done something altruistically,. You're a good person.
Fixing an issue? "Took long enough. Are you sure you're any good at this?"
At least some search the issues and answer the question themselves, it's even more valid when the maintainer decided to abandon the project.