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ê.
\n\nComece com essas tarefas simples para descobrir como é o processo de desenvolvimento do Django.
\nAssine o Acordo de Licença do Contribuidor
\nO 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.
\nTriagem de tickets
\nSe 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?
\nProcure por tickets que são aceitos e revise os patchs para criar familiaridade com o processo e a estrutura do código.
\nAdicione 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!
\nMantenha patches antigos atualizados
\nA 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.
\nEscreve alguma documentação
\nA 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.
\n\nComo 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.
\nEscolha um assunto que você te interesse, com o qual você esteja familiarizado, ou que você queira aprender
\nVocê 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.
\nAnalise o contexto e histórico dos tickets
\nTrac isn’t an absolute; the context is just as important as the words.\nWhen reading Trac, you need to take into account who says things, and when\nthey were said. Support for an idea two years ago doesn’t necessarily mean\nthat the idea will still have support. You also need to pay attention to who\nhasn’t spoken – for example, if an experienced contributor hasn’t been\nrecently involved in a discussion, then a ticket may not have the support\nrequired to get into Django.
\nComece devagar
\nÉ mais fácil obter retorno para um problema pequeno do que para um problema grande. Veja os easy pickings.
\nSe você planeja se engajar em uma tarefa grande, certifique-se que a sua ideia possui apoio primeiro
\nThis means getting someone else to confirm that a bug is real before you fix\nthe issue, and ensuring that there’s consensus on a proposed feature before\nyou go implementing it.
\nSeja corajoso! Deixe comentários!
\nSometimes it can be scary to put your opinion out to the world and say “this\nticket is correct” or “this patch needs work”, but it’s the only way the\nproject moves forward. The contributions of the broad Django community\nultimately have a much greater impact than that of any one person. We can’t\ndo it without you!
\nPeque por excesso de precaução ao marcar coisas como Ready For Check-in
\nSe 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.
\nAguarde por feedback, e responda ao feedback que você receber
\nFoque-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.
\nSeja rigoroso
\nQuando 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.
\n**Este ticket que me interessa foi ignorado por dias/semanas/meses! O que eu posso fazer para que ele seja commitado?
\nFirst off, it’s not personal. Django is entirely developed by volunteers\n(except the Django fellow), and sometimes folks just don’t have time. The\nbest thing to do is to send a gentle reminder to the django-developers\nmailing list asking for review on the ticket, or to bring it up in the\n#django-dev IRC channel.
\nEu tenho certeza que o meu ticket está absolutamente 100% perfeito, posso marcá-lo como RFC eu mesmo?
\nResposta 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.
\n