FFUntriaged number games

As some of you may know we have over 900,000 thousand bug reports in bugzilla.mozilla.org these days. Around 120K of those are open bugs.

I keep an eye on the incoming bugs, which are still around 350-550 for any 24 hour period and peck away at those. Many people in QA and various engineering teams also keep watch over the incoming bugs so that problems are caught quickly, escalated appropriately, and stuff gets fixed and released as soon as possible.

But the incoming are just one thing among many. Lately I’ve been working on a fairly arbitrary goal. That is to bring down a specific number, the bugs filed for Firefox that are in the “Untriaged” component, where the last comment was by the person who reported the bug. I have it on my todo list as “FFUntriaged”, so I think of it that way. FFUN! (I’m sure that is unconvincing…)

Bugs on a laptop

When I started putting half an hour to an hour a day into this, the count was well over 500 bugs. Now it is closer to 400. I answer some from the front of the queue and some from the tail end, which right now goes back to February 2012. The older, 2012 bugs are mostly obsolete at this point, but I have caught a few that are still valid, and that are now categorized in a product and component that brought them to the notice of the developers who may already be working on similar issues.

Of the bugs that I end up closing, a bunch of them probably should have been support questions in the first place. I resolve them INVALID if they are reallky support questions because they aren’t and weren’t bugs in Firefox. If I can’t tell what was going on, and the reporter doesn’t answer my “needinfo” query, I can resolve the bug INCOMPLETE since there was never enough information to tell if it was really a bug or not.

A few of these long-untriaged Firefox bugs ended up in the RESOLVED WORKSFORME status, which I think of as: when the bug was reported, no one was able to reproduce it, I can’t reproduce it now, and maybe also the original reporter can’t reproduce it. Maybe it got fixed along the way. It doesn’t seem important enough to anyone to pin down exactly what fixed it. It just works now. Resolving it seems ok to me, since that doesn’t erase any history: the bug report is still findable if it comes up again.

The FFUNtriaged bugs project has been fairly satisfying just to watch the number come down over time. Pretty soon we will have it down to something reasonable, like under 30, and actually recent bugs instead of cruft from a year ago. Then I’ll pick a new little project!

And now a digression about duplicate bugs.

A few bugs from FFUNtriaged end up being marked as duplicates. I catch a few, but more often someone more experienced notices the duplicates after I do something else with them, which sends bugmail or puts a report into a new product or component. Some reports just sound like they must have been reported before. DUPing them is a good way to establish connections and direct the original bug reporter to where the action or discussion is. There is good advice in Screening duplicate bugs article on MDN.

There is not only a Most Frequently Reported Bugs list, there is also now a whole dashboard which can show most duped bugs by product. The one I have been looking at a lot recently is the most duped list for Core::Layout bugs. The product dashboard doesn’t let you limit by time though. So I still think the main Most Frequently Reported Bugs page is more useful; you can change its query to limit it by product, or view it as a regular (sortable) bug list.

In theory the better we get (collectively) at duping bugs, the more useful the lists of most-duped bugs will be. It may be a self perpetuating cycle though, to where we learn the most-duped ones, then dup more bugs to them. I have thought before it might be fruitful to hunt after (or ask someone for a lead to) closely related bugs and sort through them to see if any are obvious dupes.

Things I know about automatically as dupes are: anything involving shortcut keys. Layout complains about tables and images. Anything to do with bookmarks. All those are worth a search and a quick scan of a list of bugs with similar words in the summary and then a bit of digging!

Sometimes people are a bit upset that “their” report gets
duped to an already existing bug. I don’t have enough experience (after 8 months triaging) to really have a sense in the patterns of what gets fixed and why. But when a bug is duped to an older one, the people who get bugmail on that older bug are going to get a poke of some kind, so at least that brings the issue to possible attention. And over time, it may affect how teams or engineers set priorities or figure out what to fix or escalate. So I think it it likely useful.

Related posts:

FFUntriage number games

As some of you may know we have over 900,000 thousand bug reports in bugzilla.mozilla.org these days. Around 120K of those are open bugs.

I keep an eye on the incoming bugs, which are still around 350-550 for any 24 hour period and peck away at those. Many people in QA and various engineering teams also keep watch over the incoming bugs so that problems are caught quickly, escalated appropriately, and stuff gets fixed and released as soon as possible.

