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.

Outra razão desses bugs serem momentaneamente ignorados, é se um bug for um sintoma de um problema maior. Enquanto passamos um tempo escrevendo, testando e aplicando várias pequenas correções, algumas vezes a solução correta é reconstruir. Se reconstruir ou refatorar um dado componente foi proposta ou está em andamento, você pode achar que aqueles bugs que afetam aquele componente não receberam muita atenção. Novamente, isso é uma questão de priorização de recursos escassos. Por concentrar em reconstrução, podemos fechar todos os pequenos bugs de uma vez, e esperamos prevenir o aparecimento de outros pequenos bugs 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 dispomos, vamos sempre escolher fazer 10 pessoas felizes ao invés de 1 pessoa feliz.