[LAU] Linux Audio podcast. episode003: commenting replies

[Gabbe Nord]

Yes, those are all fair points. What about the rest of the questions? Lets
take the non-tools for example, as you're the author of them. With the
non-tools, what do you think users (current as well as potential future
ones) could do better in terms of bug reporting? How can a user (read: one
without the ability or desire to learn how to code) contribute to the
non-tools?


On Fri, Aug 16, 2013 at 6:53 PM, J. Liles <malnourite at gmail.com> wrote:

>
>
> On Fri, Aug 16, 2013 at 1:57 AM, Gabbe Nord <gabbe.nord at gmail.com> wrote:
>
>> If we move past the current arguments of "don't complain about free
>> stuff", there's something pretty interesting to discuss that we all could
>> benefit from; how do we make this better?
>>
>> From both a user and a developers standpoint, how do we make this
>> interaction better? What can users do to provide better bug reports, and
>> how should they be handled? Are there guidelines for most projects as to
>> how users should report bugs? Can we simplify this bugreporting somehow for
>> the user, and at the same time make it more powerful to the dev?
>>
>> What does developers think is lacking in this interaction right now? What
>> does users think's lacking?
>>
>> One point Hermann made is that devs more or less only gets contacted when
>> there's something wrong with their application. I can really see how that
>> is, and that's very unfortunate. For me, one of the greatest draws to Linux
>> Audio is the fact that I can so easily interact with the people who write
>> the applications I use. A tighter community integration would be great for
>> most people. We have forums like Linuxmusicians.com, which might be a bit
>> more laid back than the projects official forums. Maybe we could try and
>> use LM-forums as a gathering point for the community for real? If we make
>> sure every project that wants gets its own sub-forum, getting together and
>> both discussing as well as helping each other gets very easy. Any thoughts
>> on that idea?
>>
>> For me personally as a user, I can subscribe to a lot of Louigi's
>> thoughts. The applications I use more or less always has some fairly basic
>> functionality that's either half or fully broken. Even if there's reports
>> and a will to help debug, there's only so much one (or at best, a handful)
>> developer can do. What's basic and a *must* functionality for me, might not
>> at all be important to the rest. This is a reality, but can we make it
>> better?
>>
>> Please feel free to answer any of my questions here. I'd love to hear
>> what both developers and users have to say about this, as this is something
>> that
>>
>>
> The fact of the matter is, if you have a feature that is non-trivial,
> critical to you, and not critical to others (especially the developer), you
> have the following options:
>
> 1) pick a more appropriate tool. The natural instinct of a user is to
> INSIST that the feature X they want should be integrated into software Y,
> when really the feature may have nothing to do with Y at all, it just
> happens to be the software they're working with at the moment. This force
> should not be underestimated, as it is a very real effect and one of the
> major causes of software bloat. Chances are that some other program exists
> that was DESIGNED to do X and does it well. This is why we have DAWs that
> burn CDs and text editors that play tetris and browse the web--and the
> general result is a lot of software that does the same thing poorly rather
> than a little bit of software that does it well.
>
> 2) make a convincing case to the developer (maybe even one not connected
> to the project you want to change). Programmers work for free in a large
> part because it can be fun. They will only work for free on fun things. For
> unfun things, you have to pay them boatloads of money. If you have a
> feature that you consider important--convincing the developer that it's
> importand and interesting is going to be a lot more effective than just
> whinging about how badly you need it.
>
> 3) pay for it. 60% of the time, it works every time.
>
> 4) Do it your own damn self. I'm dead serious here. This is how users
> become developers. They identify a need that only they have, or in a domain
> that only they understand well enough to devise a solution. Either by
> patching existing software (a hell of a lot easier than you think!) or by
> starting something from scratch (goodbye nights and weekends! but hello
> personal improvement and satisfaction). Many great free-software projects
> started out this way.
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-user/attachments/20130816/8e2329f7/attachment.html>