Hacker News Reader

Comment by mjw1007 | Hacker News Reader

When I file a bug report, I often feel I would like to add a disclaimer, along the lines of:

« I'm filing this bug report because I found a bug. This isn't a complaint that the bug exists, or a suggestion that you prioritise fixing it, or a support request asking for workarounds. It's just a report that the bug exists. »

But I think actually writing that would come over as rather snotty. Maybe the right thing is to write a post somewhere on what I think is the right attitude for filing bug reports, and discreetly link to it.

View on HN

Is this really necessary?

If I post a bug report like "when I run command X, there's a crash", how many OSS authors get annoyed?

If anyone gets annoyed at that, this is a sign they need to take a break from the project (or from the bug database), not a sign that the bug reporter needs to do anything differently.

It depends on the maintainer.

There are some projects I've submitted issues for without such excessively fluffy language, and the maintainer has responded very negatively. I hate this, because it makes the maintainer look like a cantankerous prick, and it also puts me off using what might be a great project (and of course others will read it to).

IME, if I'm not familiar with the maintainers' temperament, I'm most successful using something like this template:

"Hi! First let me say how much I appreciate this library, it really helps with X.

I've found what I believe is a bug, whereby X (provide logs, stack trace, whatever is relevant).

You can reproduce this by X (provide repro steps or code snippet as appropriate)."

For projects I'm familiar with, things can be more business-like and to the point, and I can also offer to send a PR.

I like your approach. As a maintainer of small projects with very few users I'm not offended by business-like bug reports. But it's very nice to hear someone is actually grateful for my software. (You only need one arrogant asshole demanding support to feel like your software is shit and maintenance is a burden.) Of course you only need to make a good first impression once.

This approach will also help if another part of your message comes off as arrogant. That can happen when English is not your native language.

Meanwhile this kind of dancing around the issue will piss me off, though I don't usually respond so.

If there's a bug, tell me what happened, what you expected, what your config/environment looks like, and if it's a library a minimal code example that triggers the bug.

I don't need to hear about how your grandmother's favorite chili recipe saved your uncle's best friend's life when he was trapped in the Siberian wilderness after going on the run from the Malaysian government. Just tell me how to make the damn chili.

If you like using my software and it makes your life better in some way, I absolutely want to hear that - it will help keep me motivated the next time working on it feels like a chore.

We love hearing about that in the D forums. But in bug database submissions, just the facts, Ma'am.

P.S. I have several letters from Empire users who reported that the game caused them to flunk out of college and/or get divorced. I'm not sure if they were complimenting or complaining :-/

I think the thank you messages could be separate from the bug reports (which should be sterile and 100% tonally neutral). One possible way to separate it is to have thank you messages on twitter. It will also help promote the project, where as these messages in bug reports will get buried and lost and no one else is gonna see it.

Thank you, if I had expressed it this way I don't think I'd have riled as many feathers but this is exactly my stance. (apart from specifically Twitter)

I take your point, and I wouldn't want to read through reams of frivolity either - but there really wasn't anything like that in my example; it's 1 or 2 like saying "thanks", and then my example included all of the stuff you asked for.

Yeah, there's a difference between sharing your life story and a quick thank you, and if I have to take into account people who get offended by being thanked, then I wouldn't be able to communicate at all anymore.

You can't please everyone, and erring on the side of being too polite on average has worked pretty well so far for me.

Yeah it was probably an unfair segway into a pet issue of mine, sorry.

Allegedly search engines rank the story higher than the recipe by itself. But that doesn't extend to bug reports.

> I don't need to hear about how your grandmother's favorite chili recipe saved your uncle's best friend's life when he was trapped in the Siberian wilderness after going on the run from the Malaysian government. Just tell me how to make the damn chili.

The template given was nothing like that, at all.

Regardless, I firmly believe that this attitude is keeping many people out of the tech business, let alone open source. Society shows that niceties are wanted and work, especially by women, a demographic under-represented in most parts of tech. I also find that not showing niceties is a display of dominance and self-importance, again, something that isn't going to bring more people into tech.

I can give a pass to Linus Torvalds and those under time pressure. I doubt any of the devs here commenting on HN are able to make either of those claims.

> The template given was nothing like that, at all.

That's fair, I waded in to discuss a related pet issue and it's probably not fair to have posted the way I did.

> Regardless, I firmly believe that this attitude is keeping many people out of the tech business, let alone open source. Society shows that niceties are wanted and work, especially by women, a demographic under-represented in most parts of tech. I also find that not showing niceties is a display of dominance and self-importance, again, something that isn't going to bring more people into tech.

Let's start with the part where I said "though I don't usually respond so." It irritates me, but I tolerate it because my goal is to help people.

As for not having space for stories/niceties driving away women, I don't walk into the emergency room and think "man, this is a sausage fest". Usually there are vastly more women working there than men. Yet from discussions I've had with people who work in that area this is a common frustration there as well.

"You're bleeding, I don't need to hear about how depressed you've been since your grades are poor, fast forward to the part where you slipped while drunk and fell onto a broken beer bottle so I know what kind of treatment to administer." That's a made up example but is actually less ridiculous than the actual examples I've heard.

I'm not saying to leave out relevant details, but when you're bleeding or have broken bones or your left side is going numb, just tell the doctor the facts, as concisely and as clearly as you can.

If you want to tell stories, go to your primary doctor when you're not facing an emergency. Or, and this is not dismissive so please don't interpret it as such, go to a therapist, or a councilor.

A bug report on an issue tracker is obviously not life threatening in the vast vast majority of cases, but it's the same idea. It's where you go when things are broken, so tell me what's broken and the relevant context.

If you want to give thanks or talk about what you like or how you get value from the project or whatever, there are other venues for that and I encourage you to use them. Or put it at the end of the issue thread after the problem is at least identified. I've never been upset at someone for clearly expressing the problem and then saying thanks when I fix or acknowledge it.

EDIT:

> I also find that not showing niceties is a display of dominance and self-importance, again, something that isn't going to bring more people into tech.

It takes some serious mental gymnastics to turn a focus on helping people as quickly as possible into "a display of dominance and self-importance". I'm specifically asking people to not kiss my ass about "how much this project helped them during a dark time in their life" or whatever so I can get to the root of the problem they're encountering and resolve it.

It's incredibly bad faith to claim that trying to be efficient with my volunteered time so I can help as many people as possible is an attempt to dominate the people I'm helping. Frankly this sentence makes me question your motives here. Had I taken this sentence in earlier I wouldn't have responded to your post at all.

Yes, get rid of the niceties when you're under the kind of time pressure and situation you might find in an emergency room and you're bleeding.

Otherwise, use them. Does your development time resemble the conditions above, or is it more like you sitting at a keyboard in a nice room with a coffee reading comments on the internet?

As to an emergency room not looking like a sausage fest, the stats don't back you up. From [1]:

> The study's lead author, Remle P. Crowe, a research scientist at ESO – an emergency-medicine data company based in Austin, Texas – says she wasn't particularly surprised by the results, which culled data on graduates of EMS training courses as a proxy for likely diversity in the upcoming workforce. A former emergency medical technician, Crowe says the profession has long struggled to attract minorities and women, and previous studies have shown similar outcomes.

There are plenty of numbers given in the article that show low numbers of women among emergency room staff.

[1] https://www.usnews.com/news/healthiest-communities/articles/...

> Yes, get rid of the niceties when you're under the kind of time pressure and situation you might find in an emergency room and you're bleeding.

Again it's my fault, I brought up storytelling and was complaining about that. I'm not upset at the word "please" or something. Your posts keep saying niceties and my posts keep saying stories, which makes me think either you're not hearing my repeated admissions of sidetracking or you're intentionally pushing an agenda.

