Hacker News Reader

Comment by rmrfrmrf | Hacker News Reader

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.

View on HN

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.

Reply on news.ycombinator.com