13 ms·

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 c

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.

tenkabuto 6y ago
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.
kzrdude 6y ago
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.
FartyMcFarter 6y ago
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.
- pydry 6y ago
  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.
  - sjrd 6y ago
    > 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.
    - dkersten 6y ago
      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.
      - retox 6y ago
        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.
        dkersten 6y ago
        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-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/ https://github.blog/2020-05-06-new-from-satellite-2020-githu... [2] https://github.com/clap-rs/clap/discussions https://github.com/clap-rs/clap/discussions
- GordonS 6y ago
  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.
  - GordonS 6y ago
    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.
  - reificator 6y ago
    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.
    - GordonS 6y ago
      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.
      - 6y ago
- formerly_proven 6y ago
  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.
  - aidenn0 6y ago
    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.
    - brigandish 6y ago
      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!
      - KSteffensen 6y ago
        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.
        brigandish 6y ago
        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?
        memorysafety 6y ago
- deleted 6y ago
  [deleted]
- rmrfrmrf 6y ago
  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.
  - FartyMcFarter 6y ago
    What I had in mind was that "X" included all the relevant parameters. An actual runnable command, not just the name of a program.
    - rmrfrmrf 6y ago
      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?
      - djur 6y ago
        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.
      - FartyMcFarter 6y ago
        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.
- WalterBright 6y ago
  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.
franciscop 6y ago
As an open source maintainer, and from what I've seen in general, there's absolutely no problem with reporting a bug! Do you mind me asking why you feel like adding that disclaimer? Is it because you don't want to seem demanding? What is the goal of "just report that the bug exists"? The main/only major problem I've seen with bug reports is when it's actually user code, so if you can show why you are certain that it's the library's code that is buggy that's best. If you can prove it with a code snippet, perfect. If you can point to a specific place of code and explain why it doesn't work, perfect. Or just explain exactly what happened. TBH, as long as you are just not be like "my code doesn't work fix it" you should be mostly fine. > Note: exception if the package is marked as e.g. "unmaintained" or such > Note: there might be some truly awful OSS maintainers, and some are infamous for it (e.g. Linus); but in my experience it's very very rare to find a negative reaction to a helpful PR.
- mjw1007 6y ago
  The goal of filing a bug is to help the project. I've had cases where I've filed a report saying something like "if I enable both A and B, the log messages disappear", and the maintainer has responded with "Why do you need both A and B? Could you use A and C instead?". That's a waste of time for both of us. If I want to ask someone about the merits of B vs C I'll find somewhere better than a bug tracker.
  - cpuguy83 6y ago
    A lot of the time people just don't know about some feature or work-around to the problem. That's likely what's happening there.
    - lmeyerov 6y ago
      Yep, or don't know how to use it, or messed up in combining api keys. Not immediate bugs or useful feedback... but I find these worthwhile after playing the "5 why's game". user error -> poor error message -> bad example docs and wonky API for that area -> underserved use case. that's useful feedback!
    - 6y ago
jka 6y ago
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).
cpuguy83 6y ago
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.
pixelrevision 6y ago
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.
- bickeringyokel 6y ago
  Gauging demand can sometimes be useful in planning a project can it not? I mean, if the comments are phrased nicer than your example.
  - noisem4ker 6y ago
    On several bug trackers there are structured ways to make it known without commenting. On GitHub, at least there's thumbs-up reactions.
unnouinceput 6y ago
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.
Gehinnn 6y ago
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 https://i.imgur.com/p76JlUk.png
apeace 6y ago
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.
aaronbrethorst 6y ago
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.
- cxr 6y ago
  > 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.
  - aaronbrethorst 6y ago
spacechild1 6y ago
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 :-)
miguelmota 6y ago
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.
DoreenMichele 6y ago
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."

tenkabuto 6y ago

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.

kzrdude 6y ago

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.

FartyMcFarter 6y ago

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.

pydry 6y ago
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.
- sjrd 6y ago
  > 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.
  - dkersten 6y ago
    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.
    - retox 6y ago
      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.
      - dkersten 6y ago
        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-github-codespaces-github-discussions-securing-code-in-private-repositories-and-more/ https://github.blog/2020-05-06-new-from-satellite-2020-githu... [2] https://github.com/clap-rs/clap/discussions https://github.com/clap-rs/clap/discussions
GordonS 6y ago
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.
- GordonS 6y ago
  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.
- reificator 6y ago
  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.
  - GordonS 6y ago
    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.
    - 6y ago
formerly_proven 6y ago
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.
- aidenn0 6y ago
  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.
  - brigandish 6y ago
    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!
    - KSteffensen 6y ago
      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.
      - brigandish 6y ago
        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?
        memorysafety 6y ago
deleted 6y ago
[deleted]
rmrfrmrf 6y ago
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.
- FartyMcFarter 6y ago
  What I had in mind was that "X" included all the relevant parameters. An actual runnable command, not just the name of a program.
  - rmrfrmrf 6y ago
    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?
    - djur 6y ago
      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.
    - FartyMcFarter 6y ago
      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.
WalterBright 6y ago
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.

franciscop 6y ago

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

mjw1007 6y ago
The goal of filing a bug is to help the project. I've had cases where I've filed a report saying something like "if I enable both A and B, the log messages disappear", and the maintainer has responded with "Why do you need both A and B? Could you use A and C instead?". That's a waste of time for both of us. If I want to ask someone about the merits of B vs C I'll find somewhere better than a bug tracker.
- cpuguy83 6y ago
  A lot of the time people just don't know about some feature or work-around to the problem. That's likely what's happening there.
  - lmeyerov 6y ago
    Yep, or don't know how to use it, or messed up in combining api keys. Not immediate bugs or useful feedback... but I find these worthwhile after playing the "5 why's game". user error -> poor error message -> bad example docs and wonky API for that area -> underserved use case. that's useful feedback!
  - 6y ago

jka 6y ago

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

cpuguy83 6y ago

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.

pixelrevision 6y ago

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.

bickeringyokel 6y ago
Gauging demand can sometimes be useful in planning a project can it not? I mean, if the comments are phrased nicer than your example.
- noisem4ker 6y ago
  On several bug trackers there are structured ways to make it known without commenting. On GitHub, at least there's thumbs-up reactions.

unnouinceput 6y ago

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.

Gehinnn 6y ago

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 https://i.imgur.com/p76JlUk.png

apeace 6y ago

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.

aaronbrethorst 6y ago

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.

cxr 6y ago
> 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.
- aaronbrethorst 6y ago

spacechild1 6y ago

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 :-)

miguelmota 6y ago

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.

DoreenMichele 6y ago

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