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@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,
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@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user



--