I recently made my first contributions to Firefox Desktop.
I have landed three patches so far, resolving bugs 1895394, 1899687, and 1950995.
Beginning in this post, I’ll write about some of the work I’ve done and Firefox development generally.
This post introduces the tools of the trade, how to pick your first bug, and some brief notes on what my first contributions were.
The tools
The Firefox development ecosystem includes numerous tools, but some of the most important to understand are Bugzilla, Phabricator, Matrix, and Searchfox.
Bugzilla is the issue tracking system, where bugs (issues) are reported, discussed, and closed.
When you are working on a bug and have code to contribute, either as a work in process or ready for review, you push it to Phabricator. On Phabricator, code changes are discussed, reviewed, and approved.
For more general communication, community communication channels are Matrix chat rooms. There is an #introduction channel ideal for new contributors’ questions.
Searchfox is a bespoke search tool for the Firefox source code, useful both for finding things yourself and for linking specific lines of source code in discussions with other developers.
The Firefox source has a dedicated documentation site, including onboarding information for new contributors. See for instance Getting Set Up To Work On The Firefox Codebase.
Pick a “good first bug”
I will describe some basics of how to make your first contribution to Firefox. If you wish to contribute, refer to the Firefox source docs for thorough and up to date instructions.
Contribution starts with setting up your development environment. Use the bootstrap script to download the source code and install dependencies, confirm you can build and run it, and debug any issues that crop up.
To make your first contribution, you will probably want to pick an existing bug that has been described and categorized as a good first bug. You can filter on Bugzilla for the keyword good-first-bug, or browse Mozilla’s Codetribute, a site for finding your first bug.
One benefit of Firefox development happening out in the open is that you can dig into the source code and start thinking about a bug on your own without having to ask permission or make any commitments. Hopefully, a look around the bug description and relevant source code will give you a sense of whether it is a problem you want to tackle.
You can post on Bugzilla indicating that you are planning to submit a patch for the bug, thereby saving someone else the trouble of wasting time doing parallel work, but you can also wait until you have a solution, and then submit a patch.
As you work on a bug, there’s a good chance you will have questions, whether about general development processes or the particular bug. If there is a mentor assigned to the bug on Bugzilla, that’s a great person to ask questions about the particular bug. You can also ask in Matrix.
My first contributions were cleanup
The name “bug” may lead you to think that the issues tracked on Bugzilla are things that are broken or missing. They can be, but there are also tasks aimed at improving code that already works. You may even end up mostly deleting code, as I did in my first contributions.
The first three patches I landed all related to removing “prefs” that were no longer needed or wanted. A pref is a setting, such as for a user preference or a feature toggle. There are a lot of them, and some of them aren’t necessary anymore. This excess is enough of an issue that there is a meta bug collecting bugs about removing old prefs.
Deleting code may sound easy, and these were reasonably accessible bugs to start out with, but it does require some care to make sure that what you leave behind is correct. Even when taking a feature toggle that has been defaulted to on for years, and removing the prefs that allows it to be turned off, you may find it cropping up across the codebase in ways that can’t simply be deleted.
In future posts I will discuss some of the complications I ran into on these bugs.
Contributing is its own problem
I recommend deliberately starting with bugs that are easy enough that solving the programming problem of the bug is not a major obstacle. The development process is easier to learn if you aren’t also trying to solve a hard programming problem. Knock out some easy bugs while learning how to submit code and communicate throughout the development life cycle.
My first contributions to Firefox did not have earthshattering impact on the browser, but they made me ready to tackle harder problems.
In an upcoming post, I will discuss the first bug I completed, telling the story of how I got my wits about me and sharing some of the lessons I’ve learned so far.