4 ms·

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 (ex

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.

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.