New subject: Linux Audio podcast. episode002

15 Aug 2013

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

On Wed, Aug 14, 2013 at 6:36 PM, Burkhard Ritter &lt;burkhard(a)ualberta.ca&gt; wrote:
...
  On Wed, Aug 14, 2013 at 10:53 AM, J. Liles
&lt;malnourite(a)gmail.com&gt; 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 

Re: [LAU] Linux Audio podcast. episode002