One Year with Mozilla

It has been quite a whirlwind past year for me (and for Mozilla). I began as a Contractor working on Mozilla Marketplace support in February 2012. I got married to the love of my life in May. I made several trips to San Francisco for work weeks. I transitioned from Marketplace support to a full-time User Advocacy role. I’ve moved (and am preparing to move again). Mozilla has developed and announced Firefox OS. We’ve begun projects such as Squeaky, we’ve worked on growing and improving our tools. We’ve created a regular Firefox for Android reporting process. We’ve done so many things it’s hard to count. and get ready for an even more impressive 2013. 2012 was dominated by creating the User Advocacy team, and laying the ground work for it. This year User Advocacy can focus our whole potential on being the voice of the user for Firefox Desktop, Android, and soon FirefoxOS. I’m super excited to see what 2013 brings for me, User Advocacy, Mozilla, and the internet.

Try Firefox for Android on your ARMv6 Device!

With the launch of Firefox 17 for Android today, we are beginning support for ARMv6 devices, a much requested feature in the past. Currently we are supporting ARMv6 devices that are running Android 2.2 or higher with an 800mhz processor and 512MB of RAM. If your device meets these specifications, please install Firefox 17 from the Google Play store today! If it makes you happy, please leave a review! If if makes you sad, please let us know.

The Difference between the Firefox of 2011 and 2012

With the End of Support For Firefox 3.6 not far behind us, Firefox 13 being released with Awesome new Features, and the Wonderful Firefox 14 for Android, those of you who are on an Older version of Firefox, or who moved from Firefox to another browser, may want to take a look at how Firefox is better. A few reasons why:

  • Firefox Memory Management is FARRRRR better nowadays. With a Fresh Install of Firefox 4 on my test machine, Firefox 4 uses roughly 40MB of RAM. Firefox 13.0.1, uses 23MB. This is with the only tab open being about:memory. This is mainly due to the awesome work done by the Memshrink Team. Go read their status updates to see what work is being done in Firefox each week.
  • Firefox is much faster. With features such as Type Inference, newer versions of Firefox are faster at everything from Startup to Javascript.
  • Firefox has new Features. If you are still with an older version of Firefox, go read on what has been introduced into each new version that you are missing out on. These range from new HTML5 and CSS standards support, to security improvements, new web developer tools, and much more. Wikipedia has an excellent summary.
  • Older versions of Firefox are quite insecure. With Rapid Release, only the ESR of firefox and the latest version receive security fixes. And an alarmingly high number of users stay on these insecure versions.
  • And Much Much More.

Are Add-ons holding you back?

There have been several major changes in Firefox add-ons for new versions. In Firefox 10 and later, the majority of extensions are defaulted to compatible. With the other improvements to silent updates, removing the UAC prompt on Windows, etc. updating Firefox is worlds easier than it was even just a few months ago.


Are you having Troubles?

Another Awesome Feature in Firefox 13 is the Firefox Reset Feature! If you are having problems, or if you just want to try to make your Firefox any faster, go ahead and try it. Almost all your information will be saved (Extensions are the main thing that isn’t saved, but they are also the main cause of Firefox problems). It will probably make you wonder how you used Firefox before.

Try it out!

If you’ve been waiting to see if Firefox will improve before coming back, there isn’t a better time to do it than now. And if you have problems, want to make Firefox look like Firefox 3.6, or need anything at all, the SUMO Community is more than happy to help you out! Go to for all the help you can want.

Back from Mountain View

As some of you may know, Mozilla has Recently announced the Open Web Apps Project, as well as the Mozilla Marketplace. While many of the details aren’t finalized right now, the Mozilla Marketplace will be a medium for users to buy and download HTML5 apps to multiple devices (Desktop, Mobile, etc.).

This week I traveled to the Mountain View and San Francisco Mozilla Offices to begin my new role as a Support Specialist for the Mozilla Marketplace. While I feel like a sponge that had to soak up a Fire-hose of information in 3 days, I am very excited about this future opportunity to impact and help Mozilla Users. I meet a lot of awesome people (it is nice to finally put faces on names), and reconnected with people I haven’t seen since Whistler.

Until the Marketplace is officially released sometime this year, I’m going to be working on a lot of behind the scenes prep-work. I will be doing some work on Triage in my free-time, but expect to see me around on SUMO a lot more from now on.

Two Things

I wanted to give a reminder to all Mozilla Triagers that I have two active surveys about Mozilla Triage. The first is about general Triage Demographics and suggestions, and the second is specific to communication. If you haven’t taken these surveys, it would be a great service to me if you would take a few minutes and fill them both out. They are 100% anonymous and the responses I have received so far have been very helpful. If you have taken on and not the other, both are equally important. Thank you to all who have responded already!

Second, Justin Dolske blogged yesterday about an AWESOME experiment. As many of you will know, I have suggested using a separate product or component to filter through Untriaged bugs. It appears that idea is coming to fruition. I suggest you read Justin’s blog to get the whole scoop. Thank you Justin, Glob and everyone else for trying to make Triager’s work easier!

