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.
> 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.
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.
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.
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.
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.
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.
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.
> 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.
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.
> It's supposed to contain a list of known defects or it isn't.
If it were just a list of defects, this discussion wouldn't have started.
By "informational" I mean reporting that a bug exists. "When I do X, Y happens and Z should happen instead. You might like to know. Best wishes.".
By the other kind, I mean asking for a solution. "When I do X, Y happens, please make Z happen instead. Await your prompt reply, Kthx".
Often there's no way to tell which one is intended. A tick box to differentiate between "I'm just reporting this, I don't need the change" versus "I would find a solution useful" or even "can someone specifically help me find a solution" seems like it would be helpful.
These are different kinds of bug report, and they all land in a typical GitHub-style or Bugzilla-style public issue tracker.
The second kind are not defect reports, and we haven't even mentioned feature requests, which aren't defects at all. They land in the issue tracker as well.
> You're strawmanning
Hmm, maybe I should rephrase to clarify where the emphasis was intended: "If I submit a bug report and the maintainer replies thinking I wanted something from them, it would be silly for me to become infuriated because my effort seems wasted". That addresses the scenario in the comment I replied to, so not a straw man.
> where people have responded in genuinely obnoxious
Obnoxious is not in the comment I replied to. You've projected that. The maintainer in that scenario may have replied politely. The only issue under discussion was the submitter's reaction to a maintainer thinking the submitter wanted something.
Are you sure you're not strawmanning and counterfactualising?
> This is nuts. This can only be true if there are much, much bigger problems afoot.
Well, it's true. Yes there are problems. That's why this discussion is taking place. Do you have solutions?
> Most of this was figured out years ago and opened up to the public under Netscape. Folks abandoning or ignoring those lessons [...]
And these lessons are? If you think it's nuts, it would be nice if you were to offer useful solutions.
I was around when Netscape opened up. No solutions leap out to me arising from that, then or now. Netscape's own lessons appear to be about corporate management and control of projects.
The vast majority of open source projects, especially those where people report feeling burdened, are run by unpaid people in their spare time (or when they should be sleeping), as one-person projects. Netscape's corporate strategy doesn't seem relevant here. (And ESR's "Cathedral and the Bazaar", which was related to Netscape's changes, doesn't provide a solution either.)
> If it were just a list of defects, this discussion wouldn't have started.
This makes for the second time this week I've run into someone stating the obvious and thinking that it makes for a point in their favor and not one against their end of the argument.
> Obnoxious is not in the comment I replied to. You've projected that. The maintainer in that scenario may have been replied politely. The only issue under discussion was the submitter's reaction to a maintainer thinking the submitter wanted something. Are you sure you're not strawmanning and counterfactualising?
Yes, I'm sure, and I don't really have time or the wherewithal to explain in depth to someone who's dead set against not understanding. "The maintainer in that scenario may have been replied politely" is simply not a move that's available to you. There is no "may" when we're discussing _actual_, _concrete_ events and not hypotheticals. (Even in the case of hypotheticals, it's a problem—counterfactuals are not an argument unless the argument it opposes employs the universal quantifier; failure to understand this is a failure to understand the difference between what it means to say "∃x" and what it means to say "∀x".) There is only what did or did not occur (or what is or is not posed). To repeat: it is not your job to imagine the most convenient circumstances that would weaken the side that you're arguing against.
> And these lessons are? If you think it's nuts, it would be nice if you were to offer useful solutions.
I've offered them. Go back and read my comments in this thread and you'll see them. Read your own comments—it'll suffice to read just what you've written in this one—and the solution follows naturally from the problem you describe. If it's so hard to discriminate between "informational bug reports" and support requests, then stop mixing them. If you're going to run a bugtracker, then run a bugtracker[1].
You're right. So I don't know why you focused on it at length, as if you can talk your way into it being the thing that I was referring to. Once again, a move that's not available to you.
> There is no "may" when we're discussing _actual_, _concrete_ events and not hypotheticals
We're not.
I replied to the comment I replied to, nothing else, and it describes a hypothetical, so the reply does too.
> counterfactuals are not an argument unless the argument it opposes employs the universal quantifier; failure to understand this is a failure to understand the difference between what it means to say "∃x" and what it means to say "∀x".
:eye-roll: My job is with theorem-proving software. You can show off knowledge of quantifiers but it's unlikely to impress.
The specific comment I replied to (not the main discussion topic as you assumed) has the informal discourse equivalent of an implicit universal quantifier.
> Netscape's corporate stratgy [...] I don't know why you focused on it [...] as if you can talk your way into it being the thing that I was referring to.
You hand-waved vaguely about "Netscape" and "lessons", giving no direction as to what you meant while insinuating we should all know them. The lack of clue sounded like a communication choice, thus intentional shorthand for "you know what I mean".
That leads a good-faith correspondent naturally to a speculative reply, to which you could politely respond with "no that's not what I meant, sorry for the ambiguity". I think it's unlikely you'll see that as rational, but it's how informal language works, otherwise it's questions all the way down.
You each lob a bunch of antagonistic comments in my direction and somehow expect that you shouldn't have to deal with someone who's bothered in turn and who opts to drag you through your own tedium. You might find that surprising, but you shouldn't.
> unlikely to impress
It was a straightforward rundown of why it was unsound to push the argument you were pushing and your failure to acknowledge that, even after having already pointed it out once before. I truly do not give a goddamn about impressing you. (Although it'd be nice if you reflected on how annoying it has been to carry out this conversation in this way.) This will be my last reply.
> The specific comment I replied to (not the main discussion topic as you assumed)
As _I_ assumed? Who's setting the stage for discourse? It's not you.
> you could politely respond with
Oh, gee. My apologies for inconveniencing you while you're barraging me with a thousand hypothetical tangents that could be true instead of demonstrating the "common sense and ordinary charity"[1] of a "good faith correspondent".
> it's how informal language works
And during the barrage, where your justification for it focuses on the particular way that I worded a restatement of the premise n comments deep, but where I failed to sufficiently qualify it by exhaustively restating all the constraints to affirm that they are, in fact, relevant and in play, you think you're in a position to hand out lessons about "how informal language works". Great.
> You hand-waved vaguely about "Netscape" and "lessons"
Nope. That comes from the comment where I referenced Netscape's triage process for the very first time. It's called an allusion at that point—I didn't make a claim about it, get pushback on it from you, and then handwave it away. And if at that point you want more detail about the thing alluded to, then, yeah, you can ask for it, but if you go on to be as discourteous as to derail with another annoying strawman—after having already been called on it once—then you shouldn't expect me to respond as if I'm dealing with anything other than a bad faith correspondent wasting my energy with the level of tedium you're dragging me into. So, given that, and given how excruciating this has been, I'm not going to deliver those details, nor wrap it in a bow.
Here's some stuff that you can Google if you actually do give a shit about any of this and weren't just looking for some avenue to throw away time as part of a vaguely social activity:
"Life Cycle of a Bug", UNCONFIRMED, INVALID, INCOMPLETE
"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.
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.
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.
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.
>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...
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!
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...
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.
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.