Jira Vs Bugzilla

Today a co-worker sent me a link for Jira's Cash for Clunkers, a way to get the word out for the next release. At first I thought my co-worker was trying to say "hey we should use JIRA" (turns out he wasn't). But I think this is a thought lots of people have when it comes to picking bug/issue trackers. And I honestly don't think it is free to compare. In my mind it is like comparing the public library to the book store.

I love the public library. I get to go in and grab any book they have and read it for free(I pretend my taxes don't count)! Wow. That's amazing. But that's assuming someone hasn't checked out the book i want. Sometimes i have to wait for a book and sometimes I am too impatient and i just buy it from the Bookstore.

See the Bookstore has tons of books, not as large of a variety, but usually they have what i want. Often if I want a book they don't have, I can ask for it and they work hard to get it for me asap. Plus, i don't get some crappy fees if I'm late returning the book, because its mine.

I feel like the same thing is true of JIRA to Bugzilla. They are both great bug trackers, but their nature is totally different. You pay for JIRA (unless you're an open source tool) and no one (not even Mozilla) pays to support the development of Bugzilla. Lots of organizations and individuals donate time when they can, but there isn't any money being exchanged from a "bugzilla org" to other folks.

I feel like this by itself makes the comparison not exactly fair. Now if that philosophy isn't an issue and neither is money.

JIRA's UI is cleaner/nicer but not as geared around power users in many people's opinion, but it doesn't support the patch review process as nicely.

To be clear i've used both systems. There are PLENTY of super annoying little things (which maybe jira fixed in this next release). But as someone who has now come to understand JIRA really well and its limitations and understanding bugzilla and its limitations, I'd pick Bugzilla, but most people I work with, prefer JIRA every time.

Maybe JQL will fix the biggest JIRA issue, advanced search, but in the end, I like bugzilla because although admin UI for bugzilla is weird, I honestly find it easier to use (once I understand the mental model) than JIRAs. Oh... also, JIRA's email system makes me want to shoot somone, can't add other people to cc lists, and I couldn't for the life of me figure out how to turn off emails for specific bugs, it seems like some crazy all the things in a project or none... but that's again a personal issue.

But I'll continue to use JIRA at work, and figure out how to make work-arounds for "adding others to the cc-list" and other issues. But if you're reading this post as a way to find the answer to this question. Ask yourself this: is money not an issue? Do I have lots of novices using this tool? If the answer is yes to both of those, JIRA might be the way to go.

If you've got experts who will live with this tool every day, would prefer emacs, the command line and grep to Office, and want to be able to hack and slash their way to happiness... Bugzilla is probably your solution.

UPDATE ... Search is still horrible! doing a search for a bug with a specific owner between 2 relative dates results in "error" with no error message. OMG i miss Bugzilla. Plus quicksearch in bugzilla is GREAT @username gets me all their open bugs done... jira not so much. :(

my 2 cents

Bugzilla JSON-RPC Webservice with JQuery

I already posted how you can use YUI to use the Bugzilla web services available on the head. But lots of people don't like using YUI and prefer using JQuery. I haven't used JQuery much, but this experiment seems to have gotten the job done and should supply a basis for how to do more complex stuff with JQuery and the JSON-RPC interface.

Please note the JSON serialization capability isn't part of JQuery so I used a plug-in. The plugin doesn't seem to be as powerful as YUI's JSON serialization, but maybe it is and I haven't explored it enough. Anyway, here goes!

First you'll need JQuery and the JSON serialization parser. I added it under YUI but you should be able to add it before or after the YUI in the header.

    <script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js"></script>
    <script type="text/javascript" src="http://jquery-json.googlecode.com/files/jquery.json-1.3.min.js"></script>

Next comes the actual code which is very similar to the previous post.

First you create the JSON-RPC object:

var myObject = { "method": "Bug.add_comment", 
                 "params": [ { "id": 1, 
                               "comment":"I am using bugzilla's webservices with jQuery! YAY" 
                           } ], 
                 "id": 1 };

Then we encode it into a string:

var enc = $.toJSON(myObject);

Lastly we send it on its way using the JQuery ajax method:

$.ajax({"contentType":"application/json",
        "data": enc, 
        "dataType": "json", 
        "url": "jsonrpc.cgi",
        "type": "post",
        success: function(d, ts){
                    console.log('w00t',d); 
                    console.dir(d);
                 }
       });

Just like in YUI we need to make sure we set the contentType to application/json and use a post (get is still disabled due to cross site scripting concerns). I set the dataType to JSON so Jquery would deserialize the response for me.

And now we've got a basic JSON-RPC message being sent. Now we'll still need to handle errors etc, but for now this is enough to get any eager JavaScript developer going.

Another example is getting bug info which might be equally helpful is available below. This method gets information about 2 bugs. I'm not going to explain it as much but it follows the same pattern.

var myObject = {
               "method": "Bug.get",
               "params": [{ "ids": [1,2]}],
               "id": 1
               }; 
var enc = $.toJSON(myObject); 
jQuery.ajax({"contentType":"application/json",
             "data":enc, 
             "dataType":"json", 
             "url":"jsonrpc.cgi", 
             "type":"post", 
             success:function(d, ts){
                     console.log('w00t', d); 
                     console.dir(d)
                     }
           });

The hope is eventually to release some JavaScript plugins for YUI (2 and 3) and JQuery that will make this sort of stuff much easier, like handle the serialization, and errors. But for now these examples will have to do.

For more info about what Bugzilla web services are available check out:
http://www.bugzilla.org/docs/3.4/en/html/api/index.html

Next experiment... Jetpack! Any ideas on a cool bugzilla jetpack app?

Using YUI with Bugzilla 3.6

So today someone filed Bug 502504 and I immediately became nervous because I had never even tried using the new JSON-RPC api and I was worried it would be too hard to use for anyone.

Well after a few hickups I got it to work on my local machine as well as landfill and I thought I'd post the code and attempt to explain it.

First off you'll need to get a few YUI libraries, specifically the Connect Manager and the JSON library. For ease of my own use I just grabbed utilities.js, but that might be too much for some of you.

You'll need to set the Conent-Type properly:

YAHOO.util.Connect.setDefaultPostHeader( 'application/json', true );

You'll need to pick the Web Service you want to use by looking at the API here. Then you'll need to create the JSON to send over.

According to the JSON-RPC spec you send over an Object/Hash with 3 value pairs:

• method : the method you want to use, for this example we'll use Bug.add_comment
• params : the params the webservice docs say you need to send. The spec for JSON-RPC say it needs to be an array of objects, for Bug.add_comment is it just a hash of id and the comment and a few other optional things
• id : an integer, the id of the call so you can match it up later on, YUI should make it so we don't need to worry about this one, but you might care.

Here is the Object definition for the example...

var myObject = {
    "method": "Bug.add_comment",
    "params": [
        {
            "id": 1,
            "comment":"I am using bugzilla's webservices! YAY"
        }],
    "id": 1
};

and then we'll stringify it using YAHOO.lang.JSON.stringify.

var jsonObject = YAHOO.lang.JSON.stringify(myObject);

Now hopefully you know how to use the callback in YUI. If not there are plenty examples.

Finally you call it!

YAHOO.util.Connect.asyncRequest('POST', 'jsonrpc.cgi', callback, jsonObject );

So in this example I added a comment to bug 1, and that comment is "I am using bugzilla's webservices! YAY"

That's it! The full code that I used is below. I was using firebug so you should change the console commands to whatever you want to do with the response:

YAHOO.util.Connect.setDefaultPostHeader( 'application/json', true );
var callback = { 
    success:function(o){     
        console.log('it worked');
        console.dir(o.response); 
    },
    failure:function(o){ 
        console.log('it failed');     
        console.dir(o); 
    }};
var myObject = {
  "method": "Bug.add_comment",
  "params": [
      {
          "id": 1,
          "comment":"I am using bugzilla's webservices! YAY"
      }
  ],
  "id": 1
};
var jsonObject = YAHOO.lang.JSON.stringify(myObject);
YAHOO.util.Connect.asyncRequest('POST', 'jsonrpc.cgi', callback, jsonObject );

Another example for those who would like one...

YAHOO.util.Connect.setDefaultPostHeader(  'application/json' );    
var obj = {
     "method": "Bug.get",     
"params": [         
{             "ids": [
                 1,
                 2
              ]
          }
      ],
     "id": 1
};
var jsonObj = YAHOO.lang.JSON.stringify(obj);
YAHOO.util.Connect.asyncRequest('POST', 'jsonrpc.cgi', 
    {   success:function(o){     
            console.log('it worked');
            console.log(YAHOO.lang.JSON.parse(o.responseText)); 
        },    
        failure:function(o){     
            console.log('it failed');     
            console.dir(o); 
        }   
    },  jsonObj);

Lots of Design Feedback and Bugzilla Usability Data

There has been a lot of interest in the Bugzilla UI recently, which I'm super excited about. Attending usability conferences like CHI, I'd often hear about how hard it is to get any interest in usability or design in the open source community for various reasons (1, 2, 3, 4).

However, thanks to the post that LpSolit posted, many designers at Mozilla have stepped up with improvements to the Bugzilla UI, there is Boriss's suggestions for a new UI as well as Fligtar's new skin. Even a graphic designer from Spread Mozilla, graphicguru, stepped up to help improve my pathetic attempt at graphics(1,2,3). We've gotten some developers, like SS, to give some very useful feedback about how he'd prefer a more minimalist skin in general. And to top it off there has been feedback about new ways to think about the workflow from Jesse. Not to mention the meeting we had with the some of the Mozilla designers about future directions for Bugzilla, as documented by Aza. And today we had a small meeting with even more Mozilla folks about how they thought the tool could be improved. We're hoping to have more meetings in the future with Mozilla developers and get even more thanks to Jono.

It's been extremely exciting it is to see so many people interested in the Bugzilla UI. I'm hoping that with all these ideas you all can expect to see many design and usability improvements in future versions of Bugzilla.

But as my professor Bonnie John would say, one shouldn't design or develop without data. Turns out Mkanat, and many of the Mozilla folks feel the same way! And thanks to a very dedicated and smart group of HCII Carnegie Mellon students we've got usability data. This data was collected this past fall on Bugzilla 3.0, and I've attempted to post their research more or less unedited from their project to the Bugzilla wiki.

I haven't had a chance to look through and write an executive summery/conclusion to all their great data, but I thought to post it without one and perhaps let you all peruse the data and supply me with your important take aways from the data. This research was not based on how people use Mozilla's Bugzilla, but how people use bug trackers in general at software companies and other domains.

Let me know what you think of the data, what takeaways you find and what conclusions you draw from the data and maybe I can crowd source this task conclusion writing task.

Unfortunately Bugzilla 3.4 is going to be out the door pretty soon, and we won't be able to get many of these improvements into this version, but maybe we will see some of the improvements suggested this past week as well as ideas from the usability research appear in 3.6 or later versions of Bugzilla.

Again thanks to everyone who has become interested in redesigning Bugzilla, keep the designs and ideas coming! Feel free to email me when you've got ideas or designs and maybe we can work together to get the ideas into the source.

A new Login Form for Bugzilla

So we've gotten lots of great feedback on the homepage, it's been really helpful and we're talking to folks about redoing the icons, making sure that the big icons are the right choice and much more. Wait for a post to find out more about the future of the homepage!

But we're also working on the log in process, attempting to make that easier as well!

Here is a view of the current log in form as it exists on the head.


One of the problems with this UI is that you can't reset your password very easily from this page, or any other page really. The nice part is, you can log in from any page, and not have to go through some intermediate page.

So here is the solution we've though of to make it easier to reset your password or log in from any page in Bugzilla.

How it appears if you've never come to the page


What happens when you click on log in, cursor focused on the log in. This is also what happens if the browser auto fills in your username and password.

This is what you'll see if you click on the forgot password link.


I omitted a close icon for now because it didn't seem necessary, but maybe you guys think it is. Let me know!

We're also adding a link to the reset password on the bad username/password error page.

One more thing to note about how this form will work. If the browser auto-fills your username and password, we'll make sure the javascript on the page detects your username and password and displays them to you, so you don't have to click the login hyperlink to login. We're hoping this will maintain the 1 click to login capability that so many people like.

This isn't something that will magically make Bugzilla super easier to use, but hopefully this will take us one step closer to a more usable Bugzilla.

As always feedback is really appreciated and unlike my previous post, I'll get emailed when you guys comments, so hopefully i can respond to your feedback in a more timely manner. Can't wait to hear your opinions.

Bugzilla's new UI for Index.cgi

Bug 475063 is an enhancement to "Make the logged-out index.cgi simpler". After a few chats with Max Kanat, I've mocked up and submitted a patch to do just that.

Right now the patch looks like this.

Since this is a major change to the Bugzilla UI I'd love to get some feedback about this!

A few things to note:

There have been some discussions about how Buggy should look, with a pupil or without, more recongnizable or less, or even if we should use him at all. So that's in a state of flux.

Also for the dusk skin this UI will look the same, just set to the monocrome of Dusk.

For those wondering "what about the login box on the homepage?". There is another bug to improve that and make it easier to log in from any page! Bug 476090 will allow users to login directly from any page without needing to leave the context that they are in. Hopefully in the future we'll be able to do this ajax style to avoid having to leave the page at all.

Can't wait to hear your feedback about both of these bugs.

Google Chrome, no Undo Close Tab?!?

I was a bit shocked when Google chrome came out without an undo close tab. Google and NASA helped Mozilla do a lot of research for Firefox 3 on how people use tabs, so I would have thought that Google's browser would have incorporated one of my favorite features that were designed for this purpose, undo close tab!

Granted it might be one of the least well known features in FF3, but I think it rocks. I close the wrong tab at least once a day, and it's mostly b/c i get over eager clicking the close tab or control-w.

The point is, making everything in a browser undo-able is super useful, I wish it would be made a full fledged feature instead of something you can only get to by right-clicking on the tabs that remain.

So Google, take your own advice to other browsers and add an close tab to the undo stack... please?