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.

Another way to get traction is to pull several related tickets together. When the someone sits down to review a bug in an area they haven’t touched for a while, it can take a few minutes to remember all the fine details of how that area of code works. If you collect several minor bug fixes together into a similarly themed group, you make an attractive target, as the cost of coming up to speed on an area of code can be spread over multiple 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 para um bug ser momentaneamente ignorado é se ele for um sintoma de um problema maior. Enquanto gastamos tempo escrevendo, testando e aplicando várias pequenas correções, às vezes a solução correta é a reconstrução. Se a reconstrução ou refatoração de um componente em particular foi proposta ou está em andamento, você pode achar que os bugs afetando tal componente não estejam tendo atenção. Novamente, isso é somente uma questão de priorização de recursos escassos. Nos concentrando na reconstrução podemos corrigir todos os bugs de uma vez, e esperamos prevenir outros pequenos bugs de aparecerem 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.