4 ms·

Do whatever you want. But if the developer who gave you the fruits of their labour for free proposes a way to report bugs that works best for them, take it or

Do whatever you want. But if the developer who gave you the fruits of their labour for free proposes a way to report bugs that works best for them, take it or leave it, or recommend a different approach in a civil tone if you must. But 'screw you'? Not classy. Also, many Github-hosted projects are critical infrastructure for some people. They will make it as easy as possible for the developer to fix their bugs, if they are rational.

BinaryIdiot 9y ago
> But 'screw you'? Not classy. To be fair that's exactly the tone I read the gist in as well. It seems a bit overly hostile to users who may have questions or suggestions but either don't or cannot contribute code for whatever reason. Emotional comments beget emotional comments.
- robotresearcher 9y ago
  That's very true. But the relationship between developer and user is not symmetrical. I'll give the grumpy developer a pass that grumpy end user didn't earn. Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy. Once you have a few thousand users your inbox is a source of frequent misery.
  - BinaryIdiot 9y ago
    > But the relationship between developer and user is not symmetrical. I disagree. I see them as identical. Yes you're offering a free product but it's still a product, even if you don't want to call it one. The developers are your users. They are the ones using it. But even a developer may not know how your code works well enough to submit a PR. > Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy. Once you have a few thousand users your inbox is a source of frequent misery. For sure but I don't know how you avoid this without also isolating yourself from likely valuable feedback / information. Similar to fielding customer requests for a product a good 96% of the ideas / things customers want are going to be a terrible idea. If I've learned anything from running products it's this: make it as stupid easy as possible for your customers to give you feedback / get ahold of you. When you do that you're going to get an absolute ton of noise but the bits of signal hidden in there can be amazing and you'll be able to directly help those along the way. From there it's learning how to manage the flow of information coming to you and trying not to take the bad personally (which is very hard to do when it's your baby / code).
    - robotresearcher 9y ago
      You are completely right. No argument. It's still nasty to be rude to a developer instead of offering politely worded advice.
      - BinaryIdiot 9y ago
        Fair enough
  - scrollaway 9y ago
    > Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy. Work smart, not hard. If you're getting a lot of support requests (entitled or not), add a paid support option. If you have so much traction already that you constantly have to deal with "hundreds of issues", you're well past the point where you should have done that.
ucarion 9y ago
"I found a bug and you won't consider it unless I phrase it as example code? Screw you, I won't report it then!" This seems like a reasonable thing to think and say. A better alternative to the article's suggestion is to state somewhere that it is very likely your issue won't be considered unless it takes the form of a PR. The maintainers, if they don't want to deal with the bug, will say "could you make a PR with a failing test case? Otherwise I don't have the time to work on this". That way, those who really want the bug fixed have to put in work, but those who just noticed a problem and are kind enough to let the maintainers know can do so easily. Why discourage bug-reporting?
- robotresearcher 9y ago
  I think I covered that in 'recommend a different approach in a civil tone if you must'. It's the 'screw you' that put my back up.
  - Retra 9y ago
    To be fair, that 'screw you' was offered behind a predicate.
    - chc 9y ago
      That doesn't help much, seeing as the predicate is essentially "… if you don't want to do free debugging work for me as well as the free development work you're already doing."
      - Retra 9y ago
        Nobody said you have to actually fix the errors, only allow them to be reported. (Which GitHub makes pretty effortless, as I understand it.) At least then someone might be able to volunteer to fix it for them, especially if it is a serious or common problem.
- dragonwriter 9y ago
  Perhaps most importantly, having the issue there let's some other interested user see it and put the effort in to repro the bug and do the test case or demonstrative example.
BugsJustFindMe 9y ago
> 'screw you'? Not classy. Then, fine, tone police, I'm not classy. I am, however, a FOSS developer who understands the value of non-technical contributions to a project. Know which kinds of bugs don't get fixed? The ones your users never tell you about because you decided to make it hard to report them.
- scrollaway 9y ago
  A thousand times this. Issues are generally a favour your user is doing you and your project. Yes, sometimes they're a waste of time; it's fine to close them if they are, it takes exactly one click to do so. Most of the time however, they're valuable even if you don't fix them: Other devs might see them and fix them for you. In almost all cases, turning issues off is incredibly counter-productive.