But the incoming are just one thing among many. Lately I’ve been working on a fairly arbitrary goal. That is to bring down a specific number, the bugs filed for Firefox that are in the “Untriaged” component, where the last comment was by the person who reported the bug. I have it on my todo list as “FFUntriaged”, so I think of it that way. FFUN!

Bugs on a laptop

When I started putting half an hour to an hour a day into this, the count was well over 500 bugs. Now it is closer to 400. I answer some from the front of the queue and some from the tail end, which right now goes back to February 2012. The older, 2012 bugs are mostly obsolete at this point, but I have caught a few that are still valid, and that are now categorized in a product and component that brought them to the notice of the developers who may already be working on similar issues.

Of the bugs that I end up closing, a bunch of them probably should have been support questions in the first place. I resolve them INVALID if they are reallky support questions because they aren’t and weren’t bugs in Firefox. If I can’t tell what was going on, and the reporter doesn’t answer my “needinfo” query, I can resolve the bug INCOMPLETE since there was never enough information to tell if it was really a bug or not.

A few of these long-untriaged Firefox bugs ended up in the RESOLVED WORKSFORME status, which I think of as: when the bug was reported, no one was able to reproduce it, I can’t reproduce it now, and maybe also the original reporter can’t reproduce it. Maybe it got fixed along the way. It doesn’t seem important enough to anyone to pin down exactly what fixed it. It just works now. Resolving it seems ok to me, since that doesn’t erase any history: the bug report is still findable if it comes up again.

The FFUNtriaged bugs project has been fairly satisfying just to watch the number come down over time. Pretty soon we will have it down to something reasonable, like under 30, and actually recent bugs instead of cruft from a year ago. Then I’ll pick a new little project!

And now a digression about duplicate bugs.

A few bugs from FFUNtriaged end up being marked as duplicates. I catch a few, but more often someone more experienced notices the duplicates after I do something else with them, which sends bugmail or puts a report into a new product or component. Some reports just sound like they must have been reported before. DUPing them is a good way to establish connections and direct the original bug reporter to where the action or discussion is. There is good advice in Screening duplicate bugs article on MDN.

There is not only a Most Frequently Reported Bugs list, there is also now a whole dashboard which can show most duped bugs by product. The one I have been looking at a lot recently is the most duped list for Core::Layout bugs. The product dashboard doesn’t let you limit by time though. So I still think the main Most Frequently Reported Bugs page is more useful; you can change its query to limit it by product, or view it as a regular (sortable) bug list.

In theory the better we get (collectively) at duping bugs, the more useful the lists of most-duped bugs will be. It may be a self perpetuating cycle though, to where we learn the most-duped ones, then dup more bugs to them. I have thought before it might be fruitful to hunt after (or ask someone for a lead to) closely related bugs and sort through them to see if any are obvious dupes.

Things I know about automatically as dupes are: anything involving shortcut keys. Layout complains about tables and images. Anything to do with bookmarks. All those are worth a search and a quick scan of a list of bugs with similar words in the summary and then a bit of digging!

Sometimes people are a bit upset that “their” report gets
duped to an already existing bug. I don’t have enough experience (after 8 months triaging) to really have a sense in the patterns of what gets fixed and why. But when a bug is duped to an older one, the people who get bugmail on that older bug are going to get a poke of some kind, so at least that brings the issue to possible attention. And over time, it may affect how teams or engineers set priorities or figure out what to fix or escalate. So I think it it likely useful.

Related posts:

File a bug: the missing manual, now with unicorns

At countless conference talks I have heard standard advice on “how to get involved in an open source project”. It goes something like this:

Step 1. File a bug!
Step 2. Submit a patch! (repeat steps 1 and 2 for a while)
Step 3. Now you are ready to write some new features and stuff! Fly and be free!

I always thought that was interesting because it is an attempt to reassure people that you don’t have to leap into immediate coding. Just file a bug, that is the first step. This results in people coming into projects and wondering vaguely how to find bugs.

Part of what I want to do as bugmaster for Mozilla is to put in another step — look at the bugs already reported, since there are a squizillion of them, and see what you can do to improve the meta information of those bugs.

Today on Planet Mozilla I noticed some really good advice from Jason Smith on how to find bugs: WebRTC testing: Try out conversat.io and file bugs. It is really sensible and practical. Jason’s blog has a few posts like this that advise focus in a particular area, like WebRTC or Desktop web apps, by incorporating use of those tools in your daily life. Our “get involved in open source” sequence now looks more like this,