> > That's fair, I waded in to discuss a related pet issue and it's probably not fair to have posted the way I did.

Was my wording there.

> As to an emergency room not looking like a sausage fest, the stats don't back you up.

As I understand it emergency rooms work with EMS but most people in the emergency room are not EMS. If those stats do extend to the E.R. workers then I wonder whether my local E.R. does something different or if it's purely chance, but I'd estimate 70% female at least.

Either way the point was an analogy. Bug reports are for the bug details. There are other venues to talk about how much this leftPad library changed your life. That's all I'm trying to say.

It's very strange how in this thread maintainers who prefer ass kissing are egotistical and dominating, and maintainers who don't require ass kissing and would be more comfortable if you left it off are also egotistical and dominating. Is the message you want to convey simply that I should not volunteer my time to helping people?

This is what you responded to, this is what is being advocated.

> "Hi! First let me say how much I appreciate this library, it really helps with X.

When I, or anyone else in this thread advocates for adding a life story into a bug report or the like, then you can bring in your stories about stories and it'll be relevant.

> Is the message you want to convey simply that I should not volunteer my time to helping people?

Quite obviously not, it's that you should stop comparing yourself to those in life threatening, intensely time pressured situations and try to be more pleasant to those you're responding to, not trying to find excuses around doing so. You work in a pleasant environment, with low pressure, and are well rewarded, you definitely have the time to be well mannered.

> maintainers who prefer ass kissing are egotistical and dominating

It's not about "ass kissing" but basic respect, and if you wanted to provide an example of how not to exercise restraint and apply any semblance of etiquette, that would be a good one. Do you ever wonder why development is a "sausage fest" instead of the emergency room?

Speaking of basic respect, when someone admits to a mistake several times in a conversation and says explicitly "I waded in" and "it wasn't fair [of me]", repeatedly focusing on berating them for that mistake is not very respectful.

It shows that you are not listening to understand, but to find argumentative points. If you're truly concerned about dominating behavior that drives people away, I suggest you start with your own communication. I've been there myself, and I slip up quite often, so don't take this as judgement, only advice.

> Speaking of basic respect, when someone admits to a mistake several times in a conversation and says explicitly "I waded in" and "it wasn't fair [of me]", repeatedly focusing on berating them for that mistake is not very respectful.

We go from a grandmother's chilli recipe in an issue and end up with a comparison using bleeding patients in an ER. That's not someone apologising for a mistake and correcting, that's someone trying to wriggle around easily challenged and fantastical statements used as excuses. What next - are we airline pilots trying to save a plane with 3 failed engines while children selfishly ask for a tour of the cockpit?

I want to add, as an OSS maintainer myself, I don't put the blame for attitude solely on the kind of maintainer I mentioned. It's very common to get get users using demanding, demeaning or ungrateful language, and that type of thing does wear on you.

> There are some projects I've submitted issues for without such excessively fluffy language, and the maintainer has responded very negatively.

You are only responsible for what you say and do, not how someone else chooses to react. If you provide a bug report in good faith, and don't act entitled or snotty, you've done your part, and have behaved within the terms of the implied social contract. If the maintainer chooses to react in an unwarranted manner, that's on them, and I think that sort of bad behavior should be exposed for others to see.

Personally, as a maintainer, I find that unnecessary fluffy language makes it harder to get to the meat of the problem, and it annoys me. If you're risking a bad reaction either way, why not choose the way that's objectively the most helpful?

I think stating a bug matter-of-fact-style is fine, personally. As long as there isn't a negative tone, I don't think you need the introduction. "Tried this, expected this, got this", with a title containing a clear summary.

I've created and maintained some libraries, and I think if a library maintainer takes issue with totally neutral, fact-stating bug reports, that's entirely on them. If you're stating nothing but the technical details, there's really no implied sense of entitlement or bitterness. Maybe it comes across as cold, but it's an issue tracker, and posting issues is the point. It fits the context.

