FAQ: Contribuindo com o código¶
Como eu posso começar a contribuir com código para o Django?¶
Obrigado por perguntar! Nós escrevemos um documento inteiro para esta questão. É intitulado: Contribuindo com o Django.
Eu enviei uma correção de bug há varias semanas. Por que vocês estão ignorando minha contribuição?¶
Não se preocupe: Nós não estamos te ignorando!
É importante entender que existe uma diferença entre: “um tíquete está sendo ignorado” e “um tíquete ainda não foi atendido”. O sistema de tíquetes do Django contém centenas de tíquetes abertos com diferentes graus de impacto na funcionalidade para o usuário final, e os desenvolvedores do Django precisam revê-los e priorizá-los.
Acima de tudo: as pessoas que trabalham com o Django são voluntários. Como resultado, a quantidade de tempo disponível que nós temos para trabalhar no framework é limitado e irá variar de semana a semana dependendo de nosso tempo livre. Se estivermos ocupados, nós não estaremos disponíveis para dedicar tanto tempo com o Django quanto gostaríamos.
A melhor maneira de ter certeza de que os tíquetes não vão ficar parados no caminho para o check-in é deixá-los bem fáceis, mesmo para alguém que pode não ser intimamente familiar com aquela área do código, para compreender o problema e verificar a solução:
Existem instruções claras de como reproduzir o bug? Se isso envolve uma dependência (como o Pillow), um módulo de terceiros ou um banco de dados específico, essas instruções são claras o suficiente? Mesmo para alguém não familiar com isso?
Se existem diversos branches vinculados ao tíquete, está claro o que cada um faz, quais podem ser ignorados e quais são relevantes?
A alteração inclui um teste unitário? Se não, há uma explicação bem claro do por que não? Um teste expressa de maneira suscinta o que é o problema, e mostra qual branch o resolve.
Se sua contribuição não se encaixar em uma inclusão no Django, nós não vamos ignorá-la – nós vamos fechar o tíquete. Então se o seu tíquete ainda está aberto, não significa que estamos te ignorando; apenas significa que ainda não tivemos tempo de vê-lo ainda.
Quando e como eu devo lembrar o time de uma mudança que eu me preocupe?¶
Uma mensagem educada e no tempo certo à lista de emails é uma maneira de ter atenção. Para determinar a hora certa, você precisa ficar de olho no cronograma. Se você enviar uma mensagem logo antes de uma data final de publicação, você pode não ter a atenção desejada.
Lembretes no IRC também podem funcionar - vale lembrar, faça-os num momento estratégico, se possível. Durante um sprint para correção de bugs seria um ótimo momento, por exemplo.
Outra maneira de obter tração é fazer vários tickets relacionados juntos. Quando alguém se senta para rever um bug em uma área que eles não tocaram por um tempo, pode levar alguns minutos para lembrar todos os detalhes finos de como essa área de código funciona. Se você coletar várias pequenas correções de bugs juntos em um grupo com temas similares, você faz um alvo atraente, pois o custo de se atualizar em uma área de código pode ser distribuído em vários tickets.
Por favor, evite enviar e-mails para alguém pessoalmente ou repetidamente levantar o mesmo problema. Esse tipo de comportamento não atrairá nenhuma atenção adicional - certamente não a atenção de que você precisa para resolver seu problema
Mas eu lembrei vocês várias vezes e vocês continuam ignorando minha contribuição!¶
Sério, não estamos te ignorando. Se sua contribuição não se encaixar para inclusão no Django, fecharemos o tíquete. Para todos os outros tíquetes, precisamos priorizar esforços, o que significa que alguns tíquetes serão resolvidos antes de outros.
Um dos critérios que é usado para priorizar correções de um bug é o número de pessoas que provavelmente serão afetadas pelo bug informado. Bugs que tem potencial de afetar mais pessoas irão geralmente ter prioridade sobre os que são casos marginais.
Outra razão pela qual um bug pode ser ignorado por um tempo é se o bug for um sintoma de um problema maior. Embora possamos gastar tempo escrevendo, testando e aplicando muitos pequenos patches, às vezes a solução certa é reconstruir. Se uma reconstrução ou refatoração de um componente específico foi proposta ou está em andamento, você pode descobrir que os bugs que afetam esse componente não receberão tanta atenção. Novamente, trata-se de priorizar recursos escassos. Concentrando-nos na reconstrução, podemos fechar todos os pequenos bugs de uma só vez, e esperamos evitar que outros pequenos bugs apareçam no futuro.
Qualquer que seja o motivo, lembre-se que enquanto você pode estar sendo afetado por um bug específico com regularidade, não significa necessariamente que cada usuário de Django será afetado pelo mesmo bug. Diferentes usuários utilizam Django de diferentes formas, sobrecarregando partes diferentes do código em diferentes condições. Quando avaliamos as prioridades correspondentes, geralmente tentamos levar em conta as necessidades de toda a comunidade, não somente a gravidade para um usuário específico. Isso não significa que nós achamos que seu problema não é importante - somente que no tempo limitado que temos disponível, vamos sempre escolher fazer 10 pessoas felizes ao invés de 1 pessoa feliz.
Tenho certeza de que meu ticket está 100% perfeito, posso marcá-lo como “Pronto para check-in”?¶
Desculpe, não. É sempre melhor ter outro ponto de vista em um ticket. Se você estiver tendo problemas para obter esse segundo ponto de vista, veja as perguntas acima.