Step 1. Find some feature that could use testing.
Step 2. Figure out how to use it regularly.
Step 3. Use it.
Step 4. Encounter behavior you think is a bug.
Step 5. FILE A BUG (BUT HOW?)

There is a lot of background knowledge necessary to actually file a bug in the complicated system that is bugzilla.mozilla.org (or BMO).

So let’s take the WebRTC example. Say you’ve followed Jason’s advice, used conversat.io for a while, and found A BUG. Jason helpfully provides a link directly into Bugzilla to the enter_bug form, with the Product and Component pre-filled out to be for a bug with WebRTC (the component) and Core (the product.) Bugs in BMO are categorized according to Product, like Firefox Desktop, Firefox for Android, FirefoxOS, Thunderbird, etc. “Core” is the product for the code that is shared between many other products. If you were looking to file a bug with WebRTC from scratch you would probably not know which product to file it under, though you have to choose one. So it’s great that Jason gives a link to the right product and component!

But wait. There is so much more background, or context, to understand. You don’t have to, but it is very good to understand it!

First of all you have to have a bugzilla account for the link to work properly. If you do that, you will be a new bugzilla user, and some of the bug entry forms will look different to you — you’ll be automatically directed to a “guided bug entry form” which is broken into several steps, rather than the form that shows you the whole “advanced view” with several dozen fields and dropdown menus.

Second, how about looking at the list of all the components in the Core product. This is a good part of the background knowledge – a little piece of the map or geography of Bugzilla. As you can see, there are a lot of components that are part of Core. Scrolling down to the WebRTC bit, you can see that there are several sub categories: WebRTC, WebRTC:Audio/Video, WebRTC:Networking, and WebRTC:Signaling. Click on the general WebRTC component to see a list of open WebRTC bugs. This is where your geography lesson gets useful.

Right now there are 113 open bugs for WebRTC. You might look over them simply to get an idea of what kinds of bugs others have found. More about this later!

The important thing at this moment is: Is your bug already reported? Depending on how many bugs there are in this list, and your levels of interest and patience, you might want to either quickly read through the summaries (the title of the bug) or do a search down the page for words that might be in the bug you’re about to file.

If you find something in that list that you think is your bug, take a closer look at it. Read it and the comments and try to understand what they’re talking about. If it is the same as your bug, you may want to leave a comment describing what you saw happen.

But let’s say you don’t find your bug on that list. Aha! Here we use the File a bug link from the original blog post, link to file a bug with WebRTC. If you are me, or a user of Bugzilla who has made more than 25 edits or comments to bugs, you will see the advanced bug entry form, which is huge (you can see it from space) and looks like this:

Enter bug webrtc advanced

If you are a relatively new user of Bugzilla, you’ll come first to a guided entry form, broken into several screens. (At any point, you can switch to the advanced entry form with a link at the bottom of the page, if clicking through multiple screens annoys you.) The first screen for guided bug entry would normally be for selecting the product and component. Since you have these already chosen in Jason’s convenient link, you start on Screen 2, where you can enter the summary for your bug. In this case I am reporting a sort of unicorn invasion:

Enterbug webrtc screen2

After you enter a summary you will see a list pop up underneath the summary field, of bugs that may be similar. It is worth reading through those to see if anyone else has reported unicorns invading their conversat.io screens in Firefox. In this case, definitely not.

Enterbug webrtc screen2 list

Since no one else has reported this bug, I click the “My issue is not listed” button, and advance to screen 3, which suggests how I can describe my actions or steps to reproduce the issue, exactly what happened that I think is a bug, and what I think should have happened instead.

Enter bug screen3 unicorn jpg

Great, we have filed a bug! Back to that list of “how to contribute to an open source project”:

Step 1. Find some feature that could use testing.
Step 2. Figure out how to use it regularly.
Step 3. Use it.
Step 4. Encounter behavior you think is a bug.
Step 4.5 Make a bugzilla.mozilla.org account.
Step 4.6 Confirm it with the email confirmation.
Step 4.7 Log in to bugzilla.mozilla.org.
Step 5. FILE A BUG (which we now know how to do!!!)

But wait, there’s more — or there can be if you want to get your bearings on that map of Bugzilla. Take a look back at the list of all the general open WebRTC bugs. What can we understand from this list?

As I look over the current list it is pretty mysterious. From the language in the summaries, I would guess some of the bugs are notes by the development team for their own to-do list, and some of them look like bugs discovered by general users of the software. My first impulse is to sort the page a few different ways to see what that reveals. Sorting by Status shows the UNCONFIRMED bugs at the top and the NEW bugs listed just underneath. There is one titled getUserMedia freeze all system that isn’t confirmed yet and may be a good example.

Here is an interesting one, No event when remote peer disappeared. My view of this bug is going to be different from yours, if you are new to Bugzilla, because I have more magic powers, ie, canconfirm and editbugs permissions, as well as some extra admin stuff. There is a lot of stuff on the page. It’s extremely “busy” with text! You have to learn to skim it and parse it mentally so that you can see and notice the stuff that is important to you at the moment. Here is what this bug looks like for a new Bugzilla user.

Example webrtc bug2

What I can see from reading this bug is that there is at least one person actively looking at newly filed bugs, triaging them, and working on the project. And in fact as I click around and read more of the bugs for WebRTC I can see Jason is actively engaged with most of them, which is not a big surprise since he is blogging about the subject.

Jason’s blog looks like a quite useful place to find out areas that welcome testers and bug-finders. You can also look at the QMO quality assurance and testing pages which explain how to run nightly builds and participate in QA’s bug test and triage days.

My bigger point here, though, is that to start contributing to an open source project, aside from reporting one-off bugs you accidentally discover, it is super helpful to learn the landscape of the project. Adopt the project and poke around to learn about it. If you are reporting a bug, look at the other bugs. Look at who is commenting and working on those bugs. Join their IRC channel and read their wiki pages and (usually more formal than the wiki pages…) developer documentation. Or simply google the project to learn more about what’s going on with it. In this case I found that conversat.io is quite new and was developed partly to show off what WebRTC is and what it can do.

It was really apparent, from my morning of poking around, how much transparency there is at Mozilla, and the amazing technical depths you can get to from half a day’s reading and bug surfing. As a society we really have yet to realize the implications for education and educational institutions. It is a major cultural shift I am happy to be part of.

Related posts:

Bugzilla hijinks, Tuesday March 5

Tomorrow evening (Pacific time) the bugzilla.mozilla.org and IT folks will be moving BMO to a new infrastructure and upgrading to Bugzilla 4.2.

No bugzilla cartoon

I’ll be up on the 7th floor of the SF office with Shyam and probably others. I know a few comunity contributors will be showing up on IRC around 8pm PST to help test during deployment so if you’d like to participate, let me know!

Earlier on Tuesday, before the outage, there will be a QA-run Firefox unconfirmed bugs day. This is a good event for people new to bugzilla and bug triage! Create a bugzilla.mozilla.org account for yourself and come introduce yourself on irc.mozilla.org on the #qa or #bugmasters channels.

I plan on going through all the Mac bugs that I’m able to, to try to replicate them and add any useful information to the bugs. Right now there are 85 unconfirmed Firefox bugs that were first reported in the last week. That number might be different tomorrow obviously!

I find it very useful in Bugzilla when I get a link to a search like this one, to click “Edit Search” at the very bottom right of the page. From that, I can see what options created that result. And I can narrow the search down further or build something useful for myself, and then save it in my saved searches. Now I have a nice search for just the recent bugs reported for Firefox on MacOSX. I mention this mainly because it took me a while to notice the “Edit Search” link — until then, I was trying to deconstruct and add to the parameters in the URL by hand.

At 8:30pm the Bay Lights are going to come on: a dynamic light show decorating the whole north part of the San Francisco Bay Bridge. I’m hoping to get some awesome photos of the lit-up bridge from the Mozilla office roof. It looks basically like thousands of blinky christmas lights all over the bridge along with some sort of giant arduino mastermind program. It is nice that the bridge will be known for something other than “3rd most destroyed bridge in disaster movies throughout the ages”.

Related posts:

Walking through early bug triage

Here is a good example of a bug that went through several stages of triaging:
Scrolling a page up leaves residue in GTK slider
. I would like to walk through what happens in triaging this bug. Blow by blow report!

The bug reporter, Przemek, was new to Bugzilla, so their report was automatically put into the UNCONFIRMED status. The bug summary (the title) was originally “artifacts on scrollbar in seamonkey 2.15” and it was put into the product Seamonkey and component General. (Here is a list of Seamonkey components, if you’re curious.) Przemek attached a screenshot of the problem. At the bottom right corner of the screenshot you can see the scrollbar has some weird stripes on it.

Scrollbar bug screenshot

Matti suggested a possible duplicate bug. That shows us a related problem and which product and component it might belong to. It also can reveal some people who work on this type of issue.

