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 devo lembrar a equipe principal sobre um reparo que me importo?¶
Uma mensagem bem educada e oportuna para a lista de e-mail é uma forma de conseguir atenção. Para determinar o momento adequado, você precisa ficar de olho na agenda. Se você postar uma mensagem enquanto os desenvolvedores principais estão tentando cumprir um prazo de entrega ou enquanto estão numa fase de planejamento você não vai conseguir a atenção de que precisa. Contudo, se você chamar atenção num tíquete quando os desenvolvedores principais estão prestando atenção especial aos bugs - um pouco antes do sprint para correção de bugs, ou na reta final de um release beta, por exemplo - você terá bem mais chances de conseguir uma resposta produtiva.
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 ter atenção é fazer o pull de vários tíquetes relacionados ao mesmo tempo. Quando os desenvolvedores do núcleo sentam para arrumar um bug em uma área que há algum tempo não vêem pode levar algum tempo para lembrarem de todos os pequenos detalhes de como aquele código funciona. Se você agrupar correções de vários pequenos bugs de um mesmo tema, você tornará mais atrativo, já que o custo se dividirá em múltiplos tíquetes com o ganho de velocidade em uma área do código.
Por favor abstenha-se enviar e-mails aos desenvolvedores do núcleo pessoalmente, ou repetidamente apontar o mesmo problema várias vezes. Este tipo de comportamento não lhe dará qualquer atenção adicional – certamente não a atenção que você precisa para endereçar seu “pet bug”
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.
