5 ms·

As an open source maintainer, and from what I've seen in general, there's absolutely no problem with reporting a bug! Do you mind me asking why you feel like ad

As an open source maintainer, and from what I've seen in general, there's absolutely no problem with reporting a bug! Do you mind me asking why you feel like adding that disclaimer? Is it because you don't want to seem demanding? What is the goal of "just report that the bug exists"? The main/only major problem I've seen with bug reports is when it's actually user code, so if you can show why you are certain that it's the library's code that is buggy that's best. If you can prove it with a code snippet, perfect. If you can point to a specific place of code and explain why it doesn't work, perfect. Or just explain exactly what happened. TBH, as long as you are just not be like "my code doesn't work fix it" you should be mostly fine. > Note: exception if the package is marked as e.g. "unmaintained" or such > Note: there might be some truly awful OSS maintainers, and some are infamous for it (e.g. Linus); but in my experience it's very very rare to find a negative reaction to a helpful PR.

mjw1007 6y ago
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
- 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...
atq2119 6y ago
> Note: there might be some truly awful OSS maintainers, and some are infamous for it (e.g. Linus); but in my experience it's very very rare to find a negative reaction to a helpful PR. It's important to understand that this is a misrepresentation of Linus Torvalds' attitude, even "before adjustment". I have seen plenty examples of negative reactions by him, but they were never in reaction to helpful PRs. They were always in reaction to bad code, unhelpful behavior, etc. In some cases, they were in reaction to people who were genuinely trying but failing to be helpful. In that case, the kind of blow-up that he became famous for is usually not helpful[0]. That doesn't make him an awful maintainer, though, it just makes him a human being with large but finite amounts of patience. [0] Though who knows -- perhaps there are cases where the blow-up was what finally got the point across to the person who thought they were being helpful but weren't really. In that case, the blow-up was perhaps a crude tool, but got the job done. Difficulties arise largely due to cultural differences, keeping in mind that "old-school kernel development" is a culture in itself that deserves to be treated with some respect.
- pessimizer 6y ago
  The thing about Torvalds for me is how long and explanatory his negative reactions were. He wouldn't just blow-up, he would explain in an abrasive manner exactly why he thought discussing this thing was a waste of his time. It was obviously a tactic (if subconscious) to get people to hesitate before proposing something he would think was obviously silly. I think it probably worked; the criticism of his responses were that they were unnecessarily personal and hurtful, not that they were wrong. I can also see why he backed away from it. If you're going to hurt people's feelings, best to do it through intermediaries so you don't get stained.

mjw1007 6y ago

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
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...

atq2119 6y ago

> Note: there might be some truly awful OSS maintainers, and some are infamous for it (e.g. Linus); but in my experience it's very very rare to find a negative reaction to a helpful PR. It's important to understand that this is a misrepresentation of Linus Torvalds' attitude, even "before adjustment". I have seen plenty examples of negative reactions by him, but they were never in reaction to helpful PRs. They were always in reaction to bad code, unhelpful behavior, etc. In some cases, they were in reaction to people who were genuinely trying but failing to be helpful. In that case, the kind of blow-up that he became famous for is usually not helpful[0]. That doesn't make him an awful maintainer, though, it just makes him a human being with large but finite amounts of patience. [0] Though who knows -- perhaps there are cases where the blow-up was what finally got the point across to the person who thought they were being helpful but weren't really. In that case, the blow-up was perhaps a crude tool, but got the job done. Difficulties arise largely due to cultural differences, keeping in mind that "old-school kernel development" is a culture in itself that deserves to be treated with some respect.

pessimizer 6y ago
The thing about Torvalds for me is how long and explanatory his negative reactions were. He wouldn't just blow-up, he would explain in an abrasive manner exactly why he thought discussing this thing was a waste of his time. It was obviously a tactic (if subconscious) to get people to hesitate before proposing something he would think was obviously silly. I think it probably worked; the criticism of his responses were that they were unnecessarily personal and hurtful, not that they were wrong. I can also see why he backed away from it. If you're going to hurt people's feelings, best to do it through intermediaries so you don't get stained.