I have to disagree with this. I think we should encourage non-technical folks to submit issues, otherwise we're back to getting emails or messages that can't properly be tracked. Someone who...
I have to disagree with this. I think we should encourage non-technical folks to submit issues, otherwise we're back to getting emails or messages that can't properly be tracked.
Someone who simply uses your application should feel comfortable submitting a bug report. It should include enough information to reproduce it, but expecting test cases and the actual fix isn't realistic, imo. However, you do have every right to prioritize it however you see fit.
If this is in relation to a developer-focused project, such as an npm package or something, that's a bit different. But if it's an end-user application, you can't expect everyone to be able to fix their own issues.
Reads like rage bait to me. Their first point repeats the title and then qualifies it with the reasonable position: Yeah, a maintainer doesn't have any obligation, but that fact doesn't support...
Reads like rage bait to me. Their first point repeats the title and then qualifies it with the reasonable position:
Do not fix the bug. Because this is open source, and we are not selling software, maintainers may have some social responsibility, but are under no obligation to do anything.
Yeah, a maintainer doesn't have any obligation, but that fact doesn't support the prescriptive command to not fix bugs. But using this language gets more clicks and shares I'm sure. They continue to contradict the title as the post continues.
Taken at face value, it's a weirdly hostile attitude to the quality of their own software.
That said, sometimes I just want to fix the bug myself because it’s so interesting.
Does the author not understand that bug reports can make the software better and bring problems into the light and discussion? The reluctance to acknowledge this just feels like attention-seeking negativity.
Generally speaking, I only maintain open source projects that I myself use in production code, so if there is a bug I have a duty to my users to fix it -- it would be irresponsible to just leave...
Generally speaking, I only maintain open source projects that I myself use in production code, so if there is a bug I have a duty to my users to fix it -- it would be irresponsible to just leave it. That said, in almost every case where I report a bug to another open source project I provide tests and a patch.
A step-by-step guide to successfully killing your open source project. In less joking terms, the idea that everyone should learn enough about every piece of software they use to become...
A step-by-step guide to successfully killing your open source project.
In less joking terms, the idea that everyone should learn enough about every piece of software they use to become contributors feels absurd. It would turn all users that aren't software developers with infinite time into second-class citizens while leaving the product worse. Where would applications like Blender be if artists were told to not submit bugs they couldn't fix?
It also ignores that most developers, at least the ones I know, want to be informed of bugs regardless of who the reporter is just for the simple reason that they prefer their software to be good. Promoting a culture of hiding bugs doesn't help that person that just wants people to like, or at least find useful, what they made.
It reminds me a bit of people acting like you shouldn't criticize anything unless you can personally do it better.
It basically opens with that users aren't entitled to the maintainers' time, but ends with feeling entitled to the users' time to fix the project's buggy code.
I'd only support this position if the quality of the codebase was such that the time which it takes for me to grok the codebase and fix the issue is comparable to the time it takes the developer...
I'd only support this position if the quality of the codebase was such that the time which it takes for me to grok the codebase and fix the issue is comparable to the time it takes the developer with his back-of-my-hand knowledge of the codebase to fix it. In other words, I don't want to spend 20 hours understanding spaghetti to do what the developer could do in 30 seconds.
This is missing a lot of context to make it resemble anything reasonable to be honest. I feel like they are not describing bugs, but rather incomplete issues. All four bullet points seem to be...
This is missing a lot of context to make it resemble anything reasonable to be honest. I feel like they are not describing bugs, but rather incomplete issues. All four bullet points seem to be about dealing with people just not giving you the information to replicate a bug.
In that context what the author is saying makes a bit more sense.
Because I would consider it reasonable to not go out of your way to try to replicate a bug from an incomplete bug report. I don't find it reasonable to ignore a bug report where someone has taken clear effort to describe replication steps and include as much as possible.
I certainly find it completely unreasonable to ignore something that clearly is a bug.
I have to disagree with this. I think we should encourage non-technical folks to submit issues, otherwise we're back to getting emails or messages that can't properly be tracked.
Someone who simply uses your application should feel comfortable submitting a bug report. It should include enough information to reproduce it, but expecting test cases and the actual fix isn't realistic, imo. However, you do have every right to prioritize it however you see fit.
If this is in relation to a developer-focused project, such as an npm package or something, that's a bit different. But if it's an end-user application, you can't expect everyone to be able to fix their own issues.
Reads like rage bait to me. Their first point repeats the title and then qualifies it with the reasonable position:
Yeah, a maintainer doesn't have any obligation, but that fact doesn't support the prescriptive command to not fix bugs. But using this language gets more clicks and shares I'm sure. They continue to contradict the title as the post continues.
Taken at face value, it's a weirdly hostile attitude to the quality of their own software.
Does the author not understand that bug reports can make the software better and bring problems into the light and discussion? The reluctance to acknowledge this just feels like attention-seeking negativity.
Generally speaking, I only maintain open source projects that I myself use in production code, so if there is a bug I have a duty to my users to fix it -- it would be irresponsible to just leave it. That said, in almost every case where I report a bug to another open source project I provide tests and a patch.
A step-by-step guide to successfully killing your open source project.
In less joking terms, the idea that everyone should learn enough about every piece of software they use to become contributors feels absurd. It would turn all users that aren't software developers with infinite time into second-class citizens while leaving the product worse. Where would applications like Blender be if artists were told to not submit bugs they couldn't fix?
It also ignores that most developers, at least the ones I know, want to be informed of bugs regardless of who the reporter is just for the simple reason that they prefer their software to be good. Promoting a culture of hiding bugs doesn't help that person that just wants people to like, or at least find useful, what they made.
It reminds me a bit of people acting like you shouldn't criticize anything unless you can personally do it better.
It basically opens with that users aren't entitled to the maintainers' time, but ends with feeling entitled to the users' time to fix the project's buggy code.
I'd only support this position if the quality of the codebase was such that the time which it takes for me to grok the codebase and fix the issue is comparable to the time it takes the developer with his back-of-my-hand knowledge of the codebase to fix it. In other words, I don't want to spend 20 hours understanding spaghetti to do what the developer could do in 30 seconds.
This is missing a lot of context to make it resemble anything reasonable to be honest. I feel like they are not describing bugs, but rather incomplete issues. All four bullet points seem to be about dealing with people just not giving you the information to replicate a bug.
In that context what the author is saying makes a bit more sense.
Because I would consider it reasonable to not go out of your way to try to replicate a bug from an incomplete bug report. I don't find it reasonable to ignore a bug report where someone has taken clear effort to describe replication steps and include as much as possible.
I certainly find it completely unreasonable to ignore something that clearly is a bug.
I reported a bug once to Lutris, it got marked as not our problem.
Last time I ever reported a bug.