Contributing to the Mozilla code base 编辑

Need help?

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

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 come and ask your questions in our chatroom, where we can help you get started.

We know even before you start contributing that 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 this process: making Mozilla more open, accessible, and easier to participate with. If you're having any trouble following this documentation, or hit a barrier you can't get around, please contact Mike Hoye at mhoye@mozilla.com. We're determined to solve hurdles for new contributors.

What skills do I need?

Mozilla is a large project and we are thrilled to have contributors with very diverse skills

Below is a table with our currently available projects to contribute to, along with the skills needs and links to their documentation.

There are even many ways to contribute to the Mozilla mission without programming. If getting involved in design, support, translation, testing, or other types of contributions sparks your interest please see community website.

Perhaps you do not know programming yet, but you want to start learning? There are plenty of resources available on the MDN Web Docs!

Step 1: Find something to work on

Bugs listed as 'Assigned' are not usually a good place to start unless you're sure you have something worthy to contribute. Someone else is already working on it!
Even with no assignee, it is polite to check if someone has recently commented that they're looking at fixing the issue.

Once you have found something to work on, go ahead and comment! Let the bug submitter, reviewer, and component owner know that you'd like to work on the bug. You might receive some extra information, perhaps also made the assignee.

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 great place to start. There are a number of ways to do this:

• Search Bugzilla for relevant keywords. See pages on Bugzilla and Searching Bugzilla for further help
• Learn the Bugzilla component, with which your pet peeve is implemented, using the components list. Browse this component on Bugzilla for related bugs
• Ask in our Matrix channels : #introduction:mozilla.org or #developers: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:

• Codetribute - our site for finding bugs that are mentored, some are good first bugs, some are slightly harder. Your mentor will help guide you with the bug fix and through the submission and landing process.
• 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.
• Visit firefox-dev.tools - 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, 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.

Use a bug searching tool

There are several tools developed by members of the Mozilla community. These help
new contributors find bugs to work on, without having to use Bugzilla's more perplexing search component.

• MozBugs

Step 2: Fix the bug

We leave this in your hands. Here are some further resources to help:

• Ask for help in a comment on the bug, or in #introduction:mozilla.org or #developers:mozilla.org
• Check out https://firefox-source-docs.mozilla.org/setup/  and https://firefox-source-docs.mozilla.org/contributing/contribution_quickref.html
• Our reviewer checklist is very useful, if you have a patch near completion, and seek a favorable review
• Utilize our build tool Mach and it's linting, static analysis, and other code checking features

Step 3: Get your code reviewed

Once you fix the bug, you can advance to having your code reviewed.

When you commit your code, please use the following format for your commit message:
`Bug Number - What your patch does; r?reviewer`
For example, a commit message may look like `Bug 1234567 - Remove reflow by caching element size. r?jsample`

Mozilla in most of the projects uses Phabricator for code review.

Who is the right person to ask for a review?

• If you have a mentored bug: ask your mentor. They will help, or can easily find out. It might be them!
• Run hg blame on the file and look for the people who have touched the functions you're working on. They too are good candidates.
  Running hg log and looking for regular reviewers might be a solution too.
• The bug itself may contain a clear indication of the best person to ask for a review
• Are there related bugs on similar topics? The reviewer in those bugs might be another good choice
• We have a list of modules, which lists peers and owners for the module. Some of these will be good reviewers. In a worst case scenario, set the module owner as the reviewer, asking them in the comments to pick someone more suitable

Please select only one reviewer.

Step 3b: Follow it up

Once you've asked for a review, a reviewer will often respond within a day or two, reviewing the patch, or saying when they will be able to review it, perhaps due to a backlog. If you don't hear back within this time, naturally reach out to them: add a comment to the bug saying 'review ping?', check the "Need more information from" box, and add the reviewer's name. If they don't respond within a day or two, you can ask for help on Matrix in the #introduction:mozilla.org or #developers:mozilla.org channels, or contact Mike Hoye directly.

Don't hesitate to contact your mentor as well if this isn't moving.

Step 4: Repeat

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

Go back to step 1, as there is plenty more to do. Your mentor might suggest a new bug for you to work on, or find one that interests you.  Now that you've got your first bug fixed you should request level 1 access to the repository to 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 you can land your own code after it has been reviewed.

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:

• A guide to learning the mozilla codebase
• A beginner's guide to SpiderMonkey, Mozilla's JavaScript engine
• Mozilla platform development cheatsheet (Wayback Machine)