3 ms·
> 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
by 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 agoI 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...
- jlokier 6y ago> 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.)
- 6y ago
- watwut 6y agoAdding workaround if you know one is just good practice IMO. Out helps prioritization too.