Rockbox mail archiveSubject: Re: question about tracker e mails to the list
Re: question about tracker e mails to the list
From: Antony Stone <Antony.Stone_at_rockbox.open.source.it>
Date: Sun, 22 Jun 2008 13:59:46 +0100
On Sunday 22 June 2008 13:18, Dominik Riebeling wrote:
> There are three options:
> 1. from a users point of view. Development is concentrated to make it
> the best experience for users.
> 2. from a developers point of view. User opinions aren't of interest
> but only what devs want. You might think I'm looking that way, but I
> go with the following
> 3. from the projects point of view. You need to ask "what's best for
> the project, and what pushes the project forward?".
> ...it's important to make life easier
> for those doing the work, and those are the devs.
> If they get drowned in feature requests (especially absolutely pointless
> request we already exclude in the tracker guidelines -- obviously quite some
> people don't read them -- like "port to player X", "Ipod Nano 2G needed
> urgently", "Help, my player won't turn on" etc.) they get annoyed and will
> most likely constantly ignore them.
> From my point of view we currently somewhat have this situation. So making
> feature request more valuable and pre-sorted would increase the possibility
> of someone actually looking at them.
Thanks, I appreciate that explanation and I can completely understand and
agree with it.
How about this as a suggestion to help things work better then:
- approve some small number of people onto the "developer" team (basically
give them greater access rights to the tracker system, not necessarily the
code repository) who don't contribute code but do deal with bug reports
(qualifying them, posting to the users list to see if other people can
reproduce them) and feature requests (cancelling the stupid ones, marking the
duplicates, asking on the users list about the ambiguous ones) so that the
tracker becomes more valuable and is to some extent pre-vetted and pre-sorted
for the rest of the developers who would do the actual coding?
Just as people who don't code can greatly benefit a project by working on the
documentation, it seems there might be a gap here for people to help smooth
the whole process of the tracker/s whilst not losing valuable user input in
the first place?
-- "It is easy to be blinded to the essential uselessness of them by the sense of achievement you get from getting them to work at all. In other words - and this is the rock solid principle on which the whole of the Corporation's Galaxy-wide success is founded - their fundamental design flaws are completely hidden by their superficial design flaws." - Douglas Noel Adams Please reply to the list; please don't CC me.Received on 2008-06-22