Good news! As of today, Bugzilla now sends out emails containing both an X-Bugzilla-Mentors header and a “You are mentoring this bug” message. This means that it’s now possible to highlight activity in your mentored bugs in your favourite email client! I use Gmail, so I’ve created a filter that searches for “You are mentoring this bug” and stars it; you might consider the same, or giving it a label so it’s easy to see at a glance if there’s something you should prioritize. For mail header filters, you’ll want to search for X-Bugzilla-Mentors containing your bugzilla email address.

Note: this only works if searching for the mentor tag in the whiteboard yields a unique result. If the tag reads mentor=ashish and there’s an another account with :ashish_d, the result will not be unique so no relevant header value or footer will be applied to any messages sent to Ashish.

Please make use of this! There is no longer a good excuse for questions in mentored bugs to go unanswered or overlooked; let’s make sure we’re providing the best possible mentoring experience to new contributors that we can.

Bugs Ahoy is coasting along right now, and that’s fine. It fills a need, and apparently it does that pretty well from what I hear. However, there is a greater need – Mozilla needs a task board for all activities, and we need to not be distracted by reinventing yet another system. I’m kicking off a project to expand the Bugs Ahoy project to fill this need, and I am need lots of help.

Here’s the plan:

The task board will scrape data from an empty github repository’s issues list

New contributors with skills other than writing code will be able to browse the tasks available and get involved easier and quicker than ever before!

The main work that needs to be done falls into two categories:

Authenticating with github (please help, my brain just falls apart when I try to read about OAuth)

Creating a page that allows creating new tasks/modifying existing ones through the Github API

We want to avoid any need for users of the task board (both task creators and browsers) to ever visit Github; it’s just serving as a convenient backend to store the data. I’m snowed under with too many projects right now and can’t focus on this right now, but I would be thrilled to work with someone (or several someones!) to get it done. This is going to be a very useful tool when it’s finished, we just need some elbow grease to crank out a prototype. If you have experience with Javascript and/or Python, please get in touch! You can find the source on github.

One thing that has become clear in my work as a Firefox coding steward is that we have no idea how healthy our community is. When people ask me how many unpaid contributors we have, I don’t have an answer I can give them. The corollary to this is that any attempts to change our contributor engagement processes will be complete shots in the dark, with us fumbling to discover what kind of effect our changes cause. David Eaves underlined this message in the community building workshop yesterday, so I decided to do something about it.

Measuring the size of a whole community is hard, so I’m not tackling that problem yet. Instead, I’ve focused on the problem of making first-time contributions more visible, and measuring the rate of incoming new contributors in a methodical way. I decided to extract the commit data of mozilla-central into a database which I could query in useful ways; in particular I store a table of committers that includes a name, email address, number of commits, date of first commit, and date of last commit. You can see the raw results of my work at my github repository, where I’m banging away at multiple tools that use this data in different ways.

This measures the number of first patches that are committed in any given month. This graph allows us to see how effective we are at shepherding new contributors through the process of shipping their first change to the code.

This tool lists the contributors whose first patch was committed in a given period of time. With this, we can create reports that will allow us to take actions that celebrate this accomplishment (blog posts, swag, announcements in meetings, submissions for about:credits, etc.). This will allow us to take the burden of these tasks off of the engineers who can’t see beyond the patch, and place it in the hands of people who have a broader vision of building community effectively.

I’m not finished yet! I’m also really interested in measuring how many contributors drop off in a given month – by combining this with the incoming contributor data, we can get rough data about churn in the community, and compare how many people are leaving vs. how many newcomers we have. There are many more interesting measurements to be taken here, and I’m excited to be digging into this data. Feel free to join me! The github repo contains the script to create the database from the git mozilla-central repository, and you’re welcome to explore the data with me.

Bugs Ahoy retrieves issues from Github for certain categories (such as B2G and Test Automation). Unfortunately, I learned recently that unauthenticated API users are now limited to 60 requests an hour, and that means that these categories often end up broken. I really want to fix this by being an authenticated user, but OAuth scares me. I would dearly appreciate someone fearless to help me get my github authentication ducks in a row so new contributors can see the full range of bugs available to them. Bugs Ahoy is entirely a client-side app written in HTML/CSS/JS, so bear that in mind when volunteering. Thanks in advance!

Hello everyone, it’s your resident Private Browsing developer here! I’ll state it up front – the release of 15.0.1 was triggered by code I wrote that broke private browsing mode in significant, privacy-affecting ways. Ehsan and I fixed that for 15, 16, and 17 by backing out the problem code completely, but we’ve been working hard to fix it properly in Firefox 18 (currently in Nightly). This means that we want YOUR help to ensure that we haven’t subtly broken private browsing mode in nightly, and here’s how you can do that:

Take some time every day to clear your disk cache, then put your browser into private browsing mode. If you want to use it for traditionally-private things, that’s cool, it just may be slightly more embarrassing to thoroughly report bugs you encounter. What would be very helpful is if you could spend some time using your browser for regular, non-private things, and every so often open up about:cache and look through the entries in your disk cache. If you see any entry that looks like it came from one of the sites you were visiting, file a bug and CC :jdm and :ehsan. In fact, I will even accept comments on this post, or IRC pings, or emails, or whatever – these are important privacy failures that need to be addressed before FF 18 goes out the door. Do your part to make it unremarkable!

Back in June I created the slightly-misnamed What Can I Do For Mozilla tool (misnamed since it only focuses on code that needs writing, ignoring any other useful skills). It took off all over twitter, but I never actually formally announced it. Now, whatcanidoformozilla.org needs your help! I want to fill it with as many projects and teams as I can, since I link an average of 250 people to it every month. Is your project missing from it? Find me and let me know, or (even better), file a pull request. The format for adding a new entry is really simple:

A mechanism that automatically expands all collapsed merges in a pushlog view. I don’t care if it’s a Firefox extension or modification to the pushloghtml source that adds an expand=1 parameter to the query string; I am tired of manually expanding each one.

I don’t always write code, but when I do… no wait, that’s not right. Here’s what I’ve been up to in the past week:

I sing in the an all-male university a capella group called The Water Boys. Our end of term concert is happening on Sunday, and the overall club EOT concert just occurred last weekend:

I also sing in a barbershop quartet called the Bearded Baritones, which doesn’t allow me to hide in the background nearly as much as the 17 person group does (third from right, if curious):

Having just attended my last class of my university career (assuming exams go well), I have to say that this is one aspect of the past five years that I will miss dearly when I move to Toronto this summer.

Do you get frustrated about how long it takes to build Firefox after you’ve only made a small change to a single file? Have you heard the words “incremental build”, or tried to only build one or two directories but can’t figure out why your changes aren’t showing up?

You are not alone.

I released my smartmake tool last year to allow people to specify then directories they’ve changed, and in return the tool would perform a correct incremental build. No hassle, no sweat. The name was deceptive; it was a pretty dumb tool, but it got the job done with a little help from the user. However, there is a rule that any build system tool eventually reimplements the functionality of make, and so I am proud to release smartmake v2, which requires less work than ever before to produce correct incremental builds.

Thanks to the hard work of the illustrious Till Schneidereit (till on IRC), smartmake now finds every source file modified since the last time you performed an incremental build, and performs a (mostly) minimal rebuild. It will also complain if it comes across any modified files for which it doesn’t have any dependency information, and suggest you perform a full build instead.

Go ahead, give it a shot! Tell me (or Till) what goes wrong so that we can fix it. I recommend doing a full build, then making a small change and running smartmake.py '5 minutes ago' to kick it off and get the timestamp caching happening.