One More Survey

Thank you for the response to survey I posted a few hours ago. I’ve already got helpful feedback and more is coming in. In the meantime, I’ve got one more short one that is probably even more important. The issue of communication in the Triage community is something that I feel needs to be improved, so I’m calling out for input.

The Communication Survey is here. And if you haven’t filled out my first Triage Survey, please go here.

Calling all Triagers

I know I’ve been silent the past few months, but haven’t been still. I’ve written up simple summaries of several of my Triage ideas on the Mozilla wiki. You can read them Here, Here, Here, Here, Here and Here. I’m looking for feedback and suggestions, so feel free to leave them in the comments and/or the wiki talk pages.

I have created a very simple survey that I would GREATLY appreciate if anyone who has participated in Triage past or present would fill it out. It is 100% anonymous, and I am simply looking for honest feedback. Do you feel triage is a waste of time, do you think it is just fine, do you think it needs to be fixed, whatever you have to say about it, I want to hear. Please also feel free to share the survey link to anyone that you think might have an interest. The results are mainly for me (I’m not doing this at anyone’s request) so I can answer a few questions of my own, and hopefully gain some new ideas.

The Survey is Here. Thank you all!

Links, Lots of Links

I wanted give a bit of input to an idea I have started to hear tossed around which I find quite intriguing. Shutting down BMO for a week or so, and devoting ALL Mozilla’s resources (devs, QA, the community, everyone) to cleaning up BMO. With 5868 UNCO bugs, and 7191 NEW bugs in Firefox alone, we obviously have a bit of need for cleaning up. Then throw in Toolkit (UNCO bugs, NEW Bugs), Thunderbird (UNCO bugs, NEW bugs), Core (UNCO bugs, NEW bugs), and so many other components and products, and really, we do have a mess on our hands.

The solution isn’t as simple as it sounds. If we just shut BMO down now, we will be using resources ineffectively, and without a long-term solution we will be right back at square 1 within a year or two. I whole-heartedly approve of shutting BMO down for a week or so, but I also know we need a multi-pronged approach. If you read my series on why we need to radically change triage, you can read most of my points there, and they are ones I have been saying repeatedly for the past year. I’ll quickly summarize them here though.

  • Create a separate product for UNCO bugs and triage. There is a new Input Tool in the works right now, and it will be using this idea in a more constrained form. I have had some discussions with the people working on it, and hopefully we can get this UNCO product rolled out to cover all bugs submitted for Firefox/Toolkit/Thunderbird/etc. I do see promise of progress here, so this is good news. Once we get this fully implemented, I feel all UNCO and abandoned NEW bugs should be moved into the product.
  • Create a way for Triagers to tell how far a bug is in the triage process, using multi-state flags. This idea was proposed at the Summit 2010 by tmyoung. Unfortunately, a lot of devs didn’t want to have their bugs cluttered up with more flags (which is understandable). By implementing the flags only in the UNCO product, they will serve triagers, and once a bug is moved out of the product, they will be no longer be needed and removed. Hopefully this way we can make both sides happy.
  • We desperately need a way to mark Support and Extension bugs as such. Having a RESOLVED>Support status and a way to automagically open a support issue for the bug will go far to help users feel that we care about them and their issues. The same goes for extensions.
  • We need Bug Triage Guidelines. Something along the lines of what I threw onto the wiki a few months ago (obviously a lot more fleshed out). But something the community, especially new members, can reference.
  • I think that if we implement a lot of the ideas that David Eaves has proposed, we can go far in improving both triage, and BMO in general. I know a few of his suggestions have already been put into production, but I don’t see any of them that would harm the community, and I think they should be thought about again.
  • I’m not sure how practical this is, but perhaps we can create some sort of bot to automatically ping a triager when a bug has gone a certain amount of time without a comment, and to ping reporters when they have not replied to their bug after a certain amount of time. This would eliminate much of the time that is spent “cleaning up”, freeing more time for “real” triage.
  • Hire several official Traigers. To do several things (most of which I’ve already discussed, so I give it in brief here). Organize the community, help new community members, communicate with Devs, do full-time triage work, be advocates for the community in Mozilla.
  • Having a yearly intense cleaning like Mike proposed would also be great, because even with the best of efforts, some bugs will slip through the cracks. The first one I think we should set a week aside for, but subsequent BMO cleaning could probably only be done in 3-4 days.

So I know this is a fairly short summary, but these are by far my most important changes to BMO, and the Triage process that I think need to be made. Some progress is happening, so I look forward to seeing what is done in the near future.

Have a good Labor Day

I am going to be using this long weekend to do a lot of reading, and private discussions on triage, and hopefully come back early next week with some more blog posts. However, in the meantime, I recommend that everyone read Mike Kaply’s blog post on how to deal with the backlog of Bugs on Bugzilla. It is an idea I’ve had before, but never talked about, and I think that once we get a game plan for triage down, it should be taken VERY seriously.

