How To Track the Bug-Trackers?
schneecrash writes "Submitting bug reports — and waiting for responses etc. — seems to be SOP for developers and users alike, these days. Every project has some sort of bug-tracker — bugzilla, trac, mailing list, etc. E.g., we currently track 200+ external bugs across ~40 OSS projects. Half the bugs depend on something else getting fixed, first. Every bug has its own email thread, etc. Management asks 'How we doin' overall?,' and suddenly everyone involved gets to work removing dried gum from the bottom of their shoe. What do Slashdotters use/recommend for centrally keeping track of all the bugs you track across all those different bugtrackers? In particular, managing communications and dependencies across bugs? So far, the best method I've managed to use is bunches of PostIt-notes stuck to the screen of an out-of-commission 32" TV (glossy, non-matte screen, of course!)."
Seriously, I've found them to be the best method of issue tracking.
Prediction: The real iPhone killer is going to be sex robots from Japan. Think about it.
Bug tracking software is great, and we implement it at our workplace (large company, so there are several solutions depending on what sort of project it is). However, it's important that the overall management gets done by a person. Put a person in charge of all bug fixes, have them start a Microsoft Project (or whatever the OSS solution is) file that tracks everything, assigns each bug to a person, and puts them in order of priority. Bug reports go in your bugzilla, this person gets notified, they map out the priority of the bug, who's skillset best fits it, when and how fast it needs to get done, etc.
There's probably a product where developers/bug-submitters can note the priority of their perceived bug, and can do this sort of thing for you. However, it doesn't solve the problem. Developers are going to pick the most interesting bugs to fix, not the most important (they're not always the same), and bug-submitters tend to think all their problems are life and death high priority. A manager is your best bet.
"How we doin' overall" then your not managing anything.
You set goals, you set milestones to get there, and you measure according to those goals.
When they don't meet, you explain why.
The Kruger Dunning explains most post on
I fix bugs as they are reported. There are currently 0 outstanding bugs in the various software projects that I maintain.
I use Tasktop. It is available as a standalone product or as an eclipse plug-in and will bring all the tasks from the multitude of bug trackers that I use for the various projects together so I can organize them as a todo list. So far it has worked great for me.
The second thing I like about tasktop is that it is an extension of the Mylyn project. Therefore it can limit what I see on my screen to items that are pertinent to my task, including interfacing with Firefox.
That sounds great, until a week in you get to a bug that you can't fix because something else is blocking it. Now you start working on that second one for about a week before you realize that it, too, is being blocked by another bug. And so, and so on. Pretty soon, you're six months in, haven't accomplished anything, and are no closer to solving those dependencies. And without mapping them out as you go, you might not know which ones to go back and fix in which order. Not to mention, not all bugs are created equal. Some you can ignore for now, some cause the entire project to stop dead in its tracks.
No, the best solution is always to stop what you're doing, back up, and make sure everything is mapped out. Better to spend two weeks doing that and get all your ducks in a row rather than running off and making things worse than they already are.
God invented whiskey so the Irish would not rule the world.
Obviously you've never worked for a ginormous corporation with competing divisions and a history of mergers stretching back a century or more. Suffice to say, it's really not that uncommon for there to be different bug tracking systems. I work for a large telecom company, and while I only work on about four or five projects, there are at least five different bug trackers, project management tools, and various other bits of e-bureaucracy that I deal with every day.
God invented whiskey so the Irish would not rule the world.
Why can't anyone agree one what's "right to use"? It seems everyone and their dog has a bug tracker, and I've yet to see one that seemed to do its job "well". Is this something that has a secret really elegant solution that Linus can pull out of his ass in an afternoon and save us all?
I wouldn't expect it, since he uses /mailing lists/ of all things, to track things. I suppose it's sortof a decentralized model of bug tracking: everyone has to figure shit out for themselves.
If I don't see an easy way to note:
- A list of known issues
- Whether they're being worked on by anyone
- What I can do to help
- What the plans are for the future
I'm much less likely to like a project. Having to send an e-mail requesting these things on a case-by-case basis seems just plain stupid.
Perhaps some elegant solution is there somewhere, begging for someone to bring it to light. Just as git accepted that e-mailed patches would always be essential to any project which used version control, maybe something can be built which rests on top of a simple mailing list, and takes care of the history and classification which is the true purpose of issue tracking.
The best system of any sort is one which not everyone needs to actively use for anyone to get benefit from.
-- 'The' Lord and Master Bitman On High, Master Of All