Release Management gets an Intern!

Thanks to the GNOME Outreach Program for Women, we’ve got ourselves an awesome January intern who will be doing her first Open Source contributions all the way from Australia.

Lianne Lee stood out as the strongest of several applicants to the Release Metrics Dashboard, which was one of the two Mozilla projects that Selena Deckelmann and I threw together in order to try and lure people to our devious schemes for moar metrics. Lianne’s application was thorough and used all the technologies I wanted our intern to have familiarity with (python, git, javascript, creating data visualizations)

She did a great job of showing one of the things release managers do over the six weeks a Firefox version is in Beta. The spikes in the above graph align with our constant triaging of tracking-firefox17? flags and how the number of bugs flagged for tracking decreases after the first few betas have shipped. When we get to beta 4 we’re starting to get more reserved about what we’re willing to track (it usually has to be pretty critical, or a low-risk fix to a many-user-facing issue).

This next graph shows us what we already know – but it’s very nice to SEE: our bugs tracked for a particular release continually go down over time, gradually.  Remember, this is while new bugs are being added to tracking regularly, so the fact that the trend keeps going down helps us know we are staying on top of our work and that engineers are continuing to fix tracked bugs as we close in on a 6 week ship date.

Now that we know Lianne has got what it takes, we’re going to set her on a more ambitious project – to create an engineering dashboard both for individuals and for teams, that would give them this sort of info on demand.  Want to see where you’re at (or where your team is at) on a particular version?  The engineering dashboard could show you in priority sequence what should be top on your list and also what bugs your team has unassigned that are tracked and should be assigned pronto (or communicate to RelMan that the bug should not be tracked).

This will be a huge improvement over email nagging (don’t worry, that’s still going to be around for many more months) because it will give us some quick, visual cues about how we’re doing with Firefox priorities and then we can also keep these measurements over time to compare release-to-release what the temperature of a particular version was. We hope this will allow us to keep fine tuning and working towards more stable beta cycles as we move forward.

Lianne will be with us from January 2 to April 2, 2013 and in her first week she’ll be evaluating a bunch of existing dashboards we know about to see what the pros and cons of each are and to do reconn on the technologies and visualizations people use.  We’ll use that to help us develop the v1.0 of this project’s deliverable and make sure it’s left in a state that RelMan intern 2.0 can pick up next summer.

Please comment if you have dashboards you like, you loathe, or you just want us to know about.