Max Bowsher wrote:
> The thing is, simple though it may seem, there still things that need to be
> discussed, and filed into the issue - we intend our issue tracker to be a
> kind of developer to-do list, which means that where enhancements are
> concerned, we want to have matters of design qualified enough so that it's
> possible to tell how big a job an issue is, and what code it is expected to
This handling of the bug database seems a little bit, er, "different"
to me, based on past experience with other open source projects. In my
opinion a bug database and a to-do list are different things: "bugs" are
very raw things created and defined by users, not developers; developers
then get to evaluate and process them. A "to-do" list is a much more
refined and highly processed thing developers use to direct their work.
Right now it seems like you have the worst of both worlds: you seriously
impede the flow of raw bugs from users, yet you also allow random people
to add bugs to the bug database from the web site, thus polluting your
"to-do" list and causing all sorts of yelling about bold red text.
If it were my decision I'd suggest either:
(a) closing the bug database to random people, forcing all bug reports
to go through the mailing list and having a real developer actually
file the bug; or
(b) freeing up the bug database (allowing and encouraging "raw" bug
reports), and using the bug status to indicate whether the
bug is really on the "to-do" list (e.g., NEW is not, ASSIGNED is).
By default, newly filed bugs would not be of course.
I realize the current setup is a result of previous frustration
with the high number and/or low quality of bug reports. Perhaps then
(a) would be the right option.
On the other hand, just because a bug gets filed doesn't mean it
has to be dealt with immediately. E.g. FreeBSD works this way,
there are thousands of outstanding bugs, but they all eventually
get dealt with in one way or another, sometimes several years later.
In the mean time you might say the bug is "ignored bug not forgotten".
There is nothing inherently wrong with having lots of un-tended-to bugs.
That number is purely a function of available developer time.
Just my opinion..
Archie Cobbs * CTO, Awarix * http://www.awarix.com
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Sat Sep 25 15:45:22 2004