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ê.
Ferramentas básicas e fluxo de trabalho
Se você é um novo voluntário no Django, esse Escrevendo seu primeiro patch para Django tutorial te dará uma introdução as ferramentas e ao fluxo de trabalho.
Primeiros passos¶
Comece com essas tarefas simples para descobrir como é o processo de desenvolvimento do Django.
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
A base de código costuma mudar entre o momento em que um patch é submetido e o momento em que ele é revisado. Certifique-se de que ele ainda seja aplicado de forma limpa e que ele funcione da maneira esperada. A simples atualização de um patch já é útil e importante! Saiba mais em 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.
FAQ¶
**Este ticket que me interessa foi ignorado por dias/semanas/meses! O que eu posso fazer para que ele seja commitado?
First off, it’s not personal. Django is entirely developed by volunteers (except the Django fellow), and sometimes folks just don’t have time. The best thing to do is to send a gentle reminder to the django-developers mailing list asking for review on the ticket, or to bring it up in the #django-dev IRC channel.
Eu tenho certeza que o meu ticket está absolutamente 100% perfeito, posso marcá-lo como RFC eu mesmo?
Resposta curta: Não. É sempre melhor ter outros conjuntos de olhos em um ticket. Se você está tendo problemas para obter esse segundo conjunto de olhos, veja a questão 1, acima.
