8 ms·

Is this really necessary? If I post a bug report like "when I run command X, there's a crash", how many OSS authors get annoyed? If anyone gets annoyed at tha

Is this really necessary? If I post a bug report like "when I run command X, there's a crash", how many OSS authors get annoyed? If anyone gets annoyed at that, this is a sign they need to take a break from the project (or from the bug database), not a sign that the bug reporter needs to do anything differently.

pydry 6y ago
I've been yelled at for reporting what I saw as a bug (coz I thought the behavior was bizarre and unexpected) and the author saw as a support request (coz he saw it as expected). Another common pattern is this "no man's land" of bug responsibility between projects. Project A interacts with project B and that interaction causes a bug or awful problem. Project A and B both wash their hands of it. I don't particularly mind support requests via the bug tracker - particularly since a pattern of support requests often highlights a UX issue or a lack of clarity in the docs. Some people view them as irritating annoyances that should be pushed to some forum like stack overflow though.
- sjrd 6y ago
  > Some people view them as irritating annoyances that should be pushed to some forum like stack overflow though. I maintain a fairly large open source project. We close "issues" that are support requests on sight, with a more-or-less automatic message telling the person that they should use Stack Overflow or Gitter for questions. This is not because they are irritating annoyances. I in fact do support people on Stack Overflow and Gitter about the project. But there are at least two reasons for keeping things separate: a) In terms of organization, I need the issue list to be about things that are actionable in the repo. b) More importantly: only the core developers and some very enthusiastic people follow the GitHub repo. There are many more people available for and willing to support on Stack Overflow and Gitter. It is important that support requests reach these people so that support can be distributed. A lot of users even have more practical experience with the project than the core developers.
  - dkersten 6y ago
    Personally, I don't like Gitter or Slack as I find them much harder to search or find already answered questions. Stack Overflow works very well though, a question-answer format is perfect for support requests. Its also much easier to search or link to. I think that Github issues feel closer to that for many people. Its also important that the project clearly specifies where to ask for help. I'm often reluctant to open issues that aren't bug reports, but the project isn't clear where I should ask.
    - retox 6y ago
      I wonder if it would be beneficial if github added a support forum to each repo, though having to deal with spam may turn into a major overhead. It would give the opportunity to contribute to a project to those with less technical skills and all the information would be in one place. Gitlab and other products may already have this, I don't tend to use them.
      - dkersten 6y ago
        GitHub has "Discussions" on the way[1] which seem like they will greatly help the situation. You can see one in action here[2], which is where I first saw it. Doesn't seem to be generally available yet though, but when it is, I think it will improve issues greatly. [1] https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/ https://github.blog/2020-05-06-new-from-satellite-2020-githu... [2] https://github.com/clap-rs/clap/discussions https://github.com/clap-rs/clap/discussions
        retox 6y ago
        Fantastic, thank you. Should have known better than to think it wasn't on the way eventually.
- benibela 6y ago
  The worst is when project B is a closed source project. I have such an open-source project A that interacts with such a project B. That is the worst. Then I get a bug report, project B got a new version and your project A does not work anymore. Fix it! Then I ask what was changed in the new version of project B. Then they say, they do not know. Then I ask the company of project B. They do not respond. Then I get another email from a user, you need to fix it for the new project B version. Then I send 5 emails to the company of project B. Then they respond, "we do not support project A". And I do not have access to project B myself
GordonS 6y ago
It depends on the maintainer. There are some projects I've submitted issues for without such excessively fluffy language, and the maintainer has responded very negatively. I hate this, because it makes the maintainer look like a cantankerous prick, and it also puts me off using what might be a great project (and of course others will read it to). IME, if I'm not familiar with the maintainers' temperament, I'm most successful using something like this template: "Hi! First let me say how much I appreciate this library, it really helps with X. I've found what I believe is a bug, whereby X (provide logs, stack trace, whatever is relevant). You can reproduce this by X (provide repro steps or code snippet as appropriate)." For projects I'm familiar with, things can be more business-like and to the point, and I can also offer to send a PR.
- GordonS 6y ago
  I want to add, as an OSS maintainer myself, I don't put the blame for attitude solely on the kind of maintainer I mentioned. It's very common to get get users using demanding, demeaning or ungrateful language, and that type of thing does wear on you.
- reificator 6y ago
  Meanwhile this kind of dancing around the issue will piss me off, though I don't usually respond so. If there's a bug, tell me what happened, what you expected, what your config/environment looks like, and if it's a library a minimal code example that triggers the bug. I don't need to hear about how your grandmother's favorite chili recipe saved your uncle's best friend's life when he was trapped in the Siberian wilderness after going on the run from the Malaysian government. Just tell me how to make the damn chili.
  - GordonS 6y ago
    I take your point, and I wouldn't want to read through reams of frivolity either - but there really wasn't anything like that in my example; it's 1 or 2 like saying "thanks", and then my example included all of the stuff you asked for.
    - 6y ago
formerly_proven 6y ago
For some people their code are like their kids; precious and they can do no wrong. These tend to be a problem when bugs crop up, because bug reports are like a personal insult to them. Personally, I've long held the view that practically all code is buggy one way or another and that many things can mean throwing code away is the best way forward, so one just shouldn't be attached to a few bytes. One should rather feel attached to the project at hand, which then naturally results in one trying to improve it, which means bug reports are GOOD and EXCELLENT because they give very clear hints were the project can be improved.
- aidenn0 6y ago
  I think it's also that people don't like feeling stupid, and most bugs are stupid mistakes, so having one pointed out can make you feel stupid.
  - brigandish 6y ago
    If you've got tests then you've already seen how many stupid mistakes you make, long before release. To get that far and still not have learnt enough humility to accept there may be more is quite the achievement!
    - KSteffensen 6y ago
      Catching a bug while testing is clever. You wrote a good test. Getting a bug report is stupid. You made a mistake, didn't catch it while testing and actually published it for others to see how stupid you are.
      - brigandish 6y ago
        Do you know of a single programmer who has written a program of any but the absolute lowest complexity that is entirely bug free upon release?
        memorysafety 6y ago
deleted 6y ago
[deleted]
rmrfrmrf 6y ago
If that's actually what you wrote, I would be annoyed as a maintainer. There's an implied assumption here that "command X" was never tested and must therefore crash for everyone. In 99% of cases, "command X" runs without issue and has been tested on multiple configurations. If it turns out that "command X" crashes for you because your company's IT department misconfigured the certificate authorities on a particular Windows build image, you end up wasting massive amounts of everyone's time. After maintainers get burned by these kind of bug reports tens of times, they understandably get hostile to such low effort bug reporting.
- FartyMcFarter 6y ago
  What I had in mind was that "X" included all the relevant parameters. An actual runnable command, not just the name of a program.
  - rmrfrmrf 6y ago
    So if I run the same command with all of the parameters you specify and it works correctly, I can close your issue as non-reproducible, right?
    - djur 6y ago
      Sure, as long as you're polite about it (and it would be incumbent on the reporter to be polite as well). It's not your responsibility to help users debug. If you do that often, for issues that are actually more widely reproducible, your software might end up getting a reputation for instability. Whether you care about that or not is up to you.
    - FartyMcFarter 6y ago
      That is up to you. Different people/projects have different standards for how much effort they put into a bug. If you think the issue is unlikely to be an actual bug, that would seem like the correct course to take. If you suspect it might depend on other details and you're keen to investigate more, you could ask for more details. One related thing that many projects do is to have a bug template that asks for details such as software versions, operating system, CPU, etc. This can help a lot in reproducing bugs.