For some people their code are like their kids; precious and they can do no wrong. These tend to be a problem when bugs crop up, because bug reports are like a personal insult to them.

Personally, I've long held the view that practically all code is buggy one way or another and that many things can mean throwing code away is the best way forward, so one just shouldn't be attached to a few bytes. One should rather feel attached to the project at hand, which then naturally results in one trying to improve it, which means bug reports are GOOD and EXCELLENT because they give very clear hints were the project can be improved.

I think it's also that people don't like feeling stupid, and most bugs are stupid mistakes, so having one pointed out can make you feel stupid.

If you've got tests then you've already seen how many stupid mistakes you make, long before release. To get that far and still not have learnt enough humility to accept there may be more is quite the achievement!

Catching a bug while testing is clever. You wrote a good test. Getting a bug report is stupid. You made a mistake, didn't catch it while testing and actually published it for others to see how stupid you are.

Do you know of a single programmer who has written a program of any but the absolute lowest complexity that is entirely bug free upon release?

Yes, I'll claim that such programs do exist. But it's rather hard for a human to notice those; beware of survivorship bias.

Having said that, I still support the sentiment that most code is buggy. It's futile to expect pervasive perfection.

I didn't mean imply that releasing buggy code was stupid. This happens, of course it does. And it not necessarily stupid

I was trying to give a reason why people, myself included, don't learn the humility you refer to.

I see, thanks for the clarification and my apologies for assuming the worst - maybe I've come to expect the kind of hubris I thought you were displaying because, all too often, programmers actually do display it. Just the other day I had one comparing himself to a doctor in an emergency ward, heroically saving bleeding victims, because he deigns to contribute to open source. This justifies treating the writers of bug reports with disdain, of course.

Nice to know it's not endemic!

> These tend to be a problem when bugs crop up, because bug reports are like a personal insult to them.

I got over that a few decades ago.

> bug reports are GOOD and EXCELLENT because they give very clear hints were the project can be improved.

Absolutely. And fixed bug reports go into the test suite so they never darken anyone's door again.

> For some people their code are like their kids; precious and they can do no wrong. These tend to be a problem when bugs crop up, because bug reports are like a personal insult to them.

Maintainers that have that attitude just shouldn't have public bug trackers that anyone can submit to. If they choose to do so anyway, and react poorly to legitimate bugs that are respectfully presented, that's on the maintainer, not the reporter.

It's "natural" to feel this way - that the product is "yours" somehow.

But it's smarter to realize you don't own the software; you own your skill at making software.

Viewed this way, every bug report is an opportunity to improve your skill.

I've been yelled at for reporting what I saw as a bug (coz I thought the behavior was bizarre and unexpected) and the author saw as a support request (coz he saw it as expected).

Another common pattern is this "no man's land" of bug responsibility between projects. Project A interacts with project B and that interaction causes a bug or awful problem. Project A and B both wash their hands of it.

I don't particularly mind support requests via the bug tracker - particularly since a pattern of support requests often highlights a UX issue or a lack of clarity in the docs.

Some people view them as irritating annoyances that should be pushed to some forum like stack overflow though.

> Some people view them as irritating annoyances that should be pushed to some forum like stack overflow though.

I maintain a fairly large open source project. We close "issues" that are support requests on sight, with a more-or-less automatic message telling the person that they should use Stack Overflow or Gitter for questions.

This is not because they are irritating annoyances. I in fact do support people on Stack Overflow and Gitter about the project. But there are at least two reasons for keeping things separate:

a) In terms of organization, I need the issue list to be about things that are actionable in the repo.

b) More importantly: only the core developers and some very enthusiastic people follow the GitHub repo. There are many more people available for and willing to support on Stack Overflow and Gitter. It is important that support requests reach these people so that support can be distributed. A lot of users even have more practical experience with the project than the core developers.

