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.
I submitted a bug fix several weeks ago. Why are you ignoring my contribution?¶
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?
- If there are several branches linked to the ticket, is it clear what each one does, which ones can be ignored and which matter?
- Does the change include a unit test? If not, is there a very clear explanation why not? A test expresses succinctly what the problem is, and shows that the branch actually fixes it.
If your contribution is not suitable for inclusion in Django, we won’t ignore it – we’ll close the ticket. So if your ticket is still open, it doesn’t mean we’re ignoring you; it just means we haven’t had time to look at it yet.
When and how might I remind the team of a change I care about?¶
A polite, well-timed message in the forum/branch is one way to get attention. To determine the right time, you need to keep an eye on the schedule. If you post your message right before a release deadline, you’re not likely to get the sort of attention you require.
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 para alguém pessoalmente ou repetidamente levantar o mesmo problema. Esse tipo de comportamento não atrairá nenhuma atenção adicional - certamente não a atenção de que você precisa para resolver seu problema
But I’ve reminded you several times and you keep ignoring my contribution!¶
Seriously - we’re not ignoring you. If your contribution is not suitable for inclusion in Django, we will close the ticket. For all the other tickets, we need to prioritize our efforts, which means that some tickets will be addressed before others.
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 a bug might be ignored for a while is if the bug is a symptom of a larger problem. While we can spend time writing, testing and applying lots of little changes, 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.
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.
Tenho certeza de que meu ticket está 100% perfeito, posso marcá-lo como “Pronto para check-in”?¶
Desculpe, não. É sempre melhor ter outro ponto de vista em um ticket. Se você estiver tendo problemas para obter esse segundo ponto de vista, veja as perguntas acima.