WalterBright 6y ago
Not me. I appreciate bug reports and the time the submitter took to post them. Even if they aren't clear enough for me to find the problem, someone else may run over the bug, too, and having multiple inadequate submissions often provides enough clues that we can fix the problem. No need to stroke our egos, just the facts is just fine.

pydry 6y ago

I've been yelled at for reporting what I saw as a bug (coz I thought the behavior was bizarre and unexpected) and the author saw as a support request (coz he saw it as expected). Another common pattern is this "no man's land" of bug responsibility between projects. Project A interacts with project B and that interaction causes a bug or awful problem. Project A and B both wash their hands of it. I don't particularly mind support requests via the bug tracker - particularly since a pattern of support requests often highlights a UX issue or a lack of clarity in the docs. Some people view them as irritating annoyances that should be pushed to some forum like stack overflow though.

sjrd 6y ago
> Some people view them as irritating annoyances that should be pushed to some forum like stack overflow though. I maintain a fairly large open source project. We close "issues" that are support requests on sight, with a more-or-less automatic message telling the person that they should use Stack Overflow or Gitter for questions. This is not because they are irritating annoyances. I in fact do support people on Stack Overflow and Gitter about the project. But there are at least two reasons for keeping things separate: a) In terms of organization, I need the issue list to be about things that are actionable in the repo. b) More importantly: only the core developers and some very enthusiastic people follow the GitHub repo. There are many more people available for and willing to support on Stack Overflow and Gitter. It is important that support requests reach these people so that support can be distributed. A lot of users even have more practical experience with the project than the core developers.
- dkersten 6y ago
  Personally, I don't like Gitter or Slack as I find them much harder to search or find already answered questions. Stack Overflow works very well though, a question-answer format is perfect for support requests. Its also much easier to search or link to. I think that Github issues feel closer to that for many people. Its also important that the project clearly specifies where to ask for help. I'm often reluctant to open issues that aren't bug reports, but the project isn't clear where I should ask.
  - retox 6y ago
    I wonder if it would be beneficial if github added a support forum to each repo, though having to deal with spam may turn into a major overhead. It would give the opportunity to contribute to a project to those with less technical skills and all the information would be in one place. Gitlab and other products may already have this, I don't tend to use them.
    - dkersten 6y ago
      GitHub has "Discussions" on the way[1] which seem like they will greatly help the situation. You can see one in action here[2], which is where I first saw it. Doesn't seem to be generally available yet though, but when it is, I think it will improve issues greatly. [1] https://github.blog/2020-05-06-new-from-satellite-2020-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/ https://github.blog/2020-05-06-new-from-satellite-2020-githu... [2] https://github.com/clap-rs/clap/discussions https://github.com/clap-rs/clap/discussions
      - retox 6y ago
        Fantastic, thank you. Should have known better than to think it wasn't on the way eventually.
benibela 6y ago
The worst is when project B is a closed source project. I have such an open-source project A that interacts with such a project B. That is the worst. Then I get a bug report, project B got a new version and your project A does not work anymore. Fix it! Then I ask what was changed in the new version of project B. Then they say, they do not know. Then I ask the company of project B. They do not respond. Then I get another email from a user, you need to fix it for the new project B version. Then I send 5 emails to the company of project B. Then they respond, "we do not support project A". And I do not have access to project B myself

GordonS 6y ago

It depends on the maintainer. There are some projects I've submitted issues for without such excessively fluffy language, and the maintainer has responded very negatively. I hate this, because it makes the maintainer look like a cantankerous prick, and it also puts me off using what might be a great project (and of course others will read it to). IME, if I'm not familiar with the maintainers' temperament, I'm most successful using something like this template: "Hi! First let me say how much I appreciate this library, it really helps with X. I've found what I believe is a bug, whereby X (provide logs, stack trace, whatever is relevant). You can reproduce this by X (provide repro steps or code snippet as appropriate)." For projects I'm familiar with, things can be more business-like and to the point, and I can also offer to send a PR.