Answering some Questions, and Responding to Comments, Part 1

It has been an interesting week. I published a blog post describing in detail some of my concerns with Triage on August 27th. I intended to simply spark a discussion about some of the finer details of the Triage issues, and explain a few of the reasons why I did and didn’t leave. It was written by a triager for triagers, and as such, it used terms that probably weren’t understood by many outside of the triage and Mozilla community. I would recommend that anyone who wants to a good grounding in how (BMO) works, and what UNCONFIRMED Bugs, Triage, etc. are, read the links at the end of this post. And if anyone needs clarification on the technical details of the What and How of BMO and Triage, I’d be more than happy to write a post on that.

I have gotten quite a few questions and comments regarding triage however, so I wanted to divide them up into a couple main themes that I noticed, and discuss them that way. I will be repeating myself from time to time to hammer home points that are important.

Some Questions and (hopefully) Answers:

  • Should we focus on bringing bugs to zero?

Matthias Versen: “In the beginning i thought that we should try to manage every incoming bug report but i realized later that this isn’t possible. It’s not possible because mozilla is a huge project with millions of users and the target to get all UNCO Firefox bug reports to zero will never happen.”

Gavin Sharp: “I don’t think that focusing on the number of UNCO bugs is useful. We should focus on outcomes, not on driving a number to 0 for the sake of it.”

So, we have the question, what should the goal of triage be? To have zero UNCO bugs? To drive every bug to resolved within a week?

I feel the goal of triage is to filter out the real bugs from the duplicates, invalid and spam bugs in an efficient, professional and through manner. The number of bugs shouldn’t be our emphasis, at least not the main one. We definitely don’t want to repeat the 13,000 bug low that we once had. As I have said, the number of bugs doesn’t matter as much to me as how fast we respond. We have Rapid Release; maybe we should have Rapid Response for triage. I don’t mean closing bugs quickly. I mean not letting a bug languish for 6 months, or even years without a comment.

It would actually be quite an interesting metric to see what the average response time to an UNCO bug is now. Then, as it seems that at least a few of my ideas are being implemented into Triage, to re-measure after they have begun to take effect. While a Rapid Response won’t fix every issue in Triage, by keeping our reporters happy, we will be able to keep a dedicated community willing to contribute again in the future.

What would help our Rapid Response strategy most will be a separate UNCO Bug Product, making bugs that need to be triaged easier to find. Along with that, we need some sort of triage flag, so then we can tell what stage of the triage process a bug is in. Organization, so the community can focus on areas of BMO that haven’t been triaged thoroughly yet. Finally, we really badly need several people to do triage full-time. Community Volunteers who are working in their spare time simply can’t always get to every bug. The community does an awesome job (pretty much the only job, as there are no Official Triagers), but, it isn’t quite enough.

  • We need Increased Communication between Triager and Developer

Steve Fink: “I just feel like there’s a conversation that needs to be happening between triagers and developers, and it isn’t, for the most part.” (I also recommend you read the rest of his comment)

There is, and it isn’t happening. We need to turn triage from Triagers vs. Developers to Triagers & Developers vs. Bugs. Triage and Development have the same end-goal, to make a product better, and to fix bugs. In theory, they make a perfect team. Triage takes incoming bugs, filters out the junk, the spam, the distractions, and hands the workable bugs over to devs, who then fix them. In reality, there is very little communication between the triage community and the developer community. I’m sure a lot of this problem stems from the lack of communication within the triage community itself. I would love to have developers come to the triage group and say “I have X amount of bugs that have to do with printing. Here is the list, would you mind working it a bit.” All this without having to organize a bugday. Having a quick reaction time to changes and trends in the Rapid Mozilla is essential.

We also need to learn from developers how they want their bugs triaged. Certain developers may not like certain methods of triage (“don’t use the closeme tag” for example). That is fine, so long as the triage team is aware. Once a good inter-group communication method is figured out, it would be nice to sit down with the various module owners, and find ways that triage can benefit them, and what they feel are dos and don’ts.

But communication needs to be two way. Steve also said “As a developer, I have an instinctive fear of getting sucked into triage because I know it has an insatiable appetite for time. I’d bet many devs would be willing to help with the overall triage process. But if there’s a hint that it means we have to jump on every vague bug report that a triager forwards to us and work on it until it’s good and dead, we’ll run away and hide under the nearest potted plant.”

Triagers often do need to ping a developer on a bug to get input on if it is a real bug or not. Many developers are good about replying when a long-time triager pings them on a bug, but for new beginners, it can be hard to figure out whom to ping, and once you do, to get a response. Having some sort of an agreement with even just a few developers who will agree to help out the triage group when it is needed would be nice.


I want to try to split this into several chunks that are easy to digest and discuss. So, I’ll be coming out with a few posts in the next couple of days. Let’s try to keep any discussion relevant to the points I have in each post, it will make my life a bit easier when trying to follow-up. I will get to the all in time, don’t worry.

For Further Reading

The Current Mozilla Wiki Page on Triage