- robotresearcher 9y ago
  I agree with your argument completely. Just be nice, and your accurate advice is more likely to be useful. That's all.
  - BugsJustFindMe 9y ago
    > Just be nice, and your accurate advice is more likely to be useful. That's all. https://en.wikipedia.org/wiki/Tone_policing https://en.wikipedia.org/wiki/Tone_policing My advice is already useful. If someone chooses not to take it because they'd rather tell non-technical users to pound sand, then I hope their project suffers for it.
    - robotresearcher 9y ago
      There is an obvious meta comment to make here that I leave as an exercise for the reader.
      - BugsJustFindMe 9y ago
        Nah, you're probably mistaken.
scrollaway 9y ago
Issues are fine. You don't need to tackle them, they're not an obligation - you don't have a contract with your users saying you'll fix their issues. If that's something you want, then say so in your README; corps will always be happy to pay for high quality code and support. Most people freaking out about being burned out by their open source stuff are generally people who don't open source their stuff. Most open source projects, even very good ones, get very little traffic therefore very few issues. If you can't deal with the occasional email once every few months, turn notifications off. > But 'screw you'? Not classy. Saying "Write a test" is essentially saying "screw you". Github has been a blessing, in that it greatly lowered the barrier of entry in filing an issue with a project. It's a blessing for users and it's also a blessing for maintainers if you know how to deal with the influx of issues. Increasing the barrier of entry again is not the solution. When I myself find bugs I'll certainly PR a fix if I'm able to (and have the time); but I often can't. Most of the time, because the development environment is unknown to me and I have no way to even run the tests (if there are any), let alone write one. So asking someone to get involved and up to speed with a project to the point that they're able to do this, before they can even file an issue with a screenshot that says "the padding looks bad on firefox", that's nonsense. It's even more nonsense when this is just a pet project of yours that most people will not care about. IMHO, "this is stuff we do give away for free" is an excuse that's too often passed around. It is always true that projects you push to Github for free come with no obligation to care about it, its issues or the pings and cries for help from your desperate potential users. However, you lose the ability to say you're a good open source citizen and you're "giving things away". A real-world parallel I can make is to the people giving their old/smelly/crappy/torn/bad clothes to charity shops and feeling ever so good about themselves. It's cool you have good intentions, but it's not charity if it ends up in the bin anyway. Disclaimer: 99% of my work is open source and ends up on Github. A bunch of it sucks and when issues come up, I ignore them or write a 10-second close-reply. A bunch of it is good and I actually care about; and if I care about it, I'm not going to turn off issues just to make myself feel better about having an already-perfect project.
cgag 9y ago
This post just seems like it's trying to class-up a screw-you to their users. I'd prefer people just keep it crude like this rather than try to make it sound like it's somehow a nice thing to do.

BinaryIdiot 9y ago

> But 'screw you'? Not classy. To be fair that's exactly the tone I read the gist in as well. It seems a bit overly hostile to users who may have questions or suggestions but either don't or cannot contribute code for whatever reason. Emotional comments beget emotional comments.

robotresearcher 9y ago
That's very true. But the relationship between developer and user is not symmetrical. I'll give the grumpy developer a pass that grumpy end user didn't earn. Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy. Once you have a few thousand users your inbox is a source of frequent misery.
- BinaryIdiot 9y ago
  > But the relationship between developer and user is not symmetrical. I disagree. I see them as identical. Yes you're offering a free product but it's still a product, even if you don't want to call it one. The developers are your users. They are the ones using it. But even a developer may not know how your code works well enough to submit a PR. > Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy. Once you have a few thousand users your inbox is a source of frequent misery. For sure but I don't know how you avoid this without also isolating yourself from likely valuable feedback / information. Similar to fielding customer requests for a product a good 96% of the ideas / things customers want are going to be a terrible idea. If I've learned anything from running products it's this: make it as stupid easy as possible for your customers to give you feedback / get ahold of you. When you do that you're going to get an absolute ton of noise but the bits of signal hidden in there can be amazing and you'll be able to directly help those along the way. From there it's learning how to manage the flow of information coming to you and trying not to take the bad personally (which is very hard to do when it's your baby / code).
  - robotresearcher 9y ago
    You are completely right. No argument. It's still nasty to be rude to a developer instead of offering politely worded advice.
    - BinaryIdiot 9y ago
      Fair enough
- scrollaway 9y ago
  > Fielding a few hundred rude and entitled support requests for your free software can make anyone grumpy. Work smart, not hard. If you're getting a lot of support requests (entitled or not), add a paid support option. If you have so much traction already that you constantly have to deal with "hundreds of issues", you're well past the point where you should have done that.

ucarion 9y ago

