3 ms·

I don't bother filing bugs or sending PRs. I spend hours filing a detailed bug report. No response. I spend hours crafting a PR. Ignored. I file a bug report al

I don't bother filing bugs or sending PRs. I spend hours filing a detailed bug report. No response. I spend hours crafting a PR. Ignored. I file a bug report along with several possible solutions. I get a snarky response totally unrelated the proposed solutions. But I get it. Maintainers are overworked and jaded. I'm on the receiving end as well, with 95% of the issues like: "help, it's broken" (with no error message), "please teach me git", "please debug my application code", "please implement this massive feature for me" (for free), "how do I do xxx?" (obviously didn't read the README.md), "your library is buggy" (no it's not, your pointer has run off the end of your array, causing Undefined Behavior). With all of that noise, it is difficult to figure out which bug reports or PRs are in the 5% that are actually well-researched and valid.

throwaway13337 5y ago
Well put. A reputation/karma system for bug reports could be an interesting way to deal with this problem. I wonder if it’s ever been tried.
deathanatos 5y ago
I file bug reports. It greatly depends on the person running the project; some are like you describe, or they're incompetent (particularly problematic in non-FOSS projects). Those, it's usually pretty clear that you're going to have to weigh "how much do I want this bug fixed" against how painful the process will be. But I've also had maintainers who were very helpful. Recently had to deal with the DST cross-sign expiring, and needed a third-party container to be rebuilt on a later version of Debian. Filed an issue with really nothing more than "Would you mind releasing with a newer version?"¹ and the maintainer had it published within like a day! Greatly made my life easier. So I really want to separate out those maintainers that are doing a stellar job; certainly some merit your criticism, just not all. ¹I didn't have time then to track down the Dockerfile & figure out the required patch. Might have once my time freed up, but the maintainer beat me to it.
- tomnipotent 5y ago
  > particularly problematic in non-FOSS projects In my experience, the products I pay for usually fix bugs faster than FOSS.
jrockway 5y ago
This is exactly the problem with an overadherance to "stability". If you submit a PR to fix a bug in a "stable" product, it will be a year before it ever becomes "stable", so the incentive to fix it is nearly zero, because you can't get the stability and your bug fix. (If they just ship every random PR to the stable build, well, now it's the "unstable" build.)

throwaway13337 5y ago

Well put. A reputation/karma system for bug reports could be an interesting way to deal with this problem. I wonder if it’s ever been tried.

deathanatos 5y ago

I file bug reports. It greatly depends on the person running the project; some are like you describe, or they're incompetent (particularly problematic in non-FOSS projects). Those, it's usually pretty clear that you're going to have to weigh "how much do I want this bug fixed" against how painful the process will be. But I've also had maintainers who were very helpful. Recently had to deal with the DST cross-sign expiring, and needed a third-party container to be rebuilt on a later version of Debian. Filed an issue with really nothing more than "Would you mind releasing with a newer version?"¹ and the maintainer had it published within like a day! Greatly made my life easier. So I really want to separate out those maintainers that are doing a stellar job; certainly some merit your criticism, just not all. ¹I didn't have time then to track down the Dockerfile & figure out the required patch. Might have once my time freed up, but the maintainer beat me to it.

tomnipotent 5y ago
> particularly problematic in non-FOSS projects In my experience, the products I pay for usually fix bugs faster than FOSS.

jrockway 5y ago

This is exactly the problem with an overadherance to "stability". If you submit a PR to fix a bug in a "stable" product, it will be a year before it ever becomes "stable", so the incentive to fix it is nearly zero, because you can't get the stability and your bug fix. (If they just ship every random PR to the stable build, well, now it's the "unstable" build.)