Contribuindo para o banco de códigos da Mozilla

Esta página irá guiá-lo pelos primeiros passos para contribuir com a Mozilla. Seja bem-vindo, estamos muito felizes em vê-lo :)

Precisa de ajuda?

A comunidade Mozilla se orgulha de ser uma comunidade aberta, acessível e amigável para os novos participantes. Se você tiver alguma dificuldade de se envolver ou encontrar respostas para suas perguntas, por favor, traga essas questões para a sala de chat #introduction sala de conversa irc.mozilla.org para que possamos ajudar você a começar.

Nós sabemos que - antes de você começar a contribuir - Pode ser um desafio para você configurar para trabalhar no Firefox e encontrar um bug, que é um bom ajuste para suas habilidade. Estamos sempre à procura de maneiras de melhorar esse processo e fazer com que a Mozilla se torne mais aberta, acessível e fácil de participar. Se você está tendo problemas para seguir esta documentação ou um obstáculo que está lhe impedindo, por favor entre em contato com Mike Hoye em [email protected] (por favor, escreva em inglês) para que possamos resolver o problema para você e outros colaboradores.

De quais habilidades eu preciso?

Mozilla é um grande projeto, e nós estamos felizes em receber contribuintes com diversas habilidades.

Se você programa em C++, por exemplo, você pode contribuir para o núcleo do Firefox, Firefox OS e outros produtos Mozilla.
Se você possui habilidades com JavaScript ou HTML/CSS, você pode contribuir para o front-end do Firefox, ou para o Gaia, a camada de aplicação do Firefox OS.
Se você sabe Java, você pode contribuir para o Firefox Mobile - Firefox no Android - e MozStumbler.
Se você sabe Python, você pode contribuir para nossos serviços web, incluindo o Firefox Sync ou Persona.
Se você sabe Make, shell-script, Perl ou Python, você pode contribuir para nosso sistema de desenvolvimento.
Se você sabe C, você pode contribuir para um número de bibliotecas de baixo-nível e de terceiros, que utilizamos como parte do banco de códigos da Mozilla.
Se você sabe Rust, você pode contribuir para o rustic, ou para o Servo, um motor do navegador web projetado para paralelismo e segurança.
Se você sabe Go, você pode contribuir para o Heka, uma ferramenta para processamento de dados.
Também há várias maneiras de contribuir para a missão Mozilla sem programar. Se você gostaria de estar envolvido no design, suporte, tradução, testes ou outros tipos de contribuição, acesse a página de Oportunidades para Voluntários.

Talvez você não saiba programação (ainda), mas você quer começar a aprender? seria ótimo. O programa Webmaker é para você, e há vários outros recursos disponíveis na Central de Desenvolvedores da Mozilla!

Passo 1 - Compilar o Firefox, Firefox para Android ou Firefox OS.

Se você deseja contribuir com o Firefox, siga nosso conjunto de instruções simples para compilar o Firefox, e para contribuidores móveis, você pode começar aqui compilando o Firefox para Android ou aqui para compilar o Firefox OS. É bastante simples, mas pode levar algum tempo, pois é necessário fazer alguns downloads. então você pode desejar seguir para os próximos passos enquanto compila. Mais instruções da compilação podem ser encontradas aqui.

Para outros produtos da Mozilla, incluindo a comunidade de suporte para construção do Thunderbird - podem ser encontrados com uma busca rápida, e muitas vezes você não vai precisar compilar para fazer uma contribuição.

Passo 2 - Encontre algo com o que trabalhar

Corrija seus problemas

Se há algo que você gostaria de saber sobre o Firefox, Thunderbird, ou sua aplicação favorita da Mozilla, este pode ser um bom lugar para começar. Há uma série de maneiras de fazer isso:

Procure no bugzilla por palavras-chave relevantes.
Descubra os componentes do bugzilla no qual eles serão seus problemas a serem implementados, usando a lista de componentes. Navegue pelo componente em bugzilla para ver bugs relacionados.
Pergunte em #introduction ou #developers no irc.mozilla.org.

Encontre um erro que nós marcamos como sendo bom para iniciantes

Com mais de um milhão de arquivos de bugs no Bugzilla, pode ser difícil saber por onde começar, nós criamos algumas categorias de bug para tornar seu envolvimento um pouco mais fácil:

"Bons" primeiros erros é a melhor maneira para dar seus primeiros passos no ecosistema Mozilla. Para todos os bugs bastam pequenas mudanças, às vezes tão pouco como poucas linhas, mas é uma maneira de aprender sobre configurações de desenvolvimento, navegador Bugzilla e fazer contribuições para a base de códigos da Mozilla.
Mentor de bugs são mais difíceis, mas tem um mentor que comenta para ajuda você no processo. Geralmente, tem informações suficientes no bug para você começar, sempre que precisar de ajuda, entre em contato com seu mentor no IRC, no próprio bug, ou por e-mail. Quando você completar o bug, eles irão ajudar você a obter o seu código na árvore.
Siga @StartMozilla on Twitter, onde nós mostraremos Bons Primeiros Bugs para novos contribuidores através do Mozilla, todos os dias.
Visite firefox-dev.tools, onde nós listaremos Ferramentas de bugs de Desenvolvimento Firefox para novos contribuidores.
Projetos para Estudantes são projetos maiores, que podem ser adequados para estudantes universitários. É claro que, se você não é um estudante, você também pode se sentir livre para corrigir um desses bugs. Nós mantemos duas listas, uma para projetos baseados na base de código existente, e uma para implementiar novas aplicações.

Passo 3 - Corrigindo o bug

Agora está nas suas mãos. Nós oferecemos alguns recursos para ajudar você:

Peça ajuda em um comentário, ou em #introduction ou #developers.
Confira https://developer.mozilla.org/En/Developer_Guide.
Nosso checklist de revisão é muito útil se você tem uma atualização perto de completar e quer ter certeza que será revisado favoravelmente.

Passo 4 - Tenha o seu código analisado

Uma vez corrigido o bug, anexe um patch ao bug, e peça por uma análise. Faça isso clicando em no link Detalhes no seu anexo, então mude a sinalização de análise para ? e coloque o ID de análise do bugzilla no campo de texto que aparece (e também o endereço de email de :NomeÚnico que eles providenciam). É muito importante anexar o ID do bugzilla, ou a requisição será perdida. Então como descobrir a pessoa certa para pedir pela análise?

Se você tem um supervisor de bug, peça a ele, ele mesmo pode fazer ou pode achar alguém facilmente.
Execute hg blame e procure por pessoas que já fizeram o mesmo que você está trabalhando - eles devem ser bons candidatos.
O próprio bug pode conter uma clara indicação da melhor pessoa pessoa para pedir pela análise.
Existem bugs ou tópicos similares? Nesse caso, o analisador desses bugs deve ser uma boa escolha.
Nós temos uma lista de módulos desatualizada que mostra colaboradores e donos do módulo, alguns que serão bons analisadores. No pior dos casos, coloque o dono do módulo como o analisador, e peça a ele nos comentários para ele escolher alguém com maior disponibilidade se ele não tiver tempo.

Passo 4b - Acompanhe a análise

Se você pediu por uma análise, mas o analisador não respondeu nada em alguns dias, não tenha medo de chamar sua atenção. Para isso apenas adicione um comentário ao bug dizendo 'alerta de revisão?' e tente de novo alguns dias depois caso ele ainda não tenha respondido. Se ele ainda não respondeu depois disso, peça ajuda no IRC nos canais #introduçao ou #desenvolvedores ou contate Myke Hoye diretamente.

Passo 5 - Responda à avaliação

Para a maioria dos novos contruibuíntes - e de forma frequente para os Mozzilians de longa data - a primeira avaliação de sua correção será um r-. Isso não quer dizer que você tenha feito um trabalho ruim, mas que você ainda tem algum trabalho pela frente antes que seu código possa ser inserido no banco. Sua correção talvez precise de algumas modificações - talvez pequenas, talvez grandes - e seu analisador irá te guiar no que você precisa fazer a seguir.

Esse é um processo importante, então não desanime! Com uma base de códigos de longa data e centenas de milhões de usuários, o cuidado e a atenção que vai para ajudar os contribuidores a fazerem um bom código de correção é o pilar do projeto Mozilla. Faça as mudanças que seu analisador pediu; se você não tiver certeza de como fazer, tenha certeza em perguntar! Anexe a nova correção ao bug de novo, e peça pela análise de novo para o mesmo analisador. Se ele te der um r+ isso significa que seu bug foi aceito para ser inserido no banco.

Passo 6 - Na verdade obtenha o código na árvore

Uma vez que seu patch tenha recebido um r+, está pronto para ir. Mas, antes que se possa dar o merge na árvore, seu patch precisará completar uma execução bem sucedida através do nosso "teste de servidor" para ter certeza que isso não causa nenhuma regressão inesperada; seu mentor ou a pessoa que revisou seu path estará apta para ajudar com isso, se você já não tem o acesso ao teste de servidor.

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.

Passo 7 - Repetição

Muito obrigado. Você solucionou o seu primeiro bug, e a internet aberta é mais forte com isso. Mas não pare agora.

Volte para o passo 3; existe muito mais a ser feito. Seu mentor pode sugerir um novo bug para você soluciona-lo, ou você pode achar um do seu interrese. 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.

Mais informações

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: