3 ms·

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.
        cpuguy83 6y ago
        Clearly you have had a bad experience. Sorry to hear that. I will nearly always, unless explicitly asked not to, offer help to work around a bug if it is at all possible. I can't control if someone is upset by this nor can I tell if they will be unless they say as much... but not doing so would be significantly less helpful to a majority of people. So "usually" does matter.
        cxr 6y ago
        I think you just validated mjw1007's impulse to add the disclaimer. And it's more than a bad experience. It's an entire culture, which leads to the point that mjw1007's comment here is the top voted one for this story, and I've written comments to explain why I stopped filing bugs for projects that host their trackers on GitHub.
    - jlokier 6y ago
      > If mjw1007 reports a bug in a piece of software that mjw1007 doesn't even use Given the burden on upstream maintainers, probably mjw1007 should have included a crucial bit of information in the bug report: That they are not using the software any more, this is just to report a known bug they encountered before. I'd say at least half of my bug reports are for things where I've already found a workaround for my situation, or I'm not using the software any more. Those bug reports are a burden to create, because I don't get anything directly useful from doing so, and I usually take care to show how to reproduce the bug, ideally with a minimal reproducer, which sometimes takes hours. If the problem upstream gets solved, it's nice to know I contributed a little civic duty, but I won't likely need the fix. But I know what it's like to be on the receiving end of reports. So as a reporter, it's on me to not waste the upstream maintainer's time, by making it clear this is just an informational bug report. After all it's more burdensome for them than it is for me. If they report back, as many do, asking if can try X, Y and Z, I may have to apologise and politely say I'm not using it any more. Ideally I already mentioned that, but upstream might not have noticed the first time. If upstream says they can't help me or fix the bug without further input from me, it would silly for me to become infuriated because my effort seems wasted. That's on me. When I contribute a bug report freely as a sort of civic contribution, it's not reasonable to expect upstream to do anything in particular with it if I'm not willing to help as well. It has to be given freely with no expectation on my part, because they haven't promised anything. If I'm infuriated that the maintainer responds as if I want something from them, and I didn't bother to clarify that I don't, then ironically that means I do want something from them, which is to read my mind and magically guess what I do and don't want, or alternatively to avoid assuming, spend an extra round trip asking what I was too lazy to say up front.
  - djur 6y ago
    There's nothing stopping anyone from acknowledging the bug _and_ offering a workaround. That's the best of both worlds. The complaint here seems to be about responses that dismiss the validity of the bug report based on the existence of a workaround. It's totally valid for the maintainer of an open source project's response to a bug report to be "I don't care enough about this use case to fix this bug", but the courteous thing to do is to be upfront about that.
- 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...

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.
      - cpuguy83 6y ago
        Clearly you have had a bad experience. Sorry to hear that. I will nearly always, unless explicitly asked not to, offer help to work around a bug if it is at all possible. I can't control if someone is upset by this nor can I tell if they will be unless they say as much... but not doing so would be significantly less helpful to a majority of people. So "usually" does matter.
        cxr 6y ago
        I think you just validated mjw1007's impulse to add the disclaimer. And it's more than a bad experience. It's an entire culture, which leads to the point that mjw1007's comment here is the top voted one for this story, and I've written comments to explain why I stopped filing bugs for projects that host their trackers on GitHub.
  - jlokier 6y ago
    > If mjw1007 reports a bug in a piece of software that mjw1007 doesn't even use Given the burden on upstream maintainers, probably mjw1007 should have included a crucial bit of information in the bug report: That they are not using the software any more, this is just to report a known bug they encountered before. I'd say at least half of my bug reports are for things where I've already found a workaround for my situation, or I'm not using the software any more. Those bug reports are a burden to create, because I don't get anything directly useful from doing so, and I usually take care to show how to reproduce the bug, ideally with a minimal reproducer, which sometimes takes hours. If the problem upstream gets solved, it's nice to know I contributed a little civic duty, but I won't likely need the fix. But I know what it's like to be on the receiving end of reports. So as a reporter, it's on me to not waste the upstream maintainer's time, by making it clear this is just an informational bug report. After all it's more burdensome for them than it is for me. If they report back, as many do, asking if can try X, Y and Z, I may have to apologise and politely say I'm not using it any more. Ideally I already mentioned that, but upstream might not have noticed the first time. If upstream says they can't help me or fix the bug without further input from me, it would silly for me to become infuriated because my effort seems wasted. That's on me. When I contribute a bug report freely as a sort of civic contribution, it's not reasonable to expect upstream to do anything in particular with it if I'm not willing to help as well. It has to be given freely with no expectation on my part, because they haven't promised anything. If I'm infuriated that the maintainer responds as if I want something from them, and I didn't bother to clarify that I don't, then ironically that means I do want something from them, which is to read my mind and magically guess what I do and don't want, or alternatively to avoid assuming, spend an extra round trip asking what I was too lazy to say up front.
- djur 6y ago
  There's nothing stopping anyone from acknowledging the bug _and_ offering a workaround. That's the best of both worlds. The complaint here seems to be about responses that dismiss the validity of the bug report based on the existence of a workaround. It's totally valid for the maintainer of an open source project's response to a bug report to be "I don't care enough about this use case to fix this bug", but the courteous thing to do is to be upfront about that.
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...