This page should guide you through the first steps of contributing to Mozilla. Welcome, we're delighted to see you :)
The Mozilla community always welcomes newcomers to our midst. If you have any difficulties anywhere while joining us, you can ask questions in the #introduction chat room on irc.mozilla.org. If you're still having problems, please contact Paul Biggar at firstname.lastname@example.org.
We have many tasks and projects that don't require you to know C++. Check out our alternate introduction.
Step 1 - Build Firefox
Follow our set of simple instructions to build firefox. This is straightforward, but may take some time, so you may want to move on to the next steps while it builds.
Step 2 - Understand how contributing to Mozilla works
See "Software Engineering for Firefox" (attached at the bottom of this page) for a top-level view of Mozilla's development process.
Step 3 - Find something to work on
Fix your pet peeve
If there's something you'd like to fix about Firefox, this can be a good place to start. There are a number of ways to do this:
- Run Firefox under a debugger, and randomly stop execution and examine the stack trace,
- Search bugzilla for relevant keywords,
- Figure out the bugzilla component 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 being good for newcomers
Mozilla developers label certain bugs as being an easy bug to get newcomers acquainted with our processes:
- Mentored bugs have a mentor who commits to helping you every step of the way. Generally, there should be enough information in the bug to get started. Whenever you need help, contact them 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. (We've only recently started creating mentored bugs, so there may be a shortage right now.)
- "Good" first bugs may be a little stale, but at some point in their lives we considered that they would be a good first step for newcomers to Mozilla. We are in the process of migrating these bugs to mentored bugs, but more recent "good first bugs" may be good starting points if there are no appropriate mentored bugs.
- 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.
Step 4 - Fix the bug
We leave this in your capable hands. We have some resources to help you here too:
- Check out https://developer.mozilla.org/En/Developer_Guide,
- Ask for help in a comment on the bug, or in #introduction or #developers.
Step 5 - Get your code reviewed
Once you fix the bug, attach a patch to the bug, and ask for review. You do this by setting r? followed by the reviewer's bugzilla ID. It is very important to attach a bugzilla ID, or the bug 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 can find out easily.
hg blameand look at the people who have touched the function's 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 5b - Follow it up
If you've asked for review, but the reviewer hasn't said anything for a few days, don't be afraid to ping them. Just add a comment to the bug saying 'review ping?', and another a few days later if they still haven't responded. If they don't respond after that, ask for help in #introduction or #developers.
Step 6 - Respond to the review
Often, a reviewer will ask for changes, perhaps minor, perhaps major. In either case, fix what the 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 7 - Actually get the code into the tree
Since you don't yet have the ability to push the code into the tree, you should ask somebody for help. If you have a mentor, ask them. If not, ask the reviewer. If the reviewer is too busy, mark that a commit is needed by adding the checkin-needed keyword. A friendly person should be along within a few days and push the code to the repository, and they will mark the bug as fixed.
Step 8 - Repeat
Congratulations, you've fixed your first bug. Now go back to step 3 and repeat. Now that you've got your first bug in, you should request level 1 access to the repository so that you can push to tryserver and get automated feedback about your changes on multiple platforms. After a nontrivial number of bugs, you should request level 2/3 access (depending on the repository you're using) so that you can push your own code after it has been r+ed.
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: