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@xxxxxxxxx> wrote:
On Fri, Aug 16, 2013 at 1:57 AM, Gabbe Nord <gabbe.nord@xxxxxxxxx> wrote:
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 thatWhat does developers think is lacking in this interaction right now? What does users think's lacking?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?
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?
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.
_______________________________________________ Linux-audio-user mailing list Linux-audio-user@xxxxxxxxxxxxxxxxxxxx http://lists.linuxaudio.org/listinfo/linux-audio-user