"I found a bug and you won't consider it unless I phrase it as example code? Screw you, I won't report it then!" This seems like a reasonable thing to think and say. A better alternative to the article's suggestion is to state somewhere that it is very likely your issue won't be considered unless it takes the form of a PR. The maintainers, if they don't want to deal with the bug, will say "could you make a PR with a failing test case? Otherwise I don't have the time to work on this". That way, those who really want the bug fixed have to put in work, but those who just noticed a problem and are kind enough to let the maintainers know can do so easily. Why discourage bug-reporting?

robotresearcher 9y ago
I think I covered that in 'recommend a different approach in a civil tone if you must'. It's the 'screw you' that put my back up.
- Retra 9y ago
  To be fair, that 'screw you' was offered behind a predicate.
  - chc 9y ago
    That doesn't help much, seeing as the predicate is essentially "… if you don't want to do free debugging work for me as well as the free development work you're already doing."
    - Retra 9y ago
      Nobody said you have to actually fix the errors, only allow them to be reported. (Which GitHub makes pretty effortless, as I understand it.) At least then someone might be able to volunteer to fix it for them, especially if it is a serious or common problem.
dragonwriter 9y ago
Perhaps most importantly, having the issue there let's some other interested user see it and put the effort in to repro the bug and do the test case or demonstrative example.

BugsJustFindMe 9y ago

> 'screw you'? Not classy. Then, fine, tone police, I'm not classy. I am, however, a FOSS developer who understands the value of non-technical contributions to a project. Know which kinds of bugs don't get fixed? The ones your users never tell you about because you decided to make it hard to report them.

scrollaway 9y ago
A thousand times this. Issues are generally a favour your user is doing you and your project. Yes, sometimes they're a waste of time; it's fine to close them if they are, it takes exactly one click to do so. Most of the time however, they're valuable even if you don't fix them: Other devs might see them and fix them for you. In almost all cases, turning issues off is incredibly counter-productive.
robotresearcher 9y ago
I agree with your argument completely. Just be nice, and your accurate advice is more likely to be useful. That's all.
- BugsJustFindMe 9y ago
  > Just be nice, and your accurate advice is more likely to be useful. That's all. https://en.wikipedia.org/wiki/Tone_policing https://en.wikipedia.org/wiki/Tone_policing My advice is already useful. If someone chooses not to take it because they'd rather tell non-technical users to pound sand, then I hope their project suffers for it.
  - robotresearcher 9y ago
    There is an obvious meta comment to make here that I leave as an exercise for the reader.
    - BugsJustFindMe 9y ago
      Nah, you're probably mistaken.

scrollaway 9y ago

Issues are fine. You don't need to tackle them, they're not an obligation - you don't have a contract with your users saying you'll fix their issues. If that's something you want, then say so in your README; corps will always be happy to pay for high quality code and support. Most people freaking out about being burned out by their open source stuff are generally people who don't open source their stuff. Most open source projects, even very good ones, get very little traffic therefore very few issues. If you can't deal with the occasional email once every few months, turn notifications off. > But 'screw you'? Not classy. Saying "Write a test" is essentially saying "screw you". Github has been a blessing, in that it greatly lowered the barrier of entry in filing an issue with a project. It's a blessing for users and it's also a blessing for maintainers if you know how to deal with the influx of issues. Increasing the barrier of entry again is not the solution. When I myself find bugs I'll certainly PR a fix if I'm able to (and have the time); but I often can't. Most of the time, because the development environment is unknown to me and I have no way to even run the tests (if there are any), let alone write one. So asking someone to get involved and up to speed with a project to the point that they're able to do this, before they can even file an issue with a screenshot that says "the padding looks bad on firefox", that's nonsense. It's even more nonsense when this is just a pet project of yours that most people will not care about. IMHO, "this is stuff we do give away for free" is an excuse that's too often passed around. It is always true that projects you push to Github for free come with no obligation to care about it, its issues or the pings and cries for help from your desperate potential users. However, you lose the ability to say you're a good open source citizen and you're "giving things away". A real-world parallel I can make is to the people giving their old/smelly/crappy/torn/bad clothes to charity shops and feeling ever so good about themselves. It's cool you have good intentions, but it's not charity if it ends up in the bin anyway. Disclaimer: 99% of my work is open source and ends up on Github. A bunch of it sucks and when issues come up, I ignore them or write a 10-second close-reply. A bunch of it is good and I actually care about; and if I care about it, I'm not going to turn off issues just to make myself feel better about having an already-perfect project.

cgag 9y ago

This post just seems like it's trying to class-up a screw-you to their users. I'd prefer people just keep it crude like this rather than try to make it sound like it's somehow a nice thing to do.