[LAU] Linux Audio podcast. episode002

[Burkhard Ritter]

Just realized I didn't send this to the list.

On Wed, Aug 14, 2013 at 6:36 PM, Burkhard Ritter <burkhard at ualberta.ca> wrote:
> On Wed, Aug 14, 2013 at 10:53 AM, J. Liles <malnourite at gmail.com> wrote:
>> To be clear, I'm not advocating not helping others, I'm simply pointing out
>> the altruistic nature of developers responding to bug reports. The OP makes
>> it seem like he's doing the developer a big favor by engaging in the
>> reporting process--when the truth is that his 15 minute bug report generates
>> hours of work for the developer--that the developer could have most likely
>> lived his entire life without needing to do otherwise. There's an underlying
>> sense of entitlement there that is really toxic to any process of
>> collaboration.
>
> In my experience (as someone who files bug reports only very
> occasionally), doing a good bug report is more on the order of an hour
> or even more. Hence, if I find a bug in a program that I only use once
> in a while, say for three to four hours every two to three weeks (my
> use case for most programs on linux audio), filing this bug is a
> considerable time investment relative to the time I actually use the
> program.
>
> Add to this the mindset of the person you are asking to file the bug
> report: As an example, say you finally got back to making some music
> after three weeks of abstinence; you carve out the time, you spend
> four hours doing some great stuff and then at two in the morning, when
> you are just about to finish things off, you run into a show-stopper
> bug. Some basic issue that "should just work". You are extremely
> frustrated, you know you are not going to get back to doing some music
> in weeks and you are not going to file a bug report. I imagine that's
> one of the situations Louigi is taking about.
>
> Things are probably quite different when it's not a show-stopper bug,
> but a smaller glitch: You finished drafting a song sketch and are very
> happy with the software you used, but encountered a couple of smaller
> issues. Next day you might be inclined to take the time to file the
> bug report.
>
> I am not sure what can be done to improve the situation, but Harry's
> testing-buddies idea seems very reasonable. As a spin on that, a
> dedicated group of "invested" users of some program (even very small
> software projects) could actively test a new version before it is
> released. I am sure this happens to some extent and in different forms
> for most projects, but I am not sure whether there is a conscious
> testing phase and a dedicated group of testers for any but the biggest
> projects (e.g. Ardour). The goal would of course be to not have any
> basic functionality broken in released versions.
>
> Cheers,
> Burkhard