GordonS 6y ago
I want to add, as an OSS maintainer myself, I don't put the blame for attitude solely on the kind of maintainer I mentioned. It's very common to get get users using demanding, demeaning or ungrateful language, and that type of thing does wear on you.
reificator 6y ago
Meanwhile this kind of dancing around the issue will piss me off, though I don't usually respond so. If there's a bug, tell me what happened, what you expected, what your config/environment looks like, and if it's a library a minimal code example that triggers the bug. I don't need to hear about how your grandmother's favorite chili recipe saved your uncle's best friend's life when he was trapped in the Siberian wilderness after going on the run from the Malaysian government. Just tell me how to make the damn chili.
- GordonS 6y ago
  I take your point, and I wouldn't want to read through reams of frivolity either - but there really wasn't anything like that in my example; it's 1 or 2 like saying "thanks", and then my example included all of the stuff you asked for.
  - 6y ago

formerly_proven 6y ago

For some people their code are like their kids; precious and they can do no wrong. These tend to be a problem when bugs crop up, because bug reports are like a personal insult to them. Personally, I've long held the view that practically all code is buggy one way or another and that many things can mean throwing code away is the best way forward, so one just shouldn't be attached to a few bytes. One should rather feel attached to the project at hand, which then naturally results in one trying to improve it, which means bug reports are GOOD and EXCELLENT because they give very clear hints were the project can be improved.

aidenn0 6y ago
I think it's also that people don't like feeling stupid, and most bugs are stupid mistakes, so having one pointed out can make you feel stupid.
- brigandish 6y ago
  If you've got tests then you've already seen how many stupid mistakes you make, long before release. To get that far and still not have learnt enough humility to accept there may be more is quite the achievement!
  - KSteffensen 6y ago
    Catching a bug while testing is clever. You wrote a good test. Getting a bug report is stupid. You made a mistake, didn't catch it while testing and actually published it for others to see how stupid you are.
    - brigandish 6y ago
      Do you know of a single programmer who has written a program of any but the absolute lowest complexity that is entirely bug free upon release?
      - memorysafety 6y ago

deleted 6y ago

[deleted]

rmrfrmrf 6y ago

If that's actually what you wrote, I would be annoyed as a maintainer. There's an implied assumption here that "command X" was never tested and must therefore crash for everyone. In 99% of cases, "command X" runs without issue and has been tested on multiple configurations. If it turns out that "command X" crashes for you because your company's IT department misconfigured the certificate authorities on a particular Windows build image, you end up wasting massive amounts of everyone's time. After maintainers get burned by these kind of bug reports tens of times, they understandably get hostile to such low effort bug reporting.

FartyMcFarter 6y ago
What I had in mind was that "X" included all the relevant parameters. An actual runnable command, not just the name of a program.
- rmrfrmrf 6y ago
  So if I run the same command with all of the parameters you specify and it works correctly, I can close your issue as non-reproducible, right?
  - djur 6y ago
    Sure, as long as you're polite about it (and it would be incumbent on the reporter to be polite as well). It's not your responsibility to help users debug. If you do that often, for issues that are actually more widely reproducible, your software might end up getting a reputation for instability. Whether you care about that or not is up to you.
  - FartyMcFarter 6y ago
    That is up to you. Different people/projects have different standards for how much effort they put into a bug. If you think the issue is unlikely to be an actual bug, that would seem like the correct course to take. If you suspect it might depend on other details and you're keen to investigate more, you could ask for more details. One related thing that many projects do is to have a bug template that asks for details such as software versions, operating system, CPU, etc. This can help a lot in reproducing bugs.

WalterBright 6y ago

Not me. I appreciate bug reports and the time the submitter took to post them. Even if they aren't clear enough for me to find the problem, someone else may run over the bug, too, and having multiple inadequate submissions often provides enough clues that we can fix the problem. No need to stroke our egos, just the facts is just fine.