Obrigado por perguntar! Escrevemos um documento inteiro dedicado a essa questão chamado Contribuindo com o Django.
Não se preocupe, não estamos te ignorando!
É importante entender que há uma diferença entre “um ticket está sendo ignorado” e “um ticket que ainda não foi atendido”. O sistema de tickets do Django contém centenas de tickets abertos, de vários graus de impacto na funcionalidade oferecida aos usuários e os desenvolvedores do Django têm de revisá-los e priorizá-los.
Além disso, as pessoas que trabalham com o Django são voluntárias. Como resultado, a quantidade de tempo que temos para trabalhar no framework é limitada e irá variar semanalmente, de acordo com nosso tempo livre. Se estivermos ocupados, não poderemos gastar tanto tempo no Django como gostaríamos.
A melhor maneira de fazer com que seu ticket chegue ao “checkin” é encurtando seu caminho, mesmo para aqueles que podem não estar intimamente familiarizado com a área de código em questão poder entender o problema e verificar a solução:
Se seu patch não teve chance de inclusão no Django, nós não o ignoramos – somente iremos fechar o ticket. Então se seu ticket ainda estiver aberto, não significa que nós estamos ignorando você; somente quer dizer que nós não tivemos tempo de olhá-lo ainda.
Educadamente, uma mensagem, no momento certo, para a lista de desenvolvimento é um bom caminho para receber atenção. Para determinar o tempo certo, você precisa se manter atento com a agenda. Se você postar sua mensagem quando os desenvolvedores principais estiverem tentando não estourar o prazo de uma funcionalidade, ou em fase de planejamento, você não terá toda a atenção que deseja. Entretanto, se você chamar a atenção com um ticket quando os desenvolvedores principais estão com as atenções voltadas para correção de bugs – bem na véspera de um sprint de correção de bugs, ou perto de um lançamento de uma versão beta, por exemplo – você terá muito mais chance de receber uma resposta produtiva.
Lembretes gentis no IRC também podem funcionar – novamente, num momento estratégico se possível. Durante um sprint de correções de bugs pode ser uma boa hora, por exemplo.
Outra forma de obter atenção é reunir vários tickets relacionados. Quando os desenvolvedores principais sentam para resolver um bug em uma certa área que eles não tenham tocado a algum tempo, eles podem demorar um pouco para relembrar todos os belos detalhes do funcionamento dessa área do código. Se você reúne várias pequenas correções de bug de um certo grupo, você cria um alvo atrativo, como um custo único que pode ser aproveitado por vários tickets.
Por favor, contenha-se em enviar e-mail para um desenvolvedor do core team pessoalmente, ou repetidamente levantar o mesmo problema, insistentemente. Este tipo de comportamento não atrairá nenhuma atenção adicional – certamente não a atenção que você deseja para o seu bug de estimação.
Sério - nós não ignoramos você. Se seu patch não recebe a chance de ser incluído no Django, nós fechamos o ticket. Nós precisamos priorizar nossos esforços para todos os outros tickets, o que significa que alguns tickets serão atendidos antes de outros.
Um dos critérios que é usado para priorizar um bug é o número de pessoas que serão atingidas por ele. Bugs que possuem potencial para afetar muita gente, geralmente terão prioridade em relação aos outros.
Uma outra razão para que bugs possam ser ignorados por um momento é se o bug é um sintoma de um problema maior. Embora nós podemos gastar tempo escrevendo, testando e aplicando um monte de patches, algumas vezes a solução certa é refazer. Se uma reconstrução ou refatoração de um componente em particular foi proposto ou está a caminho, você pode encontrar bugs que afetam o componente, mas eles não terão muita atenção. Novamente, isto é só uma questão de priorizar recursos escassos. Concentrando na refatoração, nós poderemos fechar todos estes pequenos bugs de uma vez, e esperançosamente previnir que outros pequenos bugs apareçam no futuro.
Seja qual for o motivo, por favor, mantenha em mente que enquanto você pode se incomodar com um bug regularmente, não significa que todos os usuários do Django tenham o mesmo problema. Diferentes usuários utilizam o Django de diferentes formas, estressando partes diferentes de código em diferentes condições. Quando nós avaliamos as prioridades relativas, nós geralmente tentamos considerar as necessidades de toda comunidade, não somente a gravidade de um determinado usuário. Isto não significa que pensamos que seu problema é insignificante – somente que em um limitado espaço de tempo que temos disponível, nós sempre iremos preferir fazer 10 pessoas felizes ao invés de uma só.
Dec 26, 2011