Re: [LAU] Linux Audio podcast. episode003: commenting replies

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: J. Liles <malnourite@...>
Cc: linux-audio-user <linux-audio-user@...>
Date: Saturday, August 17, 2013 - 9:04 am

--047d7bd766de7c8ee704e420ffd1
Content-Type: text/plain; charset=ISO-8859-1

Great response!

I think you're touching on what I perceive as one of the bigger potentials
in linux audio - the community integration. Perhaps a no brainer given it
open source, but still not something I feel has reached its potential just
yet. Like I said before, one of the biggest draws for me is the possibility
to interact both with the people that make the software, and also the
people who use it the same way I do. I completely understand that no dev
will sacrifice their free time to develop something they don't find
interesting. I wouldn't be making music in a style I don't find
interesting.

However, there's so much other, different things users can do. Something
that's usually a bit lacking in audio software is tutorials and examples of
actual usage of the applications. I can't even count the number of times
I've read about or seen interesting software, but just couldn't figure the
software out. This is something that users can contribute without
necessarily needing any advanced knowledge of debugging etc. Now that the
sync issue with screen casting is solved as well, we should have a good
basis for doing that. I will actually look in to doing something like that
this weekend, just to show I'm not just talk ;-)

On Fri, Aug 16, 2013 at 1:04 PM, Gabbe Nord wrote:

> Yes, those are all fair points. What about the rest of the questions? Lets

Bug reports are an entirely different problem. It's very hard to get a
quality bug report. They vary quite a bit. Often they are of the form "X
doesn't work properly". That's about as helpful as a handful of sand in the
eyes. It doesn't define 'properly', it doesn't explain how the user
determined that X doesn't meet that definition, it doesn't say what version
of X, where it was aquired, how it was built, on what system it was running
etc, and it is just lacking information in general. On the flip side, lots
of bug reports (this is especially true of automatically generated ones)
include pages and pages of backtraces and dumps, but don't give any other
context, such as what the user was trying to accomplish at the time (often
an extremely important piece of information!).

I have an article about how to prepare bug reports here:

http://non.tuxfamily.org/wiki/BugReports

But the issue has been covered at length elsewhere. Often the backtraces
etc are not even required, what is required is full disclosure on what the
user did and why--preferably without judgements or accusations (these often
backfire anyway, as a fair percentage of bugs can indeed be attributed to
user error, system configuration, or some other thing that is completely
outside the control of the developer).

Personally, I respond best to interesting ideas. If someone has a use case
for my software that I know I'll never personally need, but it's an
interesting an appropriate use case, I'm very likely to go ahead and put in
the time to implement it. Donations are always rewarding as well, they are
a very tangible way of saying 'thank you' and 'I like this'. Lots of people
will /say/ they love your work, but few will prove it by contibuting
(anything). As is true of most projects, I don't get many donations (that's
another topic entirely!), but I have had a few power users donate
considerable sums, and discussing changes with them feels a lot more like
collaboration than it does answering demands from those who contribute
nothing.

I'm also very likley to accept patches, and willing to offer lots of help
understanding the code and design for those who want to extend the
software--even if it's in a direction that I don't agree with and wouldn't
merge into the mainline.

Testing is also appreciated. The best testing is acutal use and lots of bug
reports! It sucks to put out a 'stable' release and *then* get the bug
reports.

Hope some of this was helpful!

--047d7bd766de7c8ee704e420ffd1
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Great response!
I think you're touching on what I perceive as one of the=
bigger potentials in linux audio - the community integration. Perhaps a no=
brainer given it open source, but still not something I feel has reached i=
ts potential just yet. Like I said before, one of the biggest draws for me =
is the possibility to interact both with the people that make the software,=
and also the people who use it the same way I do. I completely understand =
that no dev will sacrifice their free time to develop something they don&#3=
9;t find interesting. I wouldn't be making music in a style I don't=
find interesting.

However, there's so much other, different things users c=
an do. Something that's usually a bit lacking in audio software is tuto=
rials and examples of actual usage of the applications. I can't even co=
unt the number of times I've read about or seen interesting software, b=
ut just couldn't figure the software out. This is something that users =
can contribute without necessarily needing any advanced knowledge of debugg=
ing etc. Now that the sync issue with screen casting is solved as well, we =
should have a good basis for doing that. I will actually look in to doing s=
omething like that this weekend, just to show I'm not just talk ;-)

On Fri, Aug 16, 2013 at 1:04 =
PM, Gabbe Nord <gabbe.nord@gmail.com> wrote:

Yes, those are all fai=
r 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 de=
sire to learn how to code) contribute to the non-tools?

Bug reports are an entirely di=
fferent problem. It's very hard to get a quality bug report. They vary =
quite a bit. Often they are of the form "X doesn't work properly&q=
uot;. That's about as helpful as a handful of sand in the eyes. It does=
n't define 'properly', it doesn't explain how the user dete=
rmined that X doesn't meet that definition, it doesn't say what ver=
sion of X, where it was aquired, how it was built, on what system it was ru=
nning etc, and it is just lacking information in general. On the flip side,=
lots of bug reports (this is especially true of automatically generated on=
es) include pages and pages of backtraces and dumps, but don't give any=
other context, such as what the user was trying to accomplish at the time =
(often an extremely important piece of information!).

I have an article about how to prepare bug reports here:=
http://non.tuxfamily.org/wiki/BugReports
But the issue has been covered at length elsewhere. Often the backtraces et=
c are not even required, what is required is full disclosure on what the us=
er did and why--preferably without judgements or accusations (these often b=
ackfire anyway, as a fair percentage of bugs can indeed be attributed to us=
er error, system configuration, or some other thing that is completely outs=
ide the control of the developer).

Personally, I respond best to interesting ideas. If someone =
has a use case for my software that I know I'll never personally need, =
but it's an interesting an appropriate use case, I'm very likely to=
go ahead and put in the time to implement it. Donations are always rewardi=
ng as well, they are a very tangible way of saying 'thank you' and =
'I like this'. Lots of people will /say/ they love your work, but f=
ew will prove it by contibuting (anything). As is true of most projects, I =
don't get many donations (that's another topic entirely!), but I ha=
ve had a few power users donate considerable sums, and discussing changes w=
ith them feels a lot more like collaboration than it does answering demands=
from those who contribute nothing.

I'm also very likley to accept patches, and willing to o=
ffer lots of help understanding the code and design for those who want to e=
xtend the software--even if it's in a direction that I don't agree =
with and wouldn't merge into the mainline.

Testing is also appreciated. The best testing is acutal use =
and lots of bug reports! It sucks to put out a 'stable' release and=
*then* get the bug reports. Hope some of this was helpf=
ul!

--047d7bd766de7c8ee704e420ffd1--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAU] Linux Audio podcast. episode003: commenting replies, Louigi Verona, (Thu Aug 15, 11:23 am)
Re: [LAU] Linux Audio podcast. episode003: commenting replies, Leonardo Palomares, (Fri Aug 16, 5:58 pm)
Re: [LAU] Linux Audio podcast. episode003: commenting replies, Fons Adriaensen, (Sat Aug 17, 10:00 pm)
Re: [LAU] Linux Audio podcast. episode003: commenting replies, Fons Adriaensen, (Sun Aug 18, 11:25 am)
Re: [LAU] Linux Audio podcast. episode003: commenting replies, Gabbe Nord, (Sat Aug 17, 9:04 am)
Re: [LAU] Linux Audio podcast. episode003: commenting replies, Harry van Haaren, (Thu Aug 15, 11:42 am)