PKB

One of the most important tools we use at Mozilla for day-to-day work is Bugzilla. Bugzilla is an open source bug tracking system that was created back in 1998 by Terry Weisman at Netscape, to support mozilla.org (see the Wikipedia article for more background).

I wanted to share my experiences as a non-developer (read “token marketing guy”) at Mozilla who’s come to appreciate how useful Bugzilla is for exposing problems, inviting community input, and tracking tasks through to completion.

This isn’t intended to be a comprehensive overview of using Bugzilla. I’m focusing on how I use Bugzilla for a set of marketing related tasks, mostly related to the work we do on mozilla.com. Hopefully this will be helpful for new non-devs here at Mozilla.

Getting started
OK, full disclosure. The first time I logged onto bugzilla.mozilla.org (BMO) I was overwhelmed. So many form fields. Arcana in spades (”Blocking 1.8.1.4″ - what did that mean?). Luckily I had a friendly guide to help me get started.

BMO’s primary purpose is to track defects in Mozilla products, and to help developers resolve them. It’s been adapted over time to enable reporting of bugs in Mozilla web sites, including mozilla.com, spreadfirefox.com, and mozilla.org.

The first thing you’ll need to do is register an account on BMO. Go to https://bugzilla.mozilla.org/createaccount.cgi and follow the instructions there to create your account.

Read up on Bugzilla etiquette to get a better understanding of guidelines for using BMO.

Reporting a bug
You’ve found a problem on a Mozilla web site that you want to report. Start here: https://bugzilla.mozilla.org/enter_bug.cgi?product=Websites

Let’s walk through the parts of the bug reporting form.

First select the site you’re reporting an issue on in the Components field.

The platform and operating system you’re using will be pre-selected for you. If your bug affects multiple hardware and OS’s, select “All” for both of these options.

You can also set the severity of the bug you’re reporting. Generally speaking, unless the bug is really, really serious, leave this set at the default of normal.

Now for the main event. Enter the URL, summary and description of the bug. Be as specific as possible in describing the issue you’re encountering. This helps the folks who are receiving the bug diagnose and respond to the problem. Here’s a sample, with a description inserted from a recently filed bug for mozilla.com.

If you want to attach a screenshot of the problem you’re seeing, click on the “Add an attachment” button and follow the instructions on uploading the attachment.

You also have the option of marking your bug as confidential. The default should be to keep the bug open and accessible to everyone who accesses BMO. There may be situations where it’s necessary to restrict access to the bug — if that’s the case you can do this by selecting one of the groups listed on the bug form.

OK - you’re ready to file your bug. The last step is to hit the “Commit” button.

Your bug is now on record and folks in the Mozilla community have been notified.

Reviewing bugs
If you’re on the receiving end of a bug notification, you’ll most likely be notified by email. You can modify your email settings for bugmail here: https://bugzilla.mozilla.org/userprefs.cgi?tab=email

I look at every piece of bugmail I get, and also use a BMO query to review open web site bugs.

43 open bugs. Time to get back to work. :-)

Last words
Learning how to use BMO has helped me be much more productive since I started working for Mozilla. I’m interested in further adapting BMO to accomodate broader marketing projects beyond our web sites. Let me know if this was helpful, or if you see anything here that needs correcting.

8 comments

We’re having a great time here in Austin at SXSW. Polvi, Rhian, Mary and Jonas were at the Mozilla booth today and convinced many, many people to display their love for Firefox. A longer update soon, once the lightning storm ends.

Update: Just posted some more photos of our booth and the local Austin scenery.

1 comment

I’m heading out to SXSW Interactive this weekend, joining a crew from Mozilla. Brendan Eich is speaking on a panel on the future of browsers with Arun Ranganathan (AOL), Charles McCathieNevile (Opera), and Chris Wilson (Microsoft) on Tuesday, March 13.

This is the first time Mozilla’s participated in a significant way at SXSW. I’m excited to meet up with community members who’ll be at the show, and to connect with Web designers and developers who’ll be there. We’re hosting a barbecue and meetup Monday night 6-9 pm at Brush Square Park, with our friends at Democracy.

Austin’s an amazing place. It’s a truly unique vibe, up there for me with SF, NYC and Portland (in the US) in terms of how comfortable it feels to be there. Yet with its own inimitable places, climate and people. I’ve been once before, and can’t wait to get back out.

If you’re part of the Mozilla community and want to join us for our meetup, email Rhian Baker to get on the guest list for our Monday night shindig (if you’re attending SXSW, you’re all set already). Definitely check out John Resig’s recommendations on panels of interest at the conference.

And, let me assure you, my trip out has absolutely nothing to do with my affection for Douglas Coupland or Slacker.

2 comments