Personally, I don't like Gitter or Slack as I find them much harder to search or find already answered questions. Stack Overflow works very well though, a question-answer format is perfect for support requests. Its also much easier to search or link to. I think that Github issues feel closer to that for many people.

Its also important that the project clearly specifies where to ask for help. I'm often reluctant to open issues that aren't bug reports, but the project isn't clear where I should ask.

I wonder if it would be beneficial if github added a support forum to each repo, though having to deal with spam may turn into a major overhead. It would give the opportunity to contribute to a project to those with less technical skills and all the information would be in one place. Gitlab and other products may already have this, I don't tend to use them.

GitHub has "Discussions" on the way[1] which seem like they will greatly help the situation. You can see one in action here[2], which is where I first saw it. Doesn't seem to be generally available yet though, but when it is, I think it will improve issues greatly.

[1] https://github.blog/2020-05-06-new-from-satellite-2020-githu...

[2] https://github.com/clap-rs/clap/discussions

Fantastic, thank you. Should have known better than to think it wasn't on the way eventually.

The worst is when project B is a closed source project. I have such an open-source project A that interacts with such a project B. That is the worst. Then I get a bug report, project B got a new version and your project A does not work anymore. Fix it! Then I ask what was changed in the new version of project B. Then they say, they do not know. Then I ask the company of project B. They do not respond. Then I get another email from a user, you need to fix it for the new project B version. Then I send 5 emails to the company of project B. Then they respond, "we do not support project A". And I do not have access to project B myself

Not me. I appreciate bug reports and the time the submitter took to post them. Even if they aren't clear enough for me to find the problem, someone else may run over the bug, too, and having multiple inadequate submissions often provides enough clues that we can fix the problem.

No need to stroke our egos, just the facts is just fine.

If that's actually what you wrote, I would be annoyed as a maintainer. There's an implied assumption here that "command X" was never tested and must therefore crash for everyone. In 99% of cases, "command X" runs without issue and has been tested on multiple configurations. If it turns out that "command X" crashes for you because your company's IT department misconfigured the certificate authorities on a particular Windows build image, you end up wasting massive amounts of everyone's time. After maintainers get burned by these kind of bug reports tens of times, they understandably get hostile to such low effort bug reporting.

If that's how you react, then you're a part of the problem. If someone opens a bug report that factually represents behavior they've seen, and provides supporting evidence and information, and you react that way, you should probably re-examine your world view and think hard about why you believe that everyone is out to unfairly criticize your work.

> If it turns out that "command X" crashes for you...

As a project maintainer, I hope you recognize that people will run your software on all sorts of hardware and software configurations that don't match how you've tested it. It's impossible for you to test all possible scenarios. Requiring that every potential bug reporter explicitly acknowledge that their issue might be unique to their particular setup in order to assuage your apparently-fragile ego is unreasonable and counter-productive.

What I had in mind was that "X" included all the relevant parameters. An actual runnable command, not just the name of a program.

So if I run the same command with all of the parameters you specify and it works correctly, I can close your issue as non-reproducible, right?

Sure, as long as you're polite about it (and it would be incumbent on the reporter to be polite as well). It's not your responsibility to help users debug. If you do that often, for issues that are actually more widely reproducible, your software might end up getting a reputation for instability. Whether you care about that or not is up to you.

That is up to you. Different people/projects have different standards for how much effort they put into a bug.

If you think the issue is unlikely to be an actual bug, that would seem like the correct course to take. If you suspect it might depend on other details and you're keen to investigate more, you could ask for more details.

One related thing that many projects do is to have a bug template that asks for details such as software versions, operating system, CPU, etc. This can help a lot in reproducing bugs.

> So if I run the same command with all of the parameters you specify and it works correctly, I can close your issue as non-reproducible, right?

Depends how you want your project to be perceived.

If you don't give a crap, and just want to close issues then sure. ;)

If you're interested in finding out why the bug is occurring in such a strange way, and potentially solving the problem... then working with the user to figure out the cause (whether it's their fault or not) is going to be more useful. :)

