Bugzilla, YUI, and other things.

Thursday, February 18, 2010

Make it like code.google.com's bug tracker

For a while we've been having discussions about tags and Bugzilla on the dev mailing list. To boil down a lot of the suggestion it consists of "we could do away with most of our fields/flags and replace them with tags, it would make the UI way better".

We've also had other discussions about how the bug edit page should change. Many of the suggestions consist of moving the non-comment data about a bug to the left or right side of the page and letting the comments take up most of the page.

Today (for the first time) i went into the code.google.com (cgc) bug tracker to see what the status of tagging was in chrome. Turns out both of these UI suggestions are exactly how chrome is implemented. I event went to the advanced search page to see if the suggestions i received from the advanced search page were the same (they weren't).

Anyway, i've received the message loud and clear "we like how google did it".

I'm tempted to make a jetpack that makes the BMO UI act/look a lot more like cgc. What do you guys think? Is it worth it or is TidyBug more the direction people prefer?

If you haven't seen cgc here is the URL i looked at today: http://code.google.com/p/chromium/issues/detail?id=17536


  1. "Let's be just like some other product" is always a fast route to product death. People use Bugzilla because they want Bugzilla, not the code.google.com tracker. If people wanted to use that, they would--it's free, after all, and hosted for free even. So I think we should make Bugzilla the best *Bugzilla* it can be, not the best code.google.com it can be.

  2. I agree. Mozilla should switch to a bug tracker that meets our needs rather than trying to turn Bugzilla into something it's not.

  3. Replacing most fields with tags was actually the original idea behind TidyBug. In addition to hiding empty fields, it was going to pretend each keyword, and each bracketed marker in the status whiteboard, was a separate field (like a tag). I think some of the code is still in there.

    But I was worried that the whiteboard might end up unreadable for people not using the script, so I tabled the idea for a while.

  4. What's the difference between tags and keywords? I believe release tracking actually migrated from keywords to custom fields, so how would tags help?

  5. Max: let's not get into a mindset that ways of doing things are bad _because_ some other tracker does them. Surely, if anything, the opposite is true.

    I could counter by suggesting many people use Bugzilla over the Google tracker because, er, their code isn't hosted on code.google.com. :-) If the Google tracker were an installable product like Bugzilla, it would be easier to measure who was voting with their feet. As it is, it's hard to say.

    Anonymous: Keywords are a fixed, global list, editable only by admins. Tags can be made up on the spot, and their meaning is assigned by convention.


  6. Bug tracking seems to be much less of a problem now than it used to be but, nevertheless, when things do go wrong and you really need it then you need it to work.

  7. I am envious of your skills. I have tried to learn Perl and although I mastered the basics fairly quickly I get bogged down when things start to get even a little bit complex.