Category: planetmozilla

FirefoxOS phone beta testing

Posted on by Liz

I got my FirefoxOS phone and am doing some testing on FirefoxOS 1.1 beta. I’m about to switch over to using it as my primary phone, but so far I’ve just used its apps and web connection. It seems very responsive and fast.

green and orange FirefoxOS phones

My friend Tiziana and I compared phones. Hers is the orange one, a ZTE phone running OPEN_US_DEV_FFOS_V1.0.0B1. Mine is green and is from Alcatel, running FirefoxOS 1.1.0.0-prerelease. I definitely notice the difference in the new version of the OS in that it is more responsive and I feel more sure in control of the touchscreen. Typing works well. I miss having something to swipe across the letters so I hope an open source version of type-by-swipe is something in the works.

I have installed a few art and drawing apps as well as games. The only game I’ve tried so far is Little Alchemy, which was very buggy in earlier versions this spring, but works beautifully now.

Email setup worked great, browsing is good, I’ve been taking photos and emailing them. I’ve used the Wikipedia app to look things up, and the “I’m thinking of…” search feature to listen to music on the bus. The Music app comes pre-loaded with some albums but I haven’t figured out a good way to load my own music onto the phone. On the other hand I haven’t needed to since “I’m thinking of…” gets me decently fast connections to YouTube and other music sources.

One nice touch with this was that when I bring up my “I’m thinking of” Janelle Monae search the wallpaper background of my search screen changes to a giant aweseome photo of Monae in a tuxedo and I am offered the things on my phone to do with the search on top, then under a hairline divider, searches on Monae in many other categories like free music, Grooveshark, Google, Twitter, her official website, tickets, Amazon, and so on. Here’s what it looks like:

firefoxOS thinking of search screen

That’s different from my usual mental model of “search”. The result is interesting and, I think, powerful and useful. I’ll be exploring it over the next few days at the Mozilla Summit. And of course reporting bugs, but for now, I just wanted to share that the phone not only quite usable as a smartphone, it’s exciting to explore.

FFUntriaged number games

Posted on by Liz

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.

FFUntriage number games

Posted on by Liz

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.

Steady contribution to Firefox support forums

Posted on by Liz

Every once in a while I go over to the Mozilla support forums to this query for questions asked in the last 24 hours that haven’t been answered. I like how it’s phrased. Right now it’s “6 questions in the last 24 hours have no reply. Help solve them!”. That’s out of 86 questions asked in the last day.

Looking up the answers is interesting. To answer the question, I poke around on the support forums, do a general google search, and usually find something relevant or can at least link to advice. Hopefully, the person asking the question feels happy to get a reply even if the answer isn’t easy! And, sometimes, other people who are support forum regulars come in afterwards and give a better answer or correct my answer. So I am not afraid to answer wrong; other people are on it, and if their answers are more useful they will get voted up higher on the answers page. Either way, there is plenty to learn by trying to answer well, giving a link or a source for the information, and just plain being nice to people.

Then I take a look at my SUMO user profile to see my stats build up. I only answer a question now and then, and have edited and translated a few articles. Actually I’m a sucker for anything that shows a steady buildup of activity and any kind of stats. While my mere 38 questions answered isn’t a lot compared to some of the incredibly dedicated contributors on the support leaderboard. It is like a little dragon hoard of evidence that I did something and that is satisfying even when it’s a very small hoard!

Sumo user profile 913

I only realized recently there are canned responses for replying in the support forums. There is an icon like a top hat, or a magician’s hat, which I didn’t notice for months. Perhaps from being a person who is way more into text than images.

Sumo magichat

It never occurred to me to click on that hat. Then someone mentioned it on IRC. Wow! I may file a bug to suggest adding a label next to it, that appears even when you don’t mouse over the hat. (Or is it a can… or a bucket?)

The selection of common responses is extremely useful. Basically there is a lot of infrastructure built to support, not just the people coming to look for answers, but the community contributors answering the questions.

Sumo canned

Bugzilla now has user profiles which I’ll be working to improve and make useful. You can see a person’s last activity in bugzilla.mozilla.org, the number of bugs they’ve filed, commented on, and various other stats that may be relevant to bug reporters, bug triagers, and developers. I’ll post more about this soon!

By the way, my avatar on SUMO, though it kind of looks like me with its purple hair, is from a game called Glitch that closed in late 2012. Glitch was a descendent of Game Neverending. GNE had an image management and social network build into it that became Flickr. I still miss Glitch – it was a great game and a beautiful community!

Supporting The Ada Initiative, and making more room

Posted on by Liz

People ask me all the time what they can do to help change our culture. How to get more women in F/LOSS, in tech, get more women coding and working with us? I have a suggestion! Please donate to The Ada Initiative! I realy believe that it’s helping, and wil continue to help!

Personally I donate monthly to The Ada Initiative as well as participating on its advisory board. Over the past couple of years I’ve benefitted directly from The Ada Initiative as I see conference after conference put anti-harassment policies into place, which TAI has worked hard to facilitate.

Earlier this summer I had an amazing experience at AdaCamp in San Francisco. The Melbourne and DC AdaCamps bore fruit too, as they connected so many women in open tech and culture with the communities I’m already part of, and made us visible to each other.

The synergy from the feminist hackerspace discussions at AdaCamp SF led to the first meeting for a new feminist hacker and maker space in San Francisco. After a whole weekend of talking at AdaCamp, it was like we couldn’t stop! I ended up with a dozen or so fierce activist women in my living room describing their vision for how we could make actual physical room for our projects and ourselves, a space we would invent, define, and maintain. It was really a dream come true.

As an long-time feminist activist, I have felt tremendous relief from the amount of peer support I’ve gained from working with The Ada Initiative. The people who are part of TAI have a tremendously sophisticated view of what we’re doing and why we’re doing it, and what we need to make it happen. I deeply appreciate the professional commitment of everyone at TAI and everyone I met at AdaCamp! That’s part of why I’m posting to ask you to donate. It’s important to make support for women in free and open source tech and culture truly part of our infrastructure. We can do that by funding that work! Here’s some ways to donate!

Donate now tai

File a bug: the missing manual, now with unicorns

Posted on by Liz

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.

Screen reader and accessibility bug day

Posted on by Liz

Tomorrow Mozilla is hosting a screen reader and general accessibility bug day.

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.

Orca2 sm

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.

Len FB profile

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!

Bugzilla hijinks, Tuesday March 5

Posted on by Liz

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

CodeTriage looks very cool!

Posted on by Liz

André Klapper showed me a nifty tool called CodeTriage yesterday. I really like its simplicity, its friendliness, and what it conveys about open source bug management.

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 homescreen

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

Codetriage email sample

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!

Bugs and sheriffs in London

Posted on by Liz

Travelling Bugmaster update! I am in London with a bunch of the automation tools team for a work week. Ed, jeads, Chris, Ryan, dave, and mauro have been neck deep in making decisions about the structure of a new version of TBPL. By eavesdropping in their conference room I have learned a bit about how Ed and RyanVM and others watch the tree (sheriffing). Also, dkl and gerv and I met up to talk about bugzilla.mozilla.org and I got to bounce some ideas off them about possible ways to tweak the incoming bug triage workflow.

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.

Lanterns sky

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.

Bugzilla user dashboard 500

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.

Lion unicorn palace

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.