a non-developer’s guide to using bugzilla
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 so far
photos
music
bookmarks
tumblr
Yes, this was very helpful.
I remember how intimidated I was by the whole process when I filed my first bug 2 years ago.
I thought that it was only for developers and I was afraid I’d mess something up.
Come to find out, it ended up being a fairly popular bug. Can’t copy and paste in Firefox which gave me a bit of comfort and confidence knowing that I filed properly.
But it’s been a while since I’ve submitted one and I’m grateful for the refresher course because now I can contribute once again.
Thanks for the feedback Ken. It occurred to me today that learning how to use Bugzilla might be a good thing to share with the non-developer community.
Hey Paul,
Great write-up. Have you thought about knocking together a video version some time? I imagine it might help you reach a broader audience, and would probably not be overly onerous to put together. I’ve thought more than once that once I get the codebase firmly into my head, I’m basically duty-bound to put together a 10 minute “Intro to firefox for programmers” video. [1][2]
Just a thought for us both, sometime when we don’t have a million other things on the go.
Cheers,
J
[1] There are a couple of these out there already, in various forms - mostly recordings of brown bags or other intro talks by people like Johnny S. The problem is that they a) tend to focus more on gecko core than the XUL/JS front end, and b) are not optimal for video presentation (whiteboard diagrams don’t come through very well, for instance).
[2] And yes, I realise that my video would be intended for a more technical audience than yours. I guess I’m just thinking that, in general, this internet video thing seems to be sort of popular with the kids these days. :)
Indeed, it was a very good idea to write such an introduction. In fact, why not have a ‘Help’ button in bugzilla, or some write-up more permanent than a blogpost?
@ johnathan: they have video on the internets now? crazy! ;-) i love the idea of doing a set of video tutorials. let’s talk about this more during the onsite next week.
@ bram: there’s already longer lived content on the mozilla developer center on filing bugs at http://developer.mozilla.org/en/docs/Bug_Writing_Guidelines. i don’t know if we have a guide to bugzilla for non developers on spreadfirefox.com; my hunch is probably not. this is a good suggestion. thanks.
bugzilla intro…
I’m not sure how I missed this when Paul put it up. If you’re not a developer and you want learn how to get started using Bugzilla, check it out. Nice work, Paul. Slightly oudated, but still a good reference, Sean’s How to find out if your bug is al…
Weissman I belive, sssssssss.
[...] people in various roles on a software project has and is still awkward. Mozilla Marketer Paul Kim describes his first experience with Bugzilla as overwhelming and was grateful to his colleague (ironically) Mozilla Design Lead Mike Beltzer to guide him [...]