If you're the only maintainer of your project though, and it happens a lot then personally I'm not sure what the right approach is.

The projects I'm involved with do have it happen, but it's not that often. So we're not too burned out by those things.

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.

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.

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.

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.

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.

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.

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.

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.

1. https://wiki.lesswrong.com/wiki/Least_convenient_possible_wo...

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

> Netscape's corporate strategy doesn't seem relevant here.

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.

1. https://hyp.is/de25lAXAEeuhNEN0wan1Ww/news.ycombinator.com/i...

I agree with some of your observations and ideas, btw. But I have to wipe the antagonism off my screen with a strong disinfectant to appreciate them.

This comes to mind: https://news.ycombinator.com/item?id=24674099

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

> This comes to mind: https://news.ycombinator.com/item?id=24674099

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

1. https://pchiusano.github.io/2014-10-11/defensive-writing.htm...

Adding workaround if you know one is just good practice IMO. Out helps prioritization too.

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.

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

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

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.

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.

That's an interesting distinction. It's like simply documenting that a bug exists versus arguing that a bug exists and should be resolved.

The latter feels similar to making a feature request, which can also be done in Issue trackers like GitHub Issues. Maybe the fact that both the former and the latter are allowed/encouraged to exist within the same tracking systems somewhat contributes to the confusion/conflation of the former with the latter.

As an OSS maintainer, for me it is not snotty, but also not necessary.

My biggest issue are people that come and leave comments like "why isn't this fixed yet?", or thumbs down my response that I'd appreciate some help fixing it, or adding the feature.

My preference is usually: ‘hi, thanks for creating this tool/library/whatever. It really makes a meaningful difference in my life. I’m encountering a problem with the blah blah module, which you can repro thusly.’

Don’t grovel, but also acknowledge that the only compensation the reader of the report is likely to get is in the form of these extremely rare moments of gratitude.

I should also mention that I maintain an open source app that gets used by the public, and is regularly confused by them with being a product of a group of paid individuals. In fact, they usually think the software is a result of their tax dollars at work. I’ve received a lot of really negative, shitty feedback from all sorts of people, including folks in the software industry (shout out to everyone who ever emailed me from their Amazon.com work addresses). Don’t be like these people. The ones who start by simply saying “thanks” not only get more from me, but also help keep my motivation up.

> Don’t grovel, but also acknowledge that the only compensation the reader of the report is likely to get is in the form of these extremely rare moments of gratitude.

As I write elsewhere, this is a fundamentally flawed mindset. A high quality bug report is the reader's compensation. It's a goddamned gift. The presumption that the reporter is a leech and the recipient is the one being leeched is exactly what's wrong in the culture.

Consider this: You post your project. I'm not in the target demographic. But because I come from the culture epitomized in Shirky's Here Comes Everybody, and not the fucked up culture of the GitHub generation, where 999 times out of 10 you only reach out to someone because you're trying to get something from them, I decide take the time and give it a look anyway. Going into this, I already have nothing to gain. So I do look at it, and I spot a bug. I file a bug report with steps to reproduce. This is a contribution to the project, its maintainer, and whoever uses it. Do something with it, or don't. But no matter how you respond, I will get nothing out of it. To flip things around in a Costanza-like attempt to grab the upper hand is... anti-social.

This isn't to say that leeches don't exist. But muggers also exist. And yet, the fact that muggers exist is not a good reason to go around socking people in the mouth when they approach you and start speaking.

OK, I'll say it differently, don't be an asshole.

Don't be an asshole submitting a high quality bug report.

Don't be an asshole submitting a low quality bug report.

Just don't be an asshole.

> But no matter how you respond, I will get nothing out of it.

Well, you get a problem solved. One that was probably bothering you or stopping you from doing some work.

