Contribuir para código base da Mozilla

This translation is incomplete. Please help translate this article from English

Esta página deverá guiá-lo através dos passos iniciais para contribuir para a Mozilla. Bem-vindo, nós estamos muito contentes pela sua visita :) 

Precisa de ajuda?

A comunidade da Mozilla orgulha-se de ser uma comunidade aberta, acessível e amigável para os novos participantes. Se tiver alguma dificuldade para se envolver ou encontrar respostas às suas perguntas, por favor, traga essas perguntas para #introduction chat room on, onde nós podemos ajudá-lo a começar.

Nós sabemos mesmo antes de começar a contribuir que configurar, trabalhar no Firefox e encontrar um erro que seja adequado às suas capacidades, pode ser um desafio. Nós estamos sempre à procura de maneiras para melhorar esse processo: tornar o Mozilla mais aberto, acessível e mais fácil de participar. Se está a ter problemas para seguir esta documentação, ou encontrar uma barreira em que não a consegue contornar, entre em contacto com Mike Hoye via  em Nós estamos determinados a resolver os obstáculos para os novos colaboradores.

Que aptidões é que eu preciso?

A Mozilla é um projeto muito vasto e nós ficamos contentes por ter voluntários com diferentes aptidões.

  • Se sabe C++, por exemplo, pode contribuir para camadas núcleo do Firefox, e para outros produtos da Mozilla.
  • Se sabe JavaScript ou HTML/CSS, pode contribuir para o desenvolvimento do frontend do Firefox.
  • Se sabe Java, pode contribuir para o Firefox Mobile, Firefox para Android, e MozStumbler.
  • Se sabe Swift, pode contribuir para o Firefox para iOS e Firefox Focus para iOS.
  • Se sabe Python, pode contribuir para os nossos serviços da Web, incluíndo Firefox Sync, ou Contas firefox.
  • Se sabe Make, shell, Perl or Python, pode contribuir para o desenvolvimento do nosso sistema de compilação (build), engenharia de lançamento e automação.
  • Se sabe C, pode contribuir para NSS, Opus, e Daala.
  • Existem ainda muitas mais maneiras de como contribuir para a missão da Mozilla sem saber programação. Se participar nas áreas de desenho, suporte, tradução, testes, ou outros tipos de contribuição desperta o seu interesse, por favor veja consulte a página Seja voluntário na Mozilla.

Talvez ainda não saiba programação, mas quer começar a aprender? Existem muitos recursos disponíveis na MDN Web Docs!

Passo 1 - Criar Firefox para PC e Android

If you'd like to contribute to Firefox, simple instructions to build desktop Firefox are here, and mobile contributors can get started here to build Firefox for Android. 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. Additional build instructions can be found here.

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

Passo 2 - Encontre algo para trabalhar

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:

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 - we link up Good First Bugs for new contributors across Mozilla every day
  • Visit - 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.



Passo 3: Corrigir o erro (bug)

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



Passo 4: Rever o seu código


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

We now favor using our code review platform MozReview.
You can still submit a manual patch, but MozReview is absolutely preferred.
Check the MozReview documentation on Creating commits and Submitting review requests.

You can attach a patch to the bug and ask for a review. Do this by clicking the Details link on your attachment, then set the review flag to ?, and enter 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.

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 and look for the people who have touched the functions you're working on. They too are good candidates
  • 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 an out of date 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


Step 4b: Siga-a

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 then you can ask for help on IRC in the #introduction, or #developers channels, or contact Mike Hoye directly.

Passo 5: Responder à revisão

For most new contributors, even for long time Mozillians, the first review of your patch will be an "r-". This does not mean you've done bad work. There is more 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 on what needs to be done next.

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

Passo 6: Getting code into the tree

Once your patch has received an r+, it is ready to go. Before it can be merged into the tree, your patch will need to complete a successful run through our try server, making sure there are no unexpected regressions. If you don't have try server access already, your mentor, or the person who reviewed your patch, will be able to help.

Once you have 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 update the bug as required. If your patch passes all Mozilla's automated testing, it will soon be merged into the main branch, and become a part of the Nightly build.

Passo 7: Repetição

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 3, 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 push your own code, after it has been read.

Mais informação


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: