5 ms·

Issues are important for a large verity of reasons. This just smacks of arrogance and hostility towards other developers you make your work open to. Yes, you d

Issues are important for a large verity of reasons. This just smacks of arrogance and hostility towards other developers you make your work open to. Yes, you don't have to answer people but when you put code out there for someone to use is it crazy to think people may have a question? That should go in an issue. People can search and find those answers. Telling someone to read the docs or go to StackOverflow, where the creator of the project may not be, is a terrible idea. Questions give a maintainer an idea of what should be focused on while keeping ownership of those questions for triage. Getting lots of people asking the same thing over and over? There's a good chance your design isn't that intuitive for that use case so maybe adjust? Good luck aggregating that information from multiple third party services. You can even find issues, even MAJOR issues without understanding the code at all. If someone finds a major issue but has no way of knowing how to tackle it now you're going to either miss out on knowing about it or they're going to submit a PR that is a big waste of their time and your time. This suggestion loses out on data and more direct interaction with users. Seems like a big loss-loss to me.

creepydata 9y ago
>You can even find issues, even MAJOR issues without understanding the code at all. Yep, even if you are a kindergartener. https://www.yahoo.com/tech/five-year-old-boy-finds-xbox-security-bug-81686748317.html https://www.yahoo.com/tech/five-year-old-boy-finds-xbox-secu...
franciscop 9y ago
"That should go in an issue." => Why? Does it apply for everyone? If a developer is so saturated that they can only look at 1 issue/day, wouldn't it be better for that issue to be of substance than a random, one-off question? I normally search through Google, which will find the best source for my question, be it Github or SO. Maybe the creator is not on SO because they have no time to go there. I do agree on everything else except that affirmation though, but I also think you are looking at it from the point of view of a maintainer with lots of time, when that might not be the situation. The maintainer might just not like providing free support for a company, while still caring for improving the project. This just seems like a way of (over)filtering things.
- BinaryIdiot 9y ago
  > Why? Does it apply for everyone? Yes. Even if it's a stupid question in the docs maybe that means the docs are not as good as they could be. Or maybe it's a lazy developer / user. It doesn't really matter; most questions are going to be asked multiple times. Saving it in an issue will help those users who use GitHub or Google search and come across it. > If a developer is so saturated that they can only look at 1 issue/day, wouldn't it be better for that issue to be of substance than a random, one-off question? This is a pipe dream. You're never going to get issues of substance. Even if the proposed gist you're going to get a lot of PR garbage that maybe wouldn't have been a PR in the first place. > I also think you are looking at it from the point of view of a maintainer with lots of time I don't see why. My position isn't A maintainer has to answer all questions in an expedient fashion. When you add friction you're going to get less of both the good and the bad. If that's a trade off you want to make, fine, but that's not how you make a good product IMO. It's an important skill to learn to take a lot of incoming noise and filtering it out to find the signal. It may be a good time to work on it if you have a OSS project people are using frequently enough to file issues. Don't forget there are other resources available to you. You may find people in the community to help answer questions, maybe you already answered a question in the past and you can quickly search for it and reply, etc.
  - franciscop 9y ago
    In my [limited] experience PR have always been orders of magnitude better [for me] than the average issue. Maybe it's because they focus on improving the project and not user's problems. It is true however that some times they were unsolicited and/or unwanted, however they were still a lot easier to process and review for me as a maintainer. Of course if you remove issues and reroute people to PR the quality of them will lower (though not so low as Issues) while you will miss important things, but still seems like the net result is a easier to review _issues_ which might be what saturated maintainers want. Edit: I totally agree with the last paragraph (and parts of others of course).
jlg23 9y ago
> This just smacks of arrogance and hostility towards other developers you make your work open to. You have gotten a sign wrong here in your sensor readings where arrogance and hostility are. Someone gives you a present that comes with a condition. You either take it, or you leave it. But calling the donor "arrogant and hostile" because you don't like a condition just got you uninvited from all future gift exchange parties. Back then when people still knew what patches were, the whole post of the OP would have been a one liner: [x] send patches or stfu
- chiefalchemist 9y ago
  Well. If the gift has two buttons, say red and blue. And pressing the sequence blue, red, blue, blue makes the server self destruct. Should there be a way to know that? Put another way, it's not a gift if it somehow eventually fucks over the receiver. Or perhaps you consider STDs a gift? ;)
- BugsJustFindMe 9y ago
  > Back then when people still knew what patches were, the whole post of the OP would have been a one liner: [x] send patches or stfu The person who says that is either an idiot or doesn't care about the product. There's really no third option. It's fine if you made something once that you no longer care about and want to abandon. Really! I understand that free software isn't free! Someone has to make it, and that takes time and effort and energy, and maybe you don't want to give that anymore! That's OK! But don't for a second think that it's reasonable to give a song and dance about pretending to still care while demanding pull requests for every bug. Mark the project abandoned, and go do something else without stringing people along. Otherwise you're being a prick to your users for no reason. Non-technical users discover bugs that you didn't catch all the time. If the developer/maintainer gives half a shit, they'll listen to those users.
  - Etheryte 9y ago
    I think you're trying to paint this too black and white. It's perfectly reasonable to be interested in supporting only the proactive user base of your project – that way both parties give and gain something.
kevinherron 9y ago
> is it crazy to think people may have a question? That should go in an issue. 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.
- exadeci 9y ago
  This way hundreds of people can ask the same question over and over? At least some search the issues and answer the question themselves, it's even more valid when the maintainer decided to abandon the project.
  - kevinherron 9y ago
    Seriously? Every option except emailing me personal is searchable.
- Sunset 9y ago
  How about this, 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?
  - josephg 9y ago
    No way. The point of an issue tracker is to be a todo list of bugs and features for the project. Its right there in the name - issue tracker. Ideally when a bug is fixed, I can mark the issue as FIXED and move on to the next one. 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.

creepydata 9y ago

>You can even find issues, even MAJOR issues without understanding the code at all. Yep, even if you are a kindergartener. https://www.yahoo.com/tech/five-year-old-boy-finds-xbox-security-bug-81686748317.html https://www.yahoo.com/tech/five-year-old-boy-finds-xbox-secu...

franciscop 9y ago

"That should go in an issue." => Why? Does it apply for everyone? If a developer is so saturated that they can only look at 1 issue/day, wouldn't it be better for that issue to be of substance than a random, one-off question? I normally search through Google, which will find the best source for my question, be it Github or SO. Maybe the creator is not on SO because they have no time to go there. I do agree on everything else except that affirmation though, but I also think you are looking at it from the point of view of a maintainer with lots of time, when that might not be the situation. The maintainer might just not like providing free support for a company, while still caring for improving the project. This just seems like a way of (over)filtering things.

BinaryIdiot 9y ago
> Why? Does it apply for everyone? Yes. Even if it's a stupid question in the docs maybe that means the docs are not as good as they could be. Or maybe it's a lazy developer / user. It doesn't really matter; most questions are going to be asked multiple times. Saving it in an issue will help those users who use GitHub or Google search and come across it. > If a developer is so saturated that they can only look at 1 issue/day, wouldn't it be better for that issue to be of substance than a random, one-off question? This is a pipe dream. You're never going to get issues of substance. Even if the proposed gist you're going to get a lot of PR garbage that maybe wouldn't have been a PR in the first place. > I also think you are looking at it from the point of view of a maintainer with lots of time I don't see why. My position isn't A maintainer has to answer all questions in an expedient fashion. When you add friction you're going to get less of both the good and the bad. If that's a trade off you want to make, fine, but that's not how you make a good product IMO. It's an important skill to learn to take a lot of incoming noise and filtering it out to find the signal. It may be a good time to work on it if you have a OSS project people are using frequently enough to file issues. Don't forget there are other resources available to you. You may find people in the community to help answer questions, maybe you already answered a question in the past and you can quickly search for it and reply, etc.
- franciscop 9y ago
  In my [limited] experience PR have always been orders of magnitude better [for me] than the average issue. Maybe it's because they focus on improving the project and not user's problems. It is true however that some times they were unsolicited and/or unwanted, however they were still a lot easier to process and review for me as a maintainer. Of course if you remove issues and reroute people to PR the quality of them will lower (though not so low as Issues) while you will miss important things, but still seems like the net result is a easier to review _issues_ which might be what saturated maintainers want. Edit: I totally agree with the last paragraph (and parts of others of course).

jlg23 9y ago

> This just smacks of arrogance and hostility towards other developers you make your work open to. You have gotten a sign wrong here in your sensor readings where arrogance and hostility are. Someone gives you a present that comes with a condition. You either take it, or you leave it. But calling the donor "arrogant and hostile" because you don't like a condition just got you uninvited from all future gift exchange parties. Back then when people still knew what patches were, the whole post of the OP would have been a one liner: [x] send patches or stfu

chiefalchemist 9y ago
Well. If the gift has two buttons, say red and blue. And pressing the sequence blue, red, blue, blue makes the server self destruct. Should there be a way to know that? Put another way, it's not a gift if it somehow eventually fucks over the receiver. Or perhaps you consider STDs a gift? ;)
BugsJustFindMe 9y ago
> Back then when people still knew what patches were, the whole post of the OP would have been a one liner: [x] send patches or stfu The person who says that is either an idiot or doesn't care about the product. There's really no third option. It's fine if you made something once that you no longer care about and want to abandon. Really! I understand that free software isn't free! Someone has to make it, and that takes time and effort and energy, and maybe you don't want to give that anymore! That's OK! But don't for a second think that it's reasonable to give a song and dance about pretending to still care while demanding pull requests for every bug. Mark the project abandoned, and go do something else without stringing people along. Otherwise you're being a prick to your users for no reason. Non-technical users discover bugs that you didn't catch all the time. If the developer/maintainer gives half a shit, they'll listen to those users.
- Etheryte 9y ago
  I think you're trying to paint this too black and white. It's perfectly reasonable to be interested in supporting only the proactive user base of your project – that way both parties give and gain something.

kevinherron 9y ago

> is it crazy to think people may have a question? That should go in an issue. 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.

exadeci 9y ago
This way hundreds of people can ask the same question over and over? At least some search the issues and answer the question themselves, it's even more valid when the maintainer decided to abandon the project.
- kevinherron 9y ago
  Seriously? Every option except emailing me personal is searchable.
Sunset 9y ago
How about this, 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?
- josephg 9y ago
  No way. The point of an issue tracker is to be a todo list of bugs and features for the project. Its right there in the name - issue tracker. Ideally when a bug is fixed, I can mark the issue as FIXED and move on to the next one. 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.