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.
I appreciate this. I don't know how to fix anything, but I have used so much software that I do know how to describe the circumstances of a bug pretty well (and supply logs, screenshots, etc). I...
I appreciate this. I don't know how to fix anything, but I have used so much software that I do know how to describe the circumstances of a bug pretty well (and supply logs, screenshots, etc). I like to think my feedback on open source projects has been a net positive, but who really knows.
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.
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.
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.
Maintainers have an obligation to fix the software. I won't get too mad if they won't, but the community can also see that they don't care about the sofware if they don't fix it. I'm not a...
Maintainers have an obligation to fix the software. I won't get too mad if they won't, but the community can also see that they don't care about the sofware if they don't fix it.
I'm not a developer and have reported bugs many times and seen them fixed. I can do distro packaging, but don't have the keys to the repo often so will report a bug on a tracker, and it will be fixed. Once I identified a buffer overflow in an application. I couldn't fix it, but the dev identified the bug, and it was patched in less than a day.
Report bugs. Make good reports, as well, but most devs want tonfix your bugs, because it makes their software better, and most open source devs take pride in their hobby projects (or even occasionally paid projects).
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.
I appreciate this. I don't know how to fix anything, but I have used so much software that I do know how to describe the circumstances of a bug pretty well (and supply logs, screenshots, etc). I like to think my feedback on open source projects has been a net positive, but who really knows.
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.
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.
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.
Maintainers have an obligation to fix the software. I won't get too mad if they won't, but the community can also see that they don't care about the sofware if they don't fix it.
I'm not a developer and have reported bugs many times and seen them fixed. I can do distro packaging, but don't have the keys to the repo often so will report a bug on a tracker, and it will be fixed. Once I identified a buffer overflow in an application. I couldn't fix it, but the dev identified the bug, and it was patched in less than a day.
Report bugs. Make good reports, as well, but most devs want tonfix your bugs, because it makes their software better, and most open source devs take pride in their hobby projects (or even occasionally paid projects).
I reported a bug once to Lutris, it got marked as not our problem.
Last time I ever reported a bug.