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.
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.
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.
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 não é absoluto; o contexto é tão importante quanto as palavras. Ao ler o Trac, você deve levar em consideração quem está escrevendo coisas e quando essas coisas foram escritas. Suporte para uma ideia dois anos atrás não necessariamente significa que a ideia ainda terá suporte atualmente. Você também precisa prestar atenção em quem não participou da discussão – por exemplo, se um membro do projeto Django não se envolveu recentemente em uma discussão, então o ticket pode não ter o suporte necessário para entrar no trunk.
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
Isso significa que outra pessoa deve confirmar que um bug é real antes de você corrigir o problema, e garantir que o time do projeto apoia a ideia proposta antes de você começar a implementá-la.
Seja corajoso! Deixe comentários!
Às vezes pode ser assustador deixar a sua opinião escancarada para o mundo e dizer “este ticket está correto” ou “este patch precisa ser melhorado”, mas essa é a única maneira de fazer o projeto seguir em frente. As vastas contribuições da comunidade Django no final tem um impacto muito maior do que as próprias contribuições do time do projeto. Nós não somos capazes de fazer isso sem vocês!
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?
Primeiro que isso não é pessoal. O Django é inteiramente desenvolvido por voluntários (mesmo o time principal), e as vezes as pessoas apenas não tem tempo. A melhor coisa a se fazer é enviar um lembrete gentil para a lista django-developers perguntando por uma avaliação do ticket, ou trazer a tona no canal de irc #django-dev.
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.
