FAQ: Aportando código

¿Cómo puedo empezar a aportar código para Django?

¡Gracias por preguntar! Hemos redactado un documento entero para esta pregunta. Se titula Contribuyendo con Django.

Presenté un parche en el sistema de tickets hace varias semanas. ¿Por qué lo ignoran?

¡No se preocupe: No lo estamos ignorando!

Es importante entender que existe una diferencia entre «un ticket siendo ignorado» y «un ticket que aún no ha sido atendido». El sistema de tickets de Django contiene cientos de tickets abiertos, de diferentes grados de impacto en la funcionalidad del usuario final y que los desarrolladores de Django necesitan revisar y priorizar.

Además de eso: las personas que trabajan en Django son todos voluntarios. Como resultado, el tiempo que tenemos para trabajar en el framework es limitado y variará de semana en semana dependiendo de nuestro tiempo libre. Si estamos ocupado, es posible que no podamos emplear tanto tiempo en Django como quisiéramos.

La mejor forma de asegurarse de que los tickets no se queden en el camino a ser revisados es que sea muy fácil tanto entender el problema como comprobar el parche, incluso para alguien que puede no estar familiarizado con esa área del código:

• ¿Existen instrucciones claras sobre cómo reproducir el bug? Si esto afecta alguna dependencia (como Pillow), un módulo de contribución o una base de datos específica ¿son lo suficientemente claras esas instrucciones incluso para alguien que no está familiarizado con ello?
• Si existen varios parches adjuntados al ticket, ¿se tiene claro qué hace cada uno, cuáles pueden ser ignorados y cuáles son importantes?
• ¿El parche contiene pruebas unitarias? Si no ¿existe una muy clara explicación de por qué no? Una prueba expresa de forma resumida cuál es el problema y muestra que el parche realmente lo corrige.

Si su parche no tiene posibilidad de ser incluido en Django, no lo ignoraremos, simplemente cerraremos el ticket. Así que si su ticket todavía permanece abierto, no significa que lo estamos ignorando; es solo que no hemos tenido tiempo aún de revisarlo.

¿Cómo y cuando debo recordarle al equipo sobre un parche que me importa?

Un mensaje cortés y en buen tiempo a la lista de correo es una manera de obtener atención. Para determinar el momento correcto, tu necesitas estar pendiente del calendario. Si colocas tu mensaje justo después de una fecha límite de lanzamiento, posiblemente no vas a tener la atención que requieres

Los recordatorios gentiles por IRC también pueden funcionar, de nuevo, estratégicamente cronometrado si es posible. Por ejemplo, durante un sprint de corrección de errores sería un buen momento.

Otra manera de obtener tracción es colocar muchos tickets relacionados juntos. Cuando alguien se siente a revisar un bug en un área que no ha tocado por un tiempo, puede tomarle varios minutos recordar todos los detalles de como esa área de código funciona. Si recolectas muchos errores pequeños juntos relacionados en un mismo grupo, los conviertes en un objetivo atractivo, así el costo de revisar un área de código se puede propagar sobre varios tickets.

Por favor abstenerse de enviar correos a cualquiera personal o repetidamente, levantando la misma problemática una y otra vez. Este tipo de comportamiento no hará que gane más atención. Definitivamente no la atención que necesitas en orden de que su problemática sea resuelta

¡Pero les he recordado varias veces y siguen ignorando mi parche!

En serio, no lo estamos ignorando. Si su parche no tiene la posibilidad de ser incluido en Django, cerraremos el ticket. Para todos los otros tickets, necesitamos priorizar nuestros esfuerzos lo que significa que algunos tickets serán atendidos antes que otros.

Uno de los criterios usados para priorizar la corrección de errores es el número de personas que son afectadas por un determinado bug. Los bugs que tienen el potencial de afectar a muchas personas generalmente tienen mayor prioridad respecto a los casos extremos.

Another reason that bugs might be ignored for while is if the bug is a symptom of a larger problem. While we can spend time writing, testing and applying lots of little patches, 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.

Whatever the reason, please keep in mind that while you may hit a particular bug regularly, it doesn’t necessarily follow that every single Django user will hit the same bug. Different users use Django in different ways, stressing different parts of the code under different conditions. When we evaluate the relative priorities, we are generally trying to consider the needs of the entire community, instead of prioritizing the impact on one particular user. This doesn’t mean that we think your problem is unimportant – just that in the limited time we have available, we will always err on the side of making 10 people happy rather than making a single person happy.