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@email-addr-hidden> 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@email-addr-hidden
> http://lists.linuxaudio.org/listinfo/linux-audio-user
>
-- Louigi Verona http://www.louigiverona.com/
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-user
Received on Sat Dec 19 00:15:02 2015
This archive was generated by hypermail 2.1.8 : Sat Dec 19 2015 - 00:15:03 EET