6 ms·

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

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.
  - cxr 6y ago
    I don't recognize what it means for something to be "just an informational bug report". You either have a bugtracker or you don't. It's supposed to contain a list of known defects or it isn't. > After all it's more burdensome for them than it is for me. This is nuts. This can only be true if there are much, much bigger problems afoot. Most of this was figured out years ago and opened up to the public under Netscape. Folks abandoning or ignoring those lessons is precisely why maintainers are burdened, burning out, and complaining about it—they've fostered a culture that encourages outsiders (and the developer's own process/practices) to "burden" them. > 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. You're strawmanning. Your job here is not to postulate the most convenient[1] circumstances that could be true and which would make it easy for the fury to seem "silly". It's to deal with the concrete, non-hypothetical circumstances where people have responded in genuinely obnoxious ways to bug reports. Imagining counterfactuals is easy. > 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 Sure, but the expectation that people not be presumptuous and/or rude where it's unprovoked is an expectation that runs through everything. It should be regarded as axiomatic. 1. https://wiki.lesswrong.com/wiki/Least_convenient_possible_world https://wiki.lesswrong.com/wiki/Least_convenient_possible_wo...
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.

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.
- cxr 6y ago
  I don't recognize what it means for something to be "just an informational bug report". You either have a bugtracker or you don't. It's supposed to contain a list of known defects or it isn't. > After all it's more burdensome for them than it is for me. This is nuts. This can only be true if there are much, much bigger problems afoot. Most of this was figured out years ago and opened up to the public under Netscape. Folks abandoning or ignoring those lessons is precisely why maintainers are burdened, burning out, and complaining about it—they've fostered a culture that encourages outsiders (and the developer's own process/practices) to "burden" them. > 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. You're strawmanning. Your job here is not to postulate the most convenient[1] circumstances that could be true and which would make it easy for the fury to seem "silly". It's to deal with the concrete, non-hypothetical circumstances where people have responded in genuinely obnoxious ways to bug reports. Imagining counterfactuals is easy. > 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 Sure, but the expectation that people not be presumptuous and/or rude where it's unprovoked is an expectation that runs through everything. It should be regarded as axiomatic. 1. https://wiki.lesswrong.com/wiki/Least_convenient_possible_world https://wiki.lesswrong.com/wiki/Least_convenient_possible_wo...

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.