Conselho aos novos voluntários¶
Você é um novo voluntário e não sabe o que fazer? Quer ajudar mas não sabe por onde começar? Esta seção foi feita para você.
Get up and running!
Se você é um novo voluntário no Django, esse Writing your first contribution for Django tutorial te dará uma introdução as ferramentas e ao fluxo de trabalho.
This page contains more general advice on ways you can contribute to Django, and how to approach that.
Se você está procurando por uma referência sobre os detalhes de fazer contribuições de código, veja a documentação Enviando patches.
Primeiros passos¶
Start with these steps to discover Django’s development process.
Triagem de tickets
Se um ticket não revisado reporta um novo bug, tente reproduzi-lo. Se você pode reproduzi-lo e ele parece válido, faça uma nota informando que você confirmou o bug e aceitou o ticket. Certifique-se de que o ticket foi criado na área correta. Considere escrever um patch adicionando um teste para o comportamento apontado no bug, mesmo que você não corrija o problema em si. Veja mais em Como eu posso ajudar com a triagem?
Procure por tickets que são aceitos e revise os patchs para criar familiaridade com o processo e a estrutura do código.
Adicione as tags apropriadas caso um patch necessite de documentação ou testes. Analise as mudanças que o patch provoca, fique atento com síntaxe incompatível com versões antigas do Python e que ainda são suportadas. Rode os testes e certifique-se de que eles passaram. Quando possível e relevante, tente rodá-los em uma base diferente do SQLite. Deixe comentários e feedback!
Mantenha patches antigos atualizados
Oftentimes the codebase will change between a patch being submitted and the time it gets reviewed. Make sure it still applies cleanly and functions as expected. Updating a patch is both useful and important! See more on Enviando patches.
Escreve alguma documentação
A documentação do Django é ótima, mas sempre pode ser melhorada. Você achou um erro de digitação? Acha que algo pode ser esclarecido? Vá em frente e sugira uma “patch” para a documentação! Veja também o guia de Escrevendo a documentação.
Nota
A página de relatórios contém links para muitas consultas úteis no Trac, incluindo muitas úteis na triagem de tickets e revisão de patches como sugerido acima.
Assine o Acordo de Licença do Contribuidor
O código que você escreve pertence a você ou ao seu empregador. Se a sua contribuição é de uma ou duas linhas de código, você deve assinar o CLA. Veja a FAQ do Contributor License Agreement para uma explicação mais detalhada.
Orientações¶
Como um recém-chegado em um projeto gigantesco, É fácil acabar se frustrando. Aqui vão algumas dicas para fazer o seu trabalho no Django ser mais útil e recompensador.
Escolha um assunto que você te interesse, com o qual você esteja familiarizado, ou que você queira aprender
Você não precisa já ser um expert na sua área de atuação para poder atuar nela; você se torna um expert à medida em que vai dando suas contribuições com o código.
Analise o contexto e histórico dos tickets
Trac isn’t an absolute; the context is just as important as the words. When reading Trac, you need to take into account who says things, and when they were said. Support for an idea two years ago doesn’t necessarily mean that the idea will still have support. You also need to pay attention to who hasn’t spoken – for example, if an experienced contributor hasn’t been recently involved in a discussion, then a ticket may not have the support required to get into Django.
Comece devagar
É mais fácil obter retorno para um problema pequeno do que para um problema grande. Veja os easy pickings.
Se você planeja se engajar em uma tarefa grande, certifique-se que a sua ideia possui apoio primeiro
This means getting someone else to confirm that a bug is real before you fix the issue, and ensuring that there’s consensus on a proposed feature before you go implementing it.
Seja corajoso! Deixe comentários!
Sometimes it can be scary to put your opinion out to the world and say “this ticket is correct” or “this patch needs work”, but it’s the only way the project moves forward. The contributions of the broad Django community ultimately have a much greater impact than that of any one person. We can’t do it without you!
Peque por excesso de precaução ao marcar coisas como Ready For Check-in
Se você realmente não tem certeza se um ticket está pronto, não o marque como pronto. Ao invés disso deixe um comentário, deixe que outras pessoas saibam o que você acha. Se você tem praticamente certeza, mas não totalmente, você também pode tentar perguntar no IRC para ver se mais alguém confirma as suas suspeitas.
Aguarde por feedback, e responda ao feedback que você receber
Foque-se em um ou dois tickets, veja eles inteiros do começo ao fim, e repita. A estratégia da escopeta de pegar vários tickets e deixar alguns falhar pelo lado acaba fazendo mais mal do que bem.
Seja rigoroso
Quando nós dizemos “PEP 8, e que deve ter documentação e testes, é sério. Se um patch não tiver documentação e testes, ele deve possuir uma boa razão para isso. Argumentos como “Eu não consegui achar quaisquer testes existentes dessa funcionalidade” não tem grande peso–embora eles possam ser verdadeiros, isso significa que você tem o importantíssimo trabalho de escrever os primeiros testes para essa funcionalidade, e não que você está livre de ter que escrevê-los.
Be patient
It’s not always easy for your ticket or your patch to be reviewed quickly. This isn’t personal. There are a lot of tickets and pull requests to get through.
Keeping your patch up to date is important. Review the ticket on Trac to ensure that the Needs tests, Needs documentation, and Patch needs improvement flags are unchecked once you’ve addressed all review comments.
Remember that Django has an eight-month release cycle, so there’s plenty of time for your patch to be reviewed.
Finally, a well-timed reminder can help. See contributing code FAQ for ideas here.
