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:

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:

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.

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.

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.

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.

Len Burns and I have invited screen reader users of Firefox and other Mozilla products to join us in sorting through existing accessibility bugs. Some folks from the Mozilla Accessibility team will be on hand to talk with us.

I’m pretty sure we will also collect some new bugs along the way!

I hope that people will make new connections, and that we can attract a wider accessibility bugmaster team to do ongoing work with Mozilla’s existing developers and a11y experts.

The screen reader landscape for web access is fairly complicated. For example, here are the Firefox Gecko docs for Windows accessibility vendors which explain the relationship between the DOM tree and Microsoft’s accessibility API. Common screen reader software includes NVDA, Window-Eyes, JAWS, and Orca.

If you would like a quick overview of common web access issues, look through Aaron Leventhal’s presentation. I like it because he includes some political dimensions and context for accessibility.

So far, the “bugmaster” bug days have been combined with QA’s efforts. I’m hoping to also hold focused bug days like this one, in cooperation with various teams across Mozilla. As we gather more templates for bug managing and triage, I hope we’ll coalesce bugmaster teams with expertise in particular areas. And we can repeat topic-focused bug days periodically.

If you are interested in web accessibility or if you use a screen reader, please drop by on Tuesday and say hello in the #accessibility channel on irc.mozilla.org.

You can also add the name you go by, your irc handle, your contact infomation, or anything else you use to identify yourself, on the wiki page for the bug day under Participants: https://wiki.mozilla.org/Bugmasters/Bug_days/a11y#Participants .

The goals of the screen reader bug day are to improve everyone’s experience of Firefox and other Mozilla tools. We would like for everyone to be able to access the web smoothly. Through collecting more information on accessibility bugs, we hope to connect committed technical users with accessibility developers, and make our community better and more powerful. Our bugmaster work should help to make developers’ work easier. That way they can spend more time fixing stuff.

If you have any questions or feedback, please feel free to email me at lhenry@mozilla.org.

In setting up this event I tried to make sure that the tools we are using are as accessible as possible. Etherpad, which Mozilla teams often use for bug triage events, is not useable for screen readers. The wiki.mozilla.org pages seem readable though editing may be more of a challenge. IRC feels like our best bet for good communication. I also went through about 100 screen-reader-related bugs and emailed the bug reporters and commenters to send them invitations to participate.

Len is particularly interested in developing a plan for Thunderbird and screen reader vendors. If you share this interest I recommend joining the mailing list tb-planning.

Here is what Len has to say on Thunderbird accessibility:

It is complicated, because the issues are really between the two major screen reader vendors and Mozilla. Meaning, that the solution would need to be a cooperative one. Because the screen reader vendors perceive, right or wrong, that little more than security bugs are being updated in Thunderbird, they do not seem terribly motivated. I am not quite sure where to take it.

Unless I could convince the vendors that solving these issues are worthy of their time, I am a bit stuck.

I would definitely be willing to raise the specifics with both vendors if I could give them some reason to encourage a belief that there is a mutual interest in improving things. When I have raised several with GW Micro I hear things like: This has been filed for over a year with no response, and the like.

Those of us using screen readers are currently in quite a pickle regarding email. The choices are quite limited. A lot of us have been using Thunderbird for some time, but when things reach a point where you are spending too much time trying to send a simple email, something must give.

I can also tell you that what finally tipped me were problems between the composition screen, and other open apps on-screen. If I were going to compose an email in TBird right now, I would have to be sure that Skype was minimized, MirandaIM was minimized, etc. If I did not, I would be likely to encounter a range of strange behaviors in the edit window such as being unable to read back the text I am writing, inaability to use my backspace, format distortion, and more.

What has been slowing me down on these issues was a lack of knowing avenues of pursuit. The challenge will be convincing vendors that investing time is a benefit. My position is that I am not sure, but, we have a good chance of catalyzing and contributing to change and possible strengthened relationships.

Len has been a professional system administrator, coder and web accessibility consultant since the Internet was a kinder and gentler place. He makes his living these days free lancing as a web accessibility consultant for colleges and universities and coding the back-end glue of web sites for small to mid-sized businesses.

Thanks to Len for his insights on web dev, email, and access in the last couple of weeks as well as his outreach efforts to talk with vendors, software users, and developers!

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”.

Once you sign into CodeTriage with your github account you can browse code repositories by programming language. I picked flask and codetriage repos to follow.

Codetriage then sends me a daily email with link to a random issue from each repo, asking me to triage the bug.

This makes it beautifully clear that, with only a little time and thought, without any particular programming skill, anyone can contribute useful work to an open source project. Each email comes with a little pep talk about the goals of triage:

* Help share the weight of maintaining a project
* Minimize un-needed issues
* Prevent stale issues
* Encourage productive communication
* Teach good citizenship
* To become a better coder

Short, sweet, and to the point. The how-to-triage part of the email is not specific to any programming language or project, yet, or to the bug itself, but is an overview of the concepts of improving the quality of any bug.

It gave me a nice feeling that I had been helpful, when I tried it this morning.

André and I were talking excitedly all afternoon about shaping the idea of bugmastering (or triage) for our communities. Bug management is a great way for contributors to become familiar with a project and ease into development or become experts in QA. It’s a good evolution of a definite role in open source ecosystems.

So CodeTriage gets across exactly what I want to convey to aspiring Mozilla bugmasters. I feel super inspired to build something to hook into bugzilla.mozilla.org with a similarly lovely interface. Thanks to Richard Schneeman for creating CodeTriage!

The London office is right between Trafalgar Square, Chinatown, and Covent Garden. It’s very accessible. If you come to Mozilla London offices and are a wheelchair user, you should know that the Tube stations near the office are not accessible. Give up and take the Heathrow Express to Paddington and then a taxi.

The BMO and IT teams (glob, dkl, and fox2mike, mostly) are planning to upgrade bugzilla.mozilla.org on March 8th. You can give it a test drive here: bugzilla-dev.allizom.org. This brings Mozilla’s implementation in line with the upstream version of Bugzilla 4.2. In theory, the new server hardware and architecture will also make BMO much faster.

I’m mostly excited about the user and product dashboards in this release. They look extremely cool — great for people who are doing bugmaster and triaging work. Someone who wants to drop in to triage Firefox bugs, or to get a mental image of what’s happening with bugs of interest to them, will be able to do so easily, without having set up a sort of pachinko palace labyrinth of bugmail and filters.

So if you would like a sneak preview of the user and product dashboards, take a look on bugzilla-dev.allizom.org and poke around! You can talk to us on #bmo or #bugmasters on irc.mozilla.org if you have feedback. And do please help us by filing bugs!

Besides the upgrade and move, and the archictecture of bzAPI current and possible future — gerv, dkl and I discussed the re-framing of early bug triage as “Bugmaster” or bug management work. We kicked around some ideas and it was very helpful to me to get their advice.

I am adding links to current wiki docs into the show_components.cgi descriptions and dkl has promised to expose those descriptions in show_bug.cgi views of individual bugs. My thought is that within the bug itself, the reporter and triagers, or an aspiring new developer, will have multiple ways to dive deeper into the bug.

We talked about adding common reply templates, which I am collecting in the Bugmaster Guide but which would work well, I think, built into Bugzilla. It turns out that dkl already has an extension started, canned comments, to do exactly this. Very intriguing!

Another thing I’d like to see is something that invites extra information when a bug is filed. This can be context sensitive, so that, if you file a bug in Firefox for Android in a particular component, there can be a link to relevant support forums, wiki pages, the irc channel, and the module owner information. This landing screen could also invite the bug reporter to add bits of information they have not included. If they haven’t attached a screenshot or included a url there could be an attempt to elicit them, or a few “next steps to help make this bug more reproducible” suggestions.

I am still thinking about the READY status flag and other ways to mark “early triaging is happening, or should be happening” vs. “in the hands of dev team”. That is a fuzzy boundary and different conditions would lead to it for different products/components. In this discussion we looked at Gerv’s and Jesse Ruderman‘s proposals for BMO workflow:
* Workflow Proposal 1 which simplifies the status chain.
* Workflow Proposal 2 which more radically changes the flow and statuses to a “next action” framing.

I can see benefits and drawbacks to both models.

It would be helpful from a triaging point of view to be able to declare, in an obvious-to-all way, that a bug is as triaged as we can get it for the moment and it either is ready for a developer to look at or is in some sort of Bug Limbo waiting for later re-assessment. We can do that with some assortment of existing tags and keywords but it may lack clarity and ease of use.

We brought up the idea that if I am doing some triage on a bug but don’t feel it is “ready” yet — for example perhaps I have identified its component, but not reproduced it, or vice versa — I can list myself as the QA contact. What would that indicate, though? Would it keep away other triagers? That is not what I’d want, of course. We could end up with some sort of “needstriage” checkbox, or make a tagging taxonomy that is well documented and evangelize it.

On Sunday I spent some time wandering around in a rented mobility scooter. It is possible now in London to hire a scooter for 70 pounds a week. Very much worth it not to have to push myself over thousands of cobblestones. I have only run over one person’s foot so far in the swarms of tourists, theater-goers, schoolchildren going to museums, and Londoners purposefully striding around in overcoats staring at their mobile phones. Though the scooter delivered is bigger than most cars in this country. It is like an enormous Mecha Gundam Wing suit on wheels so my adventures in the London streets are reminiscent of the Pacific Rim movie trailer.

In London, when confronted with a giant wheeled exoskeleton, people generally give a tiny gasp and start (theatrically), mutter apologies, and make a show of getting out of the way while looking bewildered. They are relatively good at not acting shocked that I exist. That’s kind of pleasant really. Some buildings and restaurants are somewhat accessible. I get along here as long as I don’t think too hard about how I can’t use the Tube at all and I can afford the glorious taxis.

In Vienna, I used my manual chair. Almost nowhere is accessible even when it is declared to be. People there would loudly gasp, almost a little shriek, and leap forward to grab me, which reminded me of how people act in Beijing when they see an independent person using a wheelchair. They scream, and they leap, like kzinti. More details on hilarious wheelie adventures in the Hofburg, coming soon. Travel is lovely but I’ll be glad to be back in San Francisco at the end of the week.

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.

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.

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.

For example Bug 130835 – Make Bugzilla’s index.cgi (home page) useful for logged-in users has over 150 comments, stretching back 10 years. Here the problem may actually be that the bug (or enhancement request) was not well defined in scope, so had no clear end. It might be worth untangling the useful ends of these 150 comments to close this bug, and open several new and more specific ones for which “current state” *could* be summarized as dbaron suggests.

But what about a bug like Bug 83192184 – Make the plugin click-to-play UI look less like ‘plugin broken/crashed’ UI , where there is a useful active conversation? In that case trying to synthesize the conversation at every step of the way, each time someone comments, is probably not useful.

So in some cases there is clear “current state” or content, as there is on a Wikipedia page, but in some, the conversation is the content. I don’t want to have (or read) conversations in a Bugzilla equivalent of Wikipedia talk pages and am not sure that would be an improvement on the current state of Bugzilla comments. For bugs with a long history, especially ones which have mutated significantly since their beginning, the “current state” field might be an easy way to untangle the mess.

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.

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.)

“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.

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*

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”.

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.)

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

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.

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.