4 ms·

I'm going to quote @BugsJustFindMe in a separate comment, because I think it's a terrific counter-argument to "just open a pull request" as a universal rule: A

I'm going to quote @BugsJustFindMe in a separate comment, because I think it's a terrific counter-argument to "just open a pull request" as a universal rule: A month ago I encountered a bug in LibreOffice Writer, which I use because it's really good, where track changes on a docx file wasn't working properly in a particular situation involving the deletion of tracked comments across saves. QUICK! Find the line of code that caused it! Find the mechanism for creating a test case! I'll wait here. If the open source project in question is one where users can be reasonably expected to be familiar with your code base, then "propose a fix with a unit test" is fine. But when it's a project whose nature means that users have little to no incentive to look at the code, then the reasonableness of this request decreases with the the size and complexity of the project. And, quoting BugsJustFindMe again: Caring about FOSS doesn't fix bugs. I'm a competent developer, but if I ran into a bug in the text-processing utility Pandoc, it's very unlikely I'm going to drop what I'm doing, analyze the source, pinpoint the problem, and submit a PR with a unit test, and oh yes, learn enough Haskell to do all this, and I don't think it would be reasonable to expect me to do so.

roblabla 9y ago
It's funny because i actually did exactly what you're talking about once when I ran into a bug in the parsing logic of wikitext tables in pandoc. I read the (extremely well organized) source, having never ever done any haskell before. The fix ended up being a 2 character change, it took me an hour to do, and I didn't really have to learn haskell to do it. Point being, if you find a bug in a software, as a fellow developer, I think it's reasonable for the maintainer to expect you to at least take a quick look around. Regardless of prior knowledge. You get to learn stuff, and the project maintainers have their load lighten up.
- davezatch 9y ago
  That's nice when possible, but of course when something breaks you never know if it will be one hour or 30, and even then, I think there are a lot of cases where "let the developer know there's an issue" is still worth it, especially if the alternative is "drop it and say nothing because it's too much of a hassle."
- notacoward 9y ago
  What about if they did take a quick look around, and determined that trying to fix it themselves or even find the guilty line would take too long? If I spend hours, days, or even weeks like that every time I found a bug in someone else's code, I'd be doing my own users a severe disservice. I owe it to them to spend my time more productively than that. So if the author's answer is "patch or GTFO" then I've found someone I'd never hire and probably wouldn't even want to interact with. Real open source is about the community as much as the code. It's not about authors and users each trying to set themselves above the other. True collaboration involves mapping tasks to expertise in the way that results in the greatest overall good. If an expert in an area unilaterally shuts off that conversation, then they're not really helping open source. They're just throwing stuff over the wall and pretending it's open.
camtarn 9y ago
It's a good point. This post probably applies much more for libraries, where it's pretty easy to open a pull request with a code example causing the bug. For batch-processing tools like Pandoc, uploading an example input file, output file, and description of what's wrong in the output would still be very useful. I guess the nearest analogy for a graphical tool that you use as an end user, rather than a developer, would be recording a video of you triggering the bug :)
- jasode 9y ago
  >This post probably applies much more for libraries, where it's pretty easy to open a pull request with a code example causing the bug. Yes, a cursory glance at the author's repositories shows he's talking about libraries for other developers and not consumer apps like LibreOffice/GIMP/VLC/etc used by non-programmers. https://github.com/ryanflorence?tab=repositories https://github.com/ryanflorence?tab=repositories

roblabla 9y ago

It's funny because i actually did exactly what you're talking about once when I ran into a bug in the parsing logic of wikitext tables in pandoc. I read the (extremely well organized) source, having never ever done any haskell before. The fix ended up being a 2 character change, it took me an hour to do, and I didn't really have to learn haskell to do it. Point being, if you find a bug in a software, as a fellow developer, I think it's reasonable for the maintainer to expect you to at least take a quick look around. Regardless of prior knowledge. You get to learn stuff, and the project maintainers have their load lighten up.

davezatch 9y ago
That's nice when possible, but of course when something breaks you never know if it will be one hour or 30, and even then, I think there are a lot of cases where "let the developer know there's an issue" is still worth it, especially if the alternative is "drop it and say nothing because it's too much of a hassle."
notacoward 9y ago
What about if they did take a quick look around, and determined that trying to fix it themselves or even find the guilty line would take too long? If I spend hours, days, or even weeks like that every time I found a bug in someone else's code, I'd be doing my own users a severe disservice. I owe it to them to spend my time more productively than that. So if the author's answer is "patch or GTFO" then I've found someone I'd never hire and probably wouldn't even want to interact with. Real open source is about the community as much as the code. It's not about authors and users each trying to set themselves above the other. True collaboration involves mapping tasks to expertise in the way that results in the greatest overall good. If an expert in an area unilaterally shuts off that conversation, then they're not really helping open source. They're just throwing stuff over the wall and pretending it's open.

camtarn 9y ago

It's a good point. This post probably applies much more for libraries, where it's pretty easy to open a pull request with a code example causing the bug. For batch-processing tools like Pandoc, uploading an example input file, output file, and description of what's wrong in the output would still be very useful. I guess the nearest analogy for a graphical tool that you use as an end user, rather than a developer, would be recording a video of you triggering the bug :)

jasode 9y ago
>This post probably applies much more for libraries, where it's pretty easy to open a pull request with a code example causing the bug. Yes, a cursory glance at the author's repositories shows he's talking about libraries for other developers and not consumer apps like LibreOffice/GIMP/VLC/etc used by non-programmers. https://github.com/ryanflorence?tab=repositories https://github.com/ryanflorence?tab=repositories