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(a)gmail.com> wrote:
On Fri, Aug 16, 2013 at 1:57 AM, Gabbe Nord <gabbe.nord(a)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.