From: Paul Louden <paulthenerd_at_gmail.com>
Date: Sat, 21 Jun 2008 09:57:39 -0500

Antony Stone wrote:
> a) close down the list if they don't intend to do anything with the ideas
> expressed there
>
The way you've phrased this, it sounds like somehow someone's obligated
to follow up on feature requests. Even if we never, ever, ever intended
to do anything about them, wouldn't they possibly still be valuable as a
repository of ideas for new people interested in working on the project?
> b) respond to the posting which are deemed "pointless or crappy and will never
> be implemented" so that at least people know that, and they don't hang around
> for years as open requests on the list.
>
>
We do this already, the problem is there are many, many, many cases
where, for example, I think it's a crappy, horrible, terrible idea but I
know I shouldn't reject it outright simply because it's not my project
and while I don't like it, maybe I can at least voice my concerns so
that if someone does work on it, it finds its way in in a manner that's
at least more suitable, and helps make more people (on average) happy.

> On a similar vein, I can't quite work out what the system is for the bugs
> tracker - once someone has posted a bug and confirmed the circumstances and
> how to reproduce it, is there any mechanism for scheduling a fix into the
> workstream,
How would one schedule anything with volunteers? In a ExampleCo, you can
say "You work X hours a day for me, and while you're here, you'll be
working on this." In Rockbox, if Bob McDemonstration usually works 8
hours a day on Rockbox, and someone said "While you're working on
Rockbox, we want you to be fixing this bug, because you probably know
the most about it" all that will happen is that days he's not interested
in tinkering with a hard to find bug, he'll work on Project Widget instead.
> or allocating the fix to someone who knows that part of the code,
> etc? I know this is an open source project run by volunteer developers, and
> nobody can be told what to do, but I'm just wondering what mechanism is used
> to try to get action on confirmed bugs which are in the system?
>
>
Firstly, many "confirmed" bugs aren't as confirmed as the authors think.
Reproducing on the author's side is the first step, but in many cases
they can't be reproduced on the developer's side. Even then, if the
developer can trigger it regularly, it's often not obvious at all where
in the code the actual problem is. Obvious bugs rarely stay around for long.

As for assignment, the assignment system is actually a way for a
developer to say "Hey, I've looked into this, I have an idea, and I'm
working on a patch. You can work on one too, if you think you can do it
better/faster, but you don't need to waste your time on it. I've got
this one." Except in exceedingly rare circumstances, it should really
only be used by someone assigning something to his or her self.
Received on 2008-06-21