18 Dec
2015
18 Dec
'15
10:31 p.m.
Hey Len!
Thanks for the feedback!
This is good point about the users and since this was the first time I
spoke on the topic, I still need to thing some things over and everyone's
feedback and criticisms are very welcome.
What you say about the user is also true. Perhaps it is right to say that
users and developers should work together. But the reason why developer, in
my view, carries more weight in this matter, is because he is the one
investing his time and skill. Therefore, it seems rational for him to make
sure he understands the feature and why it is needed (if at all).
Another weak point in my talk are roadmaps. Many software actually do have
roadmaps. In my view, however, they have a tendency to be random and not
very well aligned with product vision. But I did not go into such
Additionally, in the future I will refrain from giving concrete examples as
I do not want to offend any developers - especially since I do not think
that my talk is really criticism, but rather analysis of the situation.
Whether it is good or bad is up to each one of us.
On Fri, Dec 18, 2015 at 9:26 PM, Len Ovens <len(a)ovenwerks.net> wrote:
On Thu, 17 Dec 2015, Louigi Verona wrote:
Last week Nils posted to the list, but apparently it has been filtered out,
--
Louigi Verona
http://www.louigiverona.com/
although I do see it in list archives.
We decided to re-post it to the mailing list for those of you (or perhaps
even
all of you) who missed it.
Got it, but at the time some parts were missing. They all seem to be there
now.
Interesting points in the last one about linux sw and developers. Having
just started doing some development work it is even more applicable to me.
Yes, most things are built for the builder first. Personally, I have tried
to make things only I will use as the things that require CL options. So
far I have had no requests for features on my own SW. However, having
helped bugfix in Ardour a bit, I have seen a lot of feature requests that
just don't make sense. Not that they are wrong or bad feature requests, but
that the user has not explained what it is really that they are looking
for. Most of the time this is because some other DAW has this feature and
they just use the name in that DAW or that it is very obvious with what is
in front of them right now. Reading a feature request that is about MIDI
while I am working with Audio, for example, is going to confuse me onless
the user actually says "when editing midi".
So I am thinking that badly executed feature requests may also be partly
the user's fault. As a user, someone asking for a feature should be willing
to stick around and explain fully what they want and help test the results.
I will note that I am not any better at making feature requests than anyone
else. I generally have to explain more than one time what I am actually
wanting. (bug reports have similar issues)
So in the same way a bug report should include a recipe to make the bug
happen, what actually happens, what is expected. A feature request should
do the same.
There are some developers who are just grumpy by nature... or because of
culture/language just seem that way.
Anyway, it was a very good talk (all three parts). Thank you for posting.
--
Len Ovens
www.ovenwerks.net
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user