On Mon, Jul 9, 2012 at 3:26 PM, Joshua D. Drake <jd@commandprompt.com> wrote:
>
> On 07/09/2012 12:02 PM, Josh Berkus wrote:
>>
>>
>> Hackers,
>>
>> So I want to repeat this because I think we are conflating several uses
>> for a "bug tracker" which aren't the same, and which really need to be
>> dealt with seperately.
>>
>> -- Better CF App: to track feature submissions, discussion, revisions
>> and reviews.
>>
>> -- Bug Submitter: easy-access way for users to submit bugs and check on
>> their status later.
> Not sure how to handle the first two. Bug submission is always a pita and
> although we could use the fix-bug-later app, it would clutter it as we were
> trying to determine real bugs vs user error.
And whatever you/we do, be *VERY* aware of the
"pile-of-...-in-the-bugtracker problem". I just happend to have Joel
Spolsky's post come through my RSS reader, where he talked about about
bugtrackers, and suggested:
- Do not allow more than two weeks (in fix time) of bugs to get into
the bug database.
- If you have more than that, stop and fix bugs until you feel like
you’re fixing stupid bugs. Then close as “won’t fix” everything left in the bug database.
Don’t worry, the severe bugs will come back.
The biggest problem of whatever tool is used for anything, is making
sure tool is useful enough to people that need to use it to make it
worth their while.
A tracker (of any type) that is even *insanely* useful for users, but
that doesn't give *developpers* (note, that's developpers, not
managers, or cat-herders, or cheer-leaders) any extra value is bound
to fill and soon become un-usefull for even uses..
If you want the develops to use it, it has to be worth their time *to
them* to use it.
Witness the hundreds of graves that are he thousands bugzilla bugs out
there filed against even active open-source projects.
a.
--
Aidan Van Dyk Create like a god,
aidan@highrise.ca command like a king,
http://www.highrise.ca/ work like a slave.