Another commenter, Slim, relatively new to Bugzilla, chimes in to say they have exactly the same issue, in Linux and that it may be a GTK problem. They include the information from about:buildconfig .

A fourth person, Philip, asks if someone who sees the problem (either the reporter or Slim) can try toggling a preference. Slim tries it but it doesn’t fix the issue. He speculates it is related to Bug 297508. Philip uses the NEEDINFO flag to ask Przemek a question (this emails Przemek with particular Bugzilla mail headers). Przemek replies, which
automatically clears the needinfo flag. Philip then decides to move the bug from the product Seamonkey to “Core”. component General to Widget: Gtk. That shows up as General -> Widget:Gtk in the comments.

Cotton Harlequin Bugs

One week later, Karl shows up in Comment 10. If we look at the list of module owners and peers for Mozilla, we can see that he is the owner for Core::Widget:GTK. I figure he was probably was looking at bugs in that area, or reading his bugmail backlog. There are 328 bugs UNCONFIRMED or NEW for Core::Widget:GTK, which you can see if you do an Advanced Search. Anyway, Karl reproduces the bug and moves its status from UNCONFIRMED to NEW. He added the keyword, “regressionwindow-wanted”. The next day he comes back and adds some info about the regression window and removes the “regressionwindow-wanted” keyword. narrows that window even further. He then moves the bug to
Core:: Layout
and adds the keyword “regression”. It is probably out of his hands now. But whose it it in?

There are over 2300 open bugs in Core::Layout, 1809 of them new and not assigned to any particular person. If I look to see how many of them have the keyword “regression” there are only 140, most of them assigned to “nobody”. So if I wanted to fix something in Core, that might be a good place to look for a bug that needs attention.

All the commenters described here were doing bug triage or what I am now calling bugmastering. Five people, two weeks. I think all their efforts and comments were useful in moving the bug along and adding new information to it. It is also instructive (and for me, reassuring) that not everything was “right”, right away. Actually, I think it’s beautiful to see how well everyone communicates, much of the time in Bugzilla.

At this point, if Bugzilla had the READY status implemented, I would call it READY. Not just to signal to developers that it is ready to be worked on, but to signal to other triagers that it may be done and they don’t need to keep looking at it. That is part of why having a clear demarcation point will be useful. Even though there is more than could be done, this is probably enough for someone knowledgeable to take it and work on it. I would consider its “early triage” life to be over and for it to be in the hands of engineering, QA, and rel-eng, who have their own models for triaging internally for their stages of handling the bug.

Now, that doesn’t mean that as your Mozilla Bugmaster, I can blithely ignore all bugs once they are done with early triage. Yet since this is a minor layout bug that does not seem to affect function I think I can let it go and hope that someday it is fixed.

It is possible that we could make some cruft-killer searches, reports, or other views that could pick up this sort of bug 6 months from its first reporting, and do anohter check to see if it still exists. If it’s been cleared up in the meantime, make a comment mark it RESOLVED WORKSFORME. Right now I’m sure some people have figured out good systems to do this, but I think most people stay focused on what’s incoming or what is especially brought to their attention. Re-assessing old bugs, or bugs within a particular time window (6 months to a year old, but not 10 years old) may be a good way for beginning bugmasters to start chipping away at some of the cruft in the system.

Related posts:

Bugzilla quicksearch, or else!

Here is a fabulous tip if you are messing around in bugzilla.mozilla.org and are searching for bugs. As, by now, as a reader of my blog, you should be.

You can search Bugzilla right from the location bar. I cannot quite bring myself to say “Awesome bar” as people do at Mozilla because I’ve said “location bar” for many years, and it feels silly.

First you will need to be logged in to a Bugzilla account!

Right(command)-click in the Search box. Choose “Add a keyword for this Search”.

Pick something short that you will remember, like “b” or “bug”. I added both since they both seem intuitive enough to me that I’ll probably forget choosing one or the other.

Command-L is the keystroke on a Mac to move to the location bar.

So, type Command-L, type bug 831552 and you will be whooshed directly to that bug.

Command-L, bug retina will result in a fairly quick list of around 18 bugs (as of right now.)

Here are a bunch of quicksearch tips for bugzilla.mozilla.org!

Take a look at the tips and see what quicksearch looks at by default. There is lots of useful info there and it is worth going through and trying some of the options and noting which field names might be specially useful.

