Contributing to the Mozilla code base

This page should guide you through the first steps of contributing to Mozilla. Welcome, we're delighted to see you! :)

Need help?

The Mozilla community prides itself on being an open, accessible and friendly community for new participants. If you have any difficulties getting involved or finding answers to your questions, please bring those questions to the #introduction chat room on irc.mozilla.org so that we can help you get started.

We know that - before you can even start contributing - getting set up to work on Firefox and finding a bug that's a good fit for your skills can be a challenge. We're always looking for ways to improve that process and make Mozilla more open, accessible and easier to participate in. If you're having trouble following this documentation or hit a roadblock you can't get around, please contact Mike Hoye at [email protected] directly so we can solve the problem for you and every new contributor afterwards.

What skills do I need?

Mozilla is a large project and we are happy to receive contributors with very different skills.

If you know C++, for instance, you can contribute to the core layers of Firefox, B2G OS, and other Mozilla products.
If you know JavaScript or HTML/CSS, you can contribute to the front-end of Firefox, or to Gaia, the application layer of B2G OS.
If you know Java, you can contribute to Firefox Mobile - Firefox on Android - and MozStumbler.
If you know Python, you can contribute to our web services, including Firefox Sync or Firefox Accounts.
If you know Make, shell, Perl, or Python, you can contribute to our build system.
If you know C, you can contribute to NSS, Opus, and Daala.
If you know Rust, you can contribute to rustc, or to Servo, a web browser engine designed for parallelism and safety.
If you know Go, you can contribute to Heka, a tool for data processing.
And there are also many ways to contribute to the Mozilla mission without programming. If you'd like to get involved in design, support, translation, testing, or other types of contributions, see the Volunteer Opportunities page.

Perhaps you do not know programming yet but you want to start learning? That's great too, the Webmaker program is for you, and there are more resources available on the Mozilla Developer Network!

Step 1 - Build Firefox, Firefox for Android or B2G OS.

If you'd like to contribute to Firefox, simple instructions to build desktop Firefox are here, and for mobile contributors, you can get started here to build Firefox for Android or here to build B2G OS. Getting set up may take some time - there are some big downloads involved - so you may want to move on to the next steps while it builds. More build instructions can be found here.

Mozilla's other products—including the community-supported Thunderbird builds—can be found with a quick search, and often you won't need to build anything to make a contribution.

Step 2 - Find something to work on

Fix your pet peeve

If there's something you'd like to fix about Firefox, Thunderbird, or your other favorite Mozilla application, this can be a good place to start. There are a number of ways to do this:

Search bugzilla for relevant keywords.
Figure out the bugzilla component in which your pet peeve is implemented, using the components list. Browse that component on bugzilla for related bugs.
Ask in #introduction or #developers on irc.mozilla.org.

Find a bug we've identified as a good fit for new contributors.

With more than a million bugs filed in Bugzilla it can be hard to know where to start, so we've created these bug categories to make getting involved a little easier:

Good First Bugs are the best way to take your first steps into the Mozilla ecosystem. They're all about small changes - sometimes as little as a few lines - but they're a great way to learn about setting up your development environment, navigating Bugzilla and making contributions to the Mozilla codebase.
Mentored bugs are more challenging, but have a mentor who commits to helping you through the process. Generally, there should be enough information in the bug to get started. Whenever you need help, contact the mentor over IRC, in the bug itself, or by email. When you've completed the bug, they will help you get your code into the tree.
Follow @StartMozilla on Twitter, where we link up Good First Bugs for new contributors across Mozilla every day.
Visit firefox-dev.tools, where we list Firefox Developer Tools bugs for new contributors
Student Projects are larger projects, such as might be suitable for a university student for credit. Of course, if you are not a student, you should still feel free to fix one of these bugs. We maintain two lists, one for projects based on the existing codebase and one for implementing new applications.

Step 3 - Fix the bug

We leave this in your capable hands. We have some resources to help you here too:

Ask for help in a comment on the bug, or in #introduction or #developers
Check out https://developer.mozilla.org/En/Developer_Guide
Our reviewer checklist is very useful if you have got a patch close to completion and want to make sure it will be reviewed favourably.

Step 4 - Get your code reviewed

Once you fix the bug, attach a patch to the bug and ask for review. Do this by clicking the Details link on your attachment, then setting the review flag to ? and entering the reviewer's bugzilla ID in the text field that appears (either their email address or the :UniqueName they provide). It is very important to attach a bugzilla ID, or the request will be missed. So how do you figure out the right person to ask for a review?

If you have a mentored bug, ask your mentor; they will know, or they can find out easily. It might even be them!
Run hg blame and look at the people who have touched the functions you've worked on - they will be a good candidate.
The bug itself may contain a clear indication of the best person to ask for a review.
Are there related bugs on similar topics? In that case, the reviewer in those bugs might be a good choice.
We have an out of date list of modules which lists peers and owners for the module, some of whom will be a good reviewer. In the worst case, set the module owner as the reviewer, and ask them in the comment to pick someone better if they don't have time.

Step 4b - Follow it up

Once you've asked for a review, a reviewer will generally get back to you within a day or two either to review the patch or, if they're backlogged, when they'll be able to review it. If you haven't heard back within that time don't be afraid to reach out to them; add a comment to the bug saying 'review ping?', check the "Need more information from:" box in the bug and add the reviewer's name. If they don't respond within a day or two then you can ask for help on IRC in the #introduction or #developers channels or contact Mike Hoye directly.

Step 5 - Respond to the review

For most new contributors - and often for long time Mozillians! - the first review of your patch will be an r-. This doesn't mean you've done bad work, but it does mean that there is still some work to do before the code can be merged into the tree. Your patch may need some changes - perhaps minor, perhaps major - and your reviewer will give you some guidance about what needs to be done next.

This is an important process, so don't be discouraged! With a long-lived codebase and hundreds of millions users, the care and attention that goes into helping contributors merge solid patches is the cornerstone of the Mozilla project. Make the changes your reviewer asks for; if you're unsure how, be sure to ask! Attach the new patch to the bug again, and ask for review again from the same reviewer. If they give you an r+ that means that your bug is accepted into the tree!

Step 6 - Actually get the code into the tree

Once your patch has received an r+, it is ready to go. But before it can be merged into the tree, your patch will need to complete a successful run through our "try server" to make sure it doesn't cause any unexpected regressions; your mentor or the person who reviewed your patch will be able to help with that, if you don't have try server access already.

Once you've got a green try server run, mark that your patch is ready to commit by adding the checkin-needed keyword to the "keywords" field at the top of the bug. A friendly Mozillian with commit access will be along shortly to push your patch to the repository, and they will update the bug as required. If your patch has passed all of Mozilla's automated testing, soon it will be merged into the main branch and become a part of our nightly builds.

Step 7 - Repeat

Thank you. You've fixed your first bug, and the Open Web is stronger for it. But don't stop now.

Go back to step 3; there is a lot more to do. Your mentor can suggest a new bug for you to work on, or you can find one yourself that interests you. And now that you've got your first bug fixed, you should request level 1 access to the repository so that you can push to the try server and get automated feedback about your changes on multiple platforms. After fixing a nontrivial number of bugs, you should request level 3 access so that you can push your own code after it has been r+ed.

More information

We're in the process of improving information on this page for newcomers to the project. We'll be integrating some information from these pages soon, but until then you may find them interesting in their current form: