5 ms·

The goal of filing a bug is to help the project. I've had cases where I've filed a report saying something like "if I enable both A and B, the log messages dis

The goal of filing a bug is to help the project. I've had cases where I've filed a report saying something like "if I enable both A and B, the log messages disappear", and the maintainer has responded with "Why do you need both A and B? Could you use A and C instead?". That's a waste of time for both of us. If I want to ask someone about the merits of B vs C I'll find somewhere better than a bug tracker.

cpuguy83 6y ago
A lot of the time people just don't know about some feature or work-around to the problem. That's likely what's happening there.
- lmeyerov 6y ago
  Yep, or don't know how to use it, or messed up in combining api keys. Not immediate bugs or useful feedback... but I find these worthwhile after playing the "5 why's game". user error -> poor error message -> bad example docs and wonky API for that area -> underserved use case. that's useful feedback!
- cxr 6y ago
  Here's a rule of thumb: if a person shows up and reports a bug, and the response is to give a workaround as if that person were really saying, "I need to be able to do X. How can do that?", then the bugtracker is not being used correctly. Not filing bugs is easier than filing bugs. If someone stops to file a bug (as the original commenter wrote, "to help the project") and someone responds to the bug reporter as if they're trying to get help, then it's just going to annoy the bug reporter and make it clear that they wasted their time. That it's possible for the ambiguity to even exist is a consequence of mixing bug reports with other types of feedback. Bug trackers should be for tracking bugs.
  - cpuguy83 6y ago
    I do not agree at all. Bugs often require work around or alternatives while the bug is still active. You always try to stop the bleeding first before you try to do anything else.
    - cxr 6y ago
      You're approaching this from a position that relies on a bunch of unsound assumptions. You're assuming that the person is bleeding. You're assuming they're trying to stop it. If mjw1007 reports a bug in a piece of software that mjw1007 doesn't even use, and the project maintainer responds as if mjw1007 is trying to get something from the maintainer, then in addition to it becoming clear that having taken the time to file the bug was a waste, the maintainer's response is going to be infuriating. I can corroborate with firsthand experience, and you should be able to agree just by considering the circumstances—which differ from your assumptions, and that's the problem. There's a fundamental disconnect here between how you understand the bugtracker to be used versus how others are actually using it and what any given person expects to get out of it. To repeat: that it's possible for the maintainer (or one of the project's fans) to give a response that gets mjw1007's intention wrong is only possible because people are freely mixing bug reports with other types of feedback. (The project doesn't actually have a bugtracker at that point!) Side note: it's not useful to move from concrete to abstract by turning to a metaphor ("bleeding"); it makes it more difficult. See also: https://news.ycombinator.com/item?id=24311700 https://news.ycombinator.com/item?id=24311700
      - cpuguy83 6y ago
        Even if the original reporter doesn't care (side note, they usually do in my experience), other people also stumble onto the report. There's a lot of assumptions being made here. A maintainer offering help is not a waste of time. The offer is not just for the original reporter.
        cxr 6y ago
        "Usually" doesn't matter. If 100 people drop by to demand the project maintainer make a change or tell them how they can do something to best benefit their company and look good by doing it, and 1 person stops by with a high quality bug report, it follows that annoying the latter is how you guarantee that your future lies in dealing with 100 assholes, because person #101 is going to disappear. > maintainer offering help That's a generous way to put it.
  - tzs 6y ago
    Sometimes deciding what the bug is depends on knowing what people are doing. For example, lets say the report is that a program crashes when a particular set of options is used together. The developers thought that there were no situations where it made sense for someone to use that particular set of options. They need to decide if the bug is that the program accepts that combination of options rather than giving an error about an illegal option combination, or the bug is that the developers were wrong and that combination should be made to work.
    - deleted 6y ago
      [deleted]
  - coldtea 6y ago
    >Here's a rule of thumb: if a person shows up and reports a bug, and the response is to give a workaround as if that person were really saying, "I need to be able to do X. How can do that?", then the bugtracker is not being used correctly. Well, most users don't use the bugtracker correctly, so there's that...
srtjstjsj 6y ago
Triage is not a waste of time. Developers usually have far less time than bugs or missing features. If someone asks a question, it's because they would like an answer.
- mjw1007 6y ago
  Right, always answer the question, even if you don't think the answer will be helpful: you might be wrong, and if you're not then providing the answer is likely to be the quickest way for the asker to find out that they didn't need to know. But also: don't ask "why do you X" if someone hasn't said they "X". On this occasion I didn't particularly want to enable both A and B, I just noticed the problem when I briefly did.
Drdrdrq 6y ago
Sometimes developers simply want to learn more about how the users use their creation. It might look like a waste of time to you, but it only is if you don't cooperate. Obviously there is something unexpected about using both A and B, so maybe just fixing the bug the way you envision is not the best approach. Maybe developer knows something you don't, or vice versa.
coldtea 6y ago
The thing is, a developer also has a concept of his project. He doesn't necessarily want it to be all things to all people, and support all of A, B, and C together. He might even consider A+B distateful and avoid coding it for that alone...

cpuguy83 6y ago

A lot of the time people just don't know about some feature or work-around to the problem. That's likely what's happening there.

lmeyerov 6y ago
Yep, or don't know how to use it, or messed up in combining api keys. Not immediate bugs or useful feedback... but I find these worthwhile after playing the "5 why's game". user error -> poor error message -> bad example docs and wonky API for that area -> underserved use case. that's useful feedback!
cxr 6y ago
Here's a rule of thumb: if a person shows up and reports a bug, and the response is to give a workaround as if that person were really saying, "I need to be able to do X. How can do that?", then the bugtracker is not being used correctly. Not filing bugs is easier than filing bugs. If someone stops to file a bug (as the original commenter wrote, "to help the project") and someone responds to the bug reporter as if they're trying to get help, then it's just going to annoy the bug reporter and make it clear that they wasted their time. That it's possible for the ambiguity to even exist is a consequence of mixing bug reports with other types of feedback. Bug trackers should be for tracking bugs.
- cpuguy83 6y ago
  I do not agree at all. Bugs often require work around or alternatives while the bug is still active. You always try to stop the bleeding first before you try to do anything else.
  - cxr 6y ago
    You're approaching this from a position that relies on a bunch of unsound assumptions. You're assuming that the person is bleeding. You're assuming they're trying to stop it. If mjw1007 reports a bug in a piece of software that mjw1007 doesn't even use, and the project maintainer responds as if mjw1007 is trying to get something from the maintainer, then in addition to it becoming clear that having taken the time to file the bug was a waste, the maintainer's response is going to be infuriating. I can corroborate with firsthand experience, and you should be able to agree just by considering the circumstances—which differ from your assumptions, and that's the problem. There's a fundamental disconnect here between how you understand the bugtracker to be used versus how others are actually using it and what any given person expects to get out of it. To repeat: that it's possible for the maintainer (or one of the project's fans) to give a response that gets mjw1007's intention wrong is only possible because people are freely mixing bug reports with other types of feedback. (The project doesn't actually have a bugtracker at that point!) Side note: it's not useful to move from concrete to abstract by turning to a metaphor ("bleeding"); it makes it more difficult. See also: https://news.ycombinator.com/item?id=24311700 https://news.ycombinator.com/item?id=24311700
    - cpuguy83 6y ago
      Even if the original reporter doesn't care (side note, they usually do in my experience), other people also stumble onto the report. There's a lot of assumptions being made here. A maintainer offering help is not a waste of time. The offer is not just for the original reporter.
      - cxr 6y ago
        "Usually" doesn't matter. If 100 people drop by to demand the project maintainer make a change or tell them how they can do something to best benefit their company and look good by doing it, and 1 person stops by with a high quality bug report, it follows that annoying the latter is how you guarantee that your future lies in dealing with 100 assholes, because person #101 is going to disappear. > maintainer offering help That's a generous way to put it.
- tzs 6y ago
  Sometimes deciding what the bug is depends on knowing what people are doing. For example, lets say the report is that a program crashes when a particular set of options is used together. The developers thought that there were no situations where it made sense for someone to use that particular set of options. They need to decide if the bug is that the program accepts that combination of options rather than giving an error about an illegal option combination, or the bug is that the developers were wrong and that combination should be made to work.
  - deleted 6y ago
    [deleted]
- coldtea 6y ago
  >Here's a rule of thumb: if a person shows up and reports a bug, and the response is to give a workaround as if that person were really saying, "I need to be able to do X. How can do that?", then the bugtracker is not being used correctly. Well, most users don't use the bugtracker correctly, so there's that...

srtjstjsj 6y ago

Triage is not a waste of time. Developers usually have far less time than bugs or missing features. If someone asks a question, it's because they would like an answer.

mjw1007 6y ago
Right, always answer the question, even if you don't think the answer will be helpful: you might be wrong, and if you're not then providing the answer is likely to be the quickest way for the asker to find out that they didn't need to know. But also: don't ask "why do you X" if someone hasn't said they "X". On this occasion I didn't particularly want to enable both A and B, I just noticed the problem when I briefly did.

Drdrdrq 6y ago

Sometimes developers simply want to learn more about how the users use their creation. It might look like a waste of time to you, but it only is if you don't cooperate. Obviously there is something unexpected about using both A and B, so maybe just fixing the bug the way you envision is not the best approach. Maybe developer knows something you don't, or vice versa.

coldtea 6y ago

The thing is, a developer also has a concept of his project. He doesn't necessarily want it to be all things to all people, and support all of A, B, and C together. He might even consider A+B distateful and avoid coding it for that alone...