Otherwise I agree, though. Gratitude is nice, but a well-formulated and described bug reports are the best. (PRs are a mixed bag, because it's rare to have a full match with the current design).

> Well, you get a problem solved. One that was probably bothering you or stopping you from doing some work.

You ignored the entire premise. Weird, because I repeated it multiple times. (And I don't understand how the comment can even make any sense unless you get the premise.)

To be clear: the scenario outlined above is one where I'm filing a bug report against a software project that I do not use and do not ever intend to use. There's no way a bug in the software can be showstopper for me if the software in question has no effect on the success or failure of whatever show I'm running.

To be clear: the scenario outlined above is one where I'm filing a bug report against a software project that I do not use and do not ever intend to use.

I think your premise is specious. Who files detailed bug reports on a piece of software that they have never and will never use?

What is the scenario where someone would bother doing this?

What is the scenario where they even have the knowledge to file this detailed bug report since they lack any context on the software in question?

I do this all the time. Sometimes I even send in patches too.

I already answered this, but maybe you missed it:

https://hyp.is/cS034gX1EeutOzMchaO06A/news.ycombinator.com/i...

That you're here having trouble grappling with the suggestion that such a scenario is even plausible is evidence of the cynical depths we've reached. Even in the case that you're unable to understand why, does the "why" really matter? It happens, and that's what matters.

That seems unnecessarily rude. Also, you still haven’t offered up a plausible scenario of why you would magnanimously look at my OSS project that you have no intention of ever using, find a bug, and submit a bug report, exhortations of circa 2008 Clay Shirky notwithstanding.

> That seems unnecessarily rude.

Am I supposed to refrain from being seen as unkind to someone tacitly accusing me of lying? I gave an answer before you ever even asked the question. I don't know what you want, I don't know why you think you deserve my time and energy in light of the incoming rudeness directed my way, and I don't know how you can't see that expecting it is in stark contradiction to the position you're taking.

I don’t think I’d want to receive one of your magnanimous bug reports. Hope you have a good night.

"So I'm afraid that I am going to have to break up with you". Really seized the upper hand there, Costanza.

https://hyp.is/9rn9dhDOEeum9XvjucTYqw/news.ycombinator.com/i...

https://www.youtube.com/watch?v=887bIe0hXyc

> Hope you have a good night.

I somehow doubt your sincerity. Go fuck yourself.

Sincerely, from me to you.

> You ignored the entire premise.

Yeah, seems so. I've re-read the original message now.

Here are two thoughts for your consideration:

- This is a discussion about FLOSS projects' lives and their maintainers' experiences. Given that your approach is an outlier, your observations don't have a lot of relevance to an average FLOSS project. Nor, as a consequence, does the opinion of "who owes who".

- Consider, in abstract, two projects. One has only bug reports from actual, motivated users. Another has 10% of bug reports from its users and 90% of "drive-by" bug reports. Starting with a certain size, I think you can imagine how the second project might have the maintainer overwhelmed, unmotivated, and/or spending a lot of time on code that is almost never run in production.

Software is not math; there are always parts that are more used, and always some bugs that are ignored because they're non-trivial to fix, and the tradeoffs are not worth the developer's time. Unless you're DJB, I guess.

This comment is rewriting the premise again.

> This is a discussion about FLOSS projects' lives and their maintainers' experiences.

It's not. It's rooted at mjw1007's comment "When I file a bug report[…]" and, before that, the linked article where antirez deals with the same matter that I'm discussing.

https://news.ycombinator.com/item?id=24670700

A later comment—the one that I responded to—tries to convince us to focus on the maintainer and sell the appreciation-as-compensation, maintainers-get-nothing, and, implicitly, the bug-reports-have-negative-value perspective that is pushed in the circles I referenced above. And that's the problem. As I wrote elsewhere, filing bug reports takes more effort than not filing them. By myopically portraying the maintainer as if they're a protagonist in some Gary Stu fanfic about the world, we end up with a take that fails to consider all the relevant details, and that's the attitude that antirez admonishes. Please revisit both the article and the comment linked above.

(I'm not really interested in responding further to this conversation.)

I usually flip this around -- report the bug as straightforwardly as possible, and then sign off with a statement of gratitude (usually paired with "let me know if I can provide any more information on this issue"). To me it feels more sincere and less likely to be perceived as trying to preemptively apologize for the bug report.

>In fact, they usually think the software is a result of their tax dollars at work

That's amazing. Perhaps it's reality that's wrong.

Woulda, shoulda, coulda.

Deciding how to phrase contributions is a surprisingly tricky problem, and in fact I think that the way a contribution is written can (to some degree) demonstrate the author's level of understanding and appreciation of the project and community's time commitments.

Some projects have extremely high issue volume, use their own automation/triage, and prefer very terse communication -- and in those cases it may make sense to include only the minimal details required.

In other cases a hobby or community-building project (for example) might prefer more informal and friendly communication.

Either way, the author's phrasing isn't the only factor that matters in each situation. The relationship also depends on the project/community responding effectively.

We're all human, we all make mistakes, and English is not everyone's first language, so a well-run project should afford for those (while also being cautious not to get completely sidetracked dealing with noise).

As an OSS maintainer (of small projects), I don't really care how someone words a bug report, as long as they aren't rude or demanding. In fact, I'm actually happy if someone takes their time to report a bug. Your imaginary disclaimer would feel a bit weird indeed. But as other people have mentioned, a little “thank you for the project“ never hurts :-)

If you would mean it, I think it's nice to instead sign off the bug report with something like this "X is great, and thanks a lot for developing it" - when you're reporting something to a project where you are not previously known.

When I receive bug reports, I usually review it and tag it but won't come back to it until I have time. I won't bother spending time on fixing it if it's not something I'm actively using. If someone submits a PR with a fix then that's great and I'll most likely merge it in if there's no objections and tests still pass. I don't perceive the submissions as if the person thinks they're entitled to getting it fixed since majority of the time they're nice about it or they never come back to check on the status. When I submit bug reports and PRs to other projects, I have no expectations that it'll be fixed or merged since I understand what it's like to be on both ends.

Probably best to just have more articles about the topic -- like the one currently under discussion -- and more discussions of the sort happening right here. Create a culture where some fairly big percentage of people have a healthy attitude towards their open source stuff, understand they don't have to do anything if they don't want to, people talking at them about it is a form of engagement with a lot of positives, etc.

And then make peace with "You can't please all of the people all of the time. Some people can't ever be pleased. etc."

Seems to me the best thing is to make it as easy as possible for the maintainer (clear, with environment and steps to reproduce). The majority of maintainers want to iron out any bugs they have and the more of a checklist item the report is the happier they are going to be. It’s the GitHub ticket comment spew of “I have this bug too! fix this shit now!” that really wears people down.

Gauging demand can sometimes be useful in planning a project can it not? I mean, if the comments are phrased nicer than your example.

On several bug trackers there are structured ways to make it known without commenting. On GitHub, at least there's thumbs-up reactions.

I think this depends on the quality of the bug report or the following dialog.

Answers like this should have this disclaimer: https://i.imgur.com/p76JlUk.png

Bug reporting should be about facts, cold hard ones and not about feelings or comments. Stay on topic, explain what you did and if you also link to a video showing the bug occurring don't comment during video. Just show the steps to reproduce it. Or if the bug happens on a particular architecture then also show that one as well and that should be the end of it. The developer needs info how to replicate it not reading a novel or entering a debate. I hate stuff like cheesy comments or mean ones. KISS is paramount in this case.

I think this is a wonderful idea, but you’re right that maybe it could be rephrased. How about a concise, straight-to-the-point bug report followed by this at the end:

> Thanks so much for this great project! I hope you don’t think I’m complaining, just thought you might want to know about this bug. Cheers.

Reply on news.ycombinator.com