The Advanced Shortcuts are the best thing about quicksearch for me so far. For example, Command-L, bug UNCO retina returns all the unconfirmed bugs with the keyword “retina”. (About 4, currently). Though keywords aren’t case-sensitive, the Advanced shortcut “Status” search terms are. So you have to type bug UNCO retina, not bug unco retina.

At the moment, quicksearch look in comments and various other bug metadata. After January 24th that will change — comments will be excluded by default from quicksearch. That should make it actually quicksearch instead of kinda_slow_search. Or at least quickersearch. Until then, you can type bug --comments retina and your search about retina-related bugs will be a bit faster.

Here is the “or else” part from the title of this post: If you have been calling yourself “The Bugmaster for Mozilla” for several weeks, and you slowly mouse over to a search box to type something, and you do this in front of some kick ass developer, instead of using quicksearch in the location bar, you will be embarrassed. So take it from me and don’t do that.

cats in hats

Related posts:

Thrills, chills, filters, and bugmail

Any bugmail at all is probably way too much bugmail. That means you will need to set up some structures to filter it!

This explanation may be useful for anyone interested in contributing to Mozilla — especially bugmasters, triagers, and developers. Even if you don’t use the same email setup, there’s some good tips.

Byron (aka glob) explained how I could set up my Bugzilla email, or bugmail. Within Bugzilla, in the Email preferences tab, there are a complicated set of checkboxes to control what conditions in Bugzilla trigger your bugmail. Right now, my email notifications are set to fire off email to me whenever anything happens to a bug I may be interested in.

Bugzilla email prefs

I then set up some users to watch, at the bottom of the Email preferences screen. Whenever Matti, Tyler, or Benjamin do anything with a bug, Bugzilla emails me about it. I can also see that Josh is watching my Bugzilla activity. People often refer to this as “stalking” in Bugzilla, without any creepy connotation intended. It is basically TMI about someone else’s bugs (or what bugs they poke at.)

Bugzilla user watching

“If you watch a user, it is as if you are standing in their shoes for the purposes of getting email. Email is sent or not according to your preferences for their relationship to the bug (e.g. Assignee).” The meaning of that takes a while to work out, much like Bilbo Baggins’ famous statement at his eleventy-first birthday party… “I don’t know half of you half as well as I should like; and I like less than half of you half as well as you deserve.”

I have picked two components to watch. Bugs in BMO (bugzilla.mozilla.org) are organized first by Product, such as Firefox, Firefox for Android, Thunderbird, and so on; then by Component, which seems to be a division by who is working on a particular area or project. You can’t pick a Component, or even see it, till you figure out what Product your bug belongs to. Here is a helpful guide from the Mozilla Developer Network with a list of Mozilla Products and their Components, handily all on one page, so it is easily searchable. I have also been using the list of Modules and their owners from the Mozilla.org wiki.

Bugzilla component watching

We don’t even have any bugmail yet, and see how much we have learned about the structure of a giant complicated FLOSS ecosystem! Hurray!!!! *waves pom poms*

Cheerleader cat

At this point, I made some folders in Zimbra inside a general Bugmail folder. While I’m still not sure how I’ll settle on bugmail organization, right now I have separate folders for my watched components and people. Then, in Zimbra preferences,there is a sidebar option for “Filters”.

Bugzilla filters

Create a new filter, then for users you’re watching, filter on header, and set the header name to X-Bugzilla-Watch-Reason. (For other filters, check the full headers and see what X-Bugzilla header info will work best.)

Bugzilla x headers

Since the X-Bugzilla-Watch-Reason filter contains the person’s email, if they change their own bugzilla email address, my filter will break.

Bugzilla user watching

Onward to Thunderbird, which I have set up with IMAP to check my Zimbra account.

Right-click (or command-click for a mac) on your account name in the Thunderbird sidebar, and choose “Subscribe”. This shows you the folders on your IMAP-connected account. Expand the folders and check the tickybox next to the new folders you just created in Zimbra (or whatever else you use). This will create a copy of that folder in Thunderbird.

Bugzilla thunderbird subscribe

One more step. In the Thunderbird sidebar, right-click one of the new folders that was just copied over from your IMAP account. Choose “Properties”. Then check the tickybox labelled “When getting new messages for this account, always check this folder.”

Now your bugmail will nicely filter itself — in both email clients.

That was non-obvious enough that I really wanted to document all the steps. Maybe some other new hire at Mozilla will be helped!

If anyone has bugmail tips for me, I would appreciate that!

Bonus points to anyone reading this who notices my PretendOffice filter and has a good laugh.

Related posts: