It’s September, so a lot of students are joining us in various Mozilla forums, hoping to make a contribution to an open source project. This is always a challenging time of year for Mozilla, and I’d like to say a few things about it. If you’re a student hoping to get involved or – even better – an educator who would like to involve their classes in open source projects or contribute specifically to Mozilla, I hope this will give you a sense of some of the challenges and pitfalls you may be facing and how we can work together to overcome them.
If you’re a veteran of Usenet from the days when Trumpet Winsock was a thing and dinosaurs roamed the earth, you recognize the particular flavor of Mozilla’s comms channels at this time of year. People who want to make a difference in the world want be a part of Mozilla and we’re always excited to hear from them, but September is a challenging time; we get a lot of requests for “student projects” and “easy bugs” that can be difficult to address, and the dropout rate from new participants grabbing “easy” [good first bug]s at this time of year is frustratingly high.
Part of these challenges are structural, of course, and some of those structures are out of our control – courses that are designed around software and development as a discrete, compartmentalizable thing, rather than a messy, rapidly evolving and organic process aren’t really compatible with the day to day process of shipping software. Likewise the benchmarks that make up a traditional academic evaluation process don’t really make sense in our context, so more often than not the goals and schedules of students and educators aren’t well-aligned with ours.
We’re grateful for any effort put in, large or small, to making Firefox better and supporting a free and open Web. Having said that: there are a few things that make working with Firefox in an academic context challenging and you should be aware of them.
The biggest one is that we can’t promise to accept a patch within a certain time frame. This can become a problem for both students and professors when getting the patch accepted into the main product is part of the criteria for a good grade in the course.
This has happened in the past: a student has done great work on a harder-than-expected bug, but it didn’t make it through our process – including testing, feedback, revision and more testing – by the time grades were assigned. Despite their effort, the student was undeservedly graded poorly.
This is bad for everyone when it happens – the student and professor both get discouraged, the value of their work (and of the course) gets harder to see, and if the student doesn’t stick with the patch long enough to carry it over the line, despite all that, Firefox doesn’t benefit and Mozilla’s engineers feel like they’ve wasted their time.
If you’re involved in shaping your curriculum, a better approach is to combine fixing the bug or delivering the project with a set of reports or presentations about the process. This presentation – maybe even a blog post, because working in the open is important – can be a discussion of what the student is working on and why it’s important, how the work progressed and what the process of getting a patch in looks like, as well as the challenges they’ve faced and what they’ve learned from it.
Making three or four “this is my experience and what I’ve learned so far” reports over the term a more important part of the grading process than the code itself helps enormously, both in terms of keeping everyone involved motivated and in reflecting the open, community-oriented values of the project. There are other options for instructors who are familiar with our processes – breaking up the grade up so that submitting a patch that builds, responding to the first review and so on all count, even if the patch isn’t ultimately accepted, is one possibility.
The second major challenge is finding bugs that are a good fit for their contributors. We’re getting better at that – good first bugs usually tell you what language they rely on ( [lang=c++] in the Bugzilla whiteboard flags, for example) and often have a pretty good outline of what a successful patch would look like and a mentor associated with them. And while we can’t promise to privilege students ahead of any other contributors, we certainly try to hold up our end of the bargain and answer new contributors’ questions promptly.
One thing that takes the edge off there is that class of bug – “good first bugs”, you can search for [good first bug] in the Bugzilla whiteboard – that are a nice, well-defined way to get involved. The idea behind “good first bugs” is that the major challenge of the bug isn’t the code itself, but learning how to get your development environment spun up, participating in development on IRC and Bugzilla, learning how to navigate our patch review and submission process.
It typically takes a few tries for most new contributors to get their patch through. Reviews for code format and quality, suitable tests, that sort of thing can all take an extra week or two to resolve, especially if you’re working on them around other classes. But most of our good first bugs can be resolved within a few weeks, well within a term.
You’ll have to judge for yourself if this is a good fit for your schedule, your students or your institutional goals. On the one hand, though GFBs are generally well-contained, Firefox uses every feature JS and C++ have to offer, so a certain amount of familiarity and comfort with the language is important. On the other, we’ve got a huge variety of Good First Bugs here, ranging from “correct this documentation” to “fix part of a JIT compiler”, so it’s likely that if you want to contribute, we can find a home for your efforts that will make millions of people’s lives just a little bit better.
More generally, if you’re interested in getting people involved with Mozilla in September, get in touch with us in June. Knowing in advance that people will be looking for new bugs or projects gives us time to talk to our team leads and project managers, to let us all find a place to put our efforts that will be helpful and valuable to everyone.
Which is all to say that small first-time bugs are often as inglorious as they are important; while they don’t seem like much, the small patches and first bugs of today come from the Web’s next generation of leaders.
– Mike Hoye – email@example.com