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\nThis page contains more general advice on ways you can contribute to Django,\nand how to approach that.
\nSe você está procurando por uma referência sobre os detalhes de fazer contribuições de código, veja a documentação Enviando patches.
\nStart with these steps to discover Django’s development process.
\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
\nOftentimes the codebase will change between a patch being submitted and the\ntime it gets reviewed. Make sure it still applies cleanly and functions as\nexpected. Updating a patch is both useful and important! See more on\nEnviando 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\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.
\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.
\nBe patient
\nIt’s not always easy for your ticket or your patch to be reviewed quickly.\nThis isn’t personal. There are a lot of tickets and pull requests to get\nthrough.
\nKeeping your patch up to date is important. Review the ticket on Trac to\nensure that the Needs tests, Needs documentation, and Patch needs\nimprovement flags are unchecked once you’ve addressed all review comments.
\nRemember that Django has an eight-month release cycle, so there’s plenty of\ntime for your patch to be reviewed.
\nFinally, a well-timed reminder can help. See contributing code FAQ for ideas here.
\n