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.

Há semanas atrás eu submeti uma correção para um bug no sistema de tíquetes. Por que vocês estão ignorando a minha correçã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 existirem diversos reparos anexados ao tíquete… Está claro o que cada um faz? Quais podem ser ignorados e quais importam?
  • O reparo inclui um teste unitário? Em caso negativo, existe uma explicação bem clara sobre o motivo? Um teste expressa do que se trata o problema de forma sucinta e demonstra que o reparo realmente o corrige.

Se sua sugestão não tiver nenhuma possibilidade de inclusão no Django, não vamos ignorá-la - Vamos apenas fechar o tíquete. Portanto, se o seu tíquete ainda está aberto, isso não significa que estamos te ignorando; significa apenas que não tivemos tempo de verificar ele ainda.

Quando e como posso lembrar ao time sobre um “patch” que me interessa?

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 pessoais a qualquer um ou repetidamente sobre a mesma “issue”. Este tipo de comportamento não irá lhe dar nenhum tipo de atenção adicional – e certamente não a atenção que você precisa para ter seu problema encaminhado.

Mas eu os lembrei diversas vezes e vocês continuam ignorando meu patch!

Sério, não estamos lhe ignorando. Se o seu “reparo” não tem chance de 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 encaminhados 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.

Another reason that bugs might be ignored for while is if the bug is a symptom of a larger problem. While we can spend time writing, testing and applying lots of little patches, sometimes the right solution is to rebuild. If a rebuild or refactor of a particular component has been proposed or is underway, you may find that bugs affecting that component will not get as much attention. Again, this is a matter of prioritizing scarce resources. By concentrating on the rebuild, we can close all the little bugs at once, and hopefully prevent other little bugs from appearing in the future.

Whatever the reason, please keep in mind that while you may hit a particular bug regularly, it doesn’t necessarily follow that every single Django user will hit the same bug. Different users use Django in different ways, stressing different parts of the code under different conditions. When we evaluate the relative priorities, we are generally trying to consider the needs of the entire community, instead of prioritizing the impact on one particular user. This doesn’t mean that we think your problem is unimportant – just that in the limited time we have available, we will always err on the side of making 10 people happy rather than making a single person happy.

Back to Top