Blue Sky On Mars

tldr; I have created a project status page for Mozilla developer tools and a library called Buggerall that helps to make pages like this.

Poor Bugzilla. It started life as an innocent bug tracker and has come to be counted on as the source of truth for a collection of significant software development projects, and the workflow tracker of Mozilla’s development process.

As manager of Mozilla’s developer tools group, I was responsible for keeping an eye on how our projects were moving toward completion. It very quickly became apparent to me during the Firefox 4 cycle that getting code through the process was just as important as writing the code in the first place. At the time, “through the process” meant gaining blocker/approval status in addition to getting a slot on the super busy review queues of browser peers and successfully managing the back-and-forth of the review process. There is no query you can run in Bugzilla’s web interface to show you how bugs are doing in this process.

Enter Bugzilla’s REST API. Using this API, you can gather whatever data you need from Bugzilla and munge it any way you want. Even better, you can use this API entirely in client side JavaScript, even cross-domain. For my initial report, which showed where a given bug was in the Firefox development process, I had a bunch of code in the page to gather and format the data.

More recently, I’ve made that code more generic and given it new superpowers. It’s called Buggerall, it’s lightly documented CoffeeScript and it’s available on GitHub.

In my new role as product manager for developer tools, I want to be aware of how things are going with the projects, but at a higher level. I also want to be able to track developer tools work as it relates to Firefox features. To that end, I have created a project status page that builds on Buggerall to give me (and anyone else that’s interested) a view into developer tools work.

Some interesting features of Buggerall:

• run queries easily
• you can serialize the result so that reports (like my status report) can use cached data and load very quickly
• but you don’t have to! queries can be live and cross-domain
• new Timeline object lets you gather a feed of events for the bugs in a query

My status page has an updater script (invoked from an update page in the browser) that runs the queries using Buggerall and then mashes the data down to a simpler format used by the status page. The updater uses a Firefox-specific API for saving files which I found in TiddlyWiki.

The status page is built around project metadata that I set up. This metadata allows me to group together arbitrary collections of bugs, which is very handy. This can be done with meta bugs in Bugzilla, but it takes a lot more work to do so. Also, since this is all in git, it’s easy to collaborate with other people on the metadata.

I’m always interested to hear about other techniques people have for getting useful info out of Bugzilla. The query interface that Bugzilla provides is quite powerful on its own, but the REST API makes it easy to gather any data you need and present it any way you want.

Yesterday, I got back to work after a nice vacation, stepping into a new role after about a year as Manager of Developer Tools.

I’ve had a lot of fun this past year and learned quite a bit along the way. A year ago, I knew very little indeed about Firefox development. I’ve come to have a good handle on the process, which has changed dramatically along the way, and a decent grasp of the technology used in Firefox and how it all fits together.

The team has been fantastic: Rob Campbell and David Dahl got things rolling before a DevTools team even existed. My Bespin partners-in-crime Joe Walker, Patrick Walton and intern Julian Viereck joined the effort. New intern (now full-time) Mihai Sucan was characteristically sanguine about being told he was going to work on Bespin only to find out just before starting that he’d be working on Firefox. We worked hard on the Web Console and Inspector tools for Firefox 4, with the Web Console making the cut and shipping in March along with Firefox 4.

Along the way, Julian left for the university and Patrick moved to working on Rust.

We knew we wanted to go a lot further. Jan Odvarko, who is one of the lead developers of Firebug, officially joined the team. Dave Camp, a long time Mozillian, returned in February with a desire to make developing for the web better. In April, we were joined by Cedric Vivier, Kyle Simpson, Mike Ratcliffe and Panagiotis Astithas. In June, Paul Rouget joined the team, bringing his considerable insight and experience as a longtime developer evangelist at Mozilla. We’ve also been joined by Nick Fitzgerald as an intern for the summer and Victor Porof who is working on a Google Summer of Code project for developers.

This is an awesome team of people and I’m very proud to be working with them.

This blog post is not one of those “it’s time to move on to bigger and better things” posts. Web developer tools is an area with a lot of work to do and boundless opportunity. Taking care of the team and the projects as we’ve grown is easily a full time job and, in May, I raised my hand and told my manager that there’s work that needs to be done that I don’t have time to do.

Luckily, we had someone willing and able to take over the work I was doing in managing the engineering team: Dave Camp. Dave is a sharp engineer and is excellent at helping people lay out a path from point A (nothin’) to point B (working feature). He’s also got a very good sense for Mozilla and working out in the open.

Product Manager, Developer Tools

Which finally brings me to my new position: Product Manager for Developer Tools. Product management is one of those roles that shows up in different places in different organizations. At Mozilla, we have a dedicated product team led by Jay Sullivan. As part of this team, I’ll be able to do the work that I have had little time to do over the past few months, but is necessary for our success.

My responsibility as product manager is to represent the interests of web developers in designing and prioritizing features that will help them build better sites and applications more easily. I’ll do this by taking input from a great many sources (in no particular order):

• Mozilla’s developer engagement and market research teams,
• the developer tools engineering team,
• web developers I talk with directly, and
• things I read (and I read a fair bit)

With that input in hand, I’ll boil it down to roadmaps and ready-to-build feature specs. Dave Camp and the engineering team will take it from there to iterate on the features and get them to users. And we do all of this out in the open, ready for feedback and help all along the way. Mozilla really is an open organization and community. New product development is among the most secretive parts of most organizations, but not for Mozilla.

I also see communicating about what Mozilla is doing in developer tools as an important part of my job, so you can expect to see more blogging from me here and on the official devtools blog.

Now, onward to the new challenges!

Update: holy cow! I forgot to mention the three most recent additions to the devtools team (sorry Paul, Nick and Victor!) That’s what I get for blogging quickly while I’m still digging out after getting back from vacation.