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 a buen tiempo a la lista de correo, es una manera de obtener atención. Para determinar el momento correcto, necesita estar pendiente del calendario. Si coloca su mensaje justo después de una fecha límite de lanzamiento, posiblemente no tendrá la atención que requiere.

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 forma de obtener tracción es juntar varios tickets relacionados. Cuando alguien se sienta a revisar un error en un área que no ha tocado por un tiempo, puede tomar unos minutos recordar todos los detalles finos de cómo funciona esa área de código. Si recopila varias correcciones de errores menores juntas en un grupo temático similar, se convierte en un objetivo atractivo, ya que el costo de ponerse al día en un área de código se puede distribuir en varios tickets.

Por favor, absténgase de enviar correos electrónicos a cualquier persona de manera personalmente o de plantear el mismo problema una y otra vez. Este tipo de comportamiento no le ganará ninguna atención adicional – ciertamente no la atención que necesita para que se aborde su problema.

¡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.

Otra razón por la que un error puede ignorarse por un tiempo es si el error es un síntoma de un problema mayor. Si bien podemos dedicar tiempo a escribir, probar y aplicar muchos pequeños parches, a veces la solución correcta es reconstruir. Si se ha propuesto o está en proceso una reconstrucción o refactorización de un componente en particular, es posible que los errores que afecten a ese componente no reciban tanta atención. Nuevamente, se trata de priorizar los recursos escasos. Concentrándonos en la reconstrucción, podemos cerrar todos los pequeños errores a la vez y, con suerte, evitar que aparezcan otros pequeños errores en el futuro.

Cualquiera sea la razón, tenga en cuenta que, si bien puede encontrar un error en particular con regularidad, no necesariamente todos los usuarios de Django podrían tener el mismo error. Diferentes usuarios usan Django de diferentes maneras, enfatizando diferentes partes del código bajo diferentes condiciones. Cuando evaluamos las prioridades relativas, generalmente tratamos de considerar las necesidades de toda la comunidad, en lugar de priorizar el impacto en un usuario en particular. Esto no significa que pensemos que su problema no es importante, solo que en el tiempo limitado que tenemos disponible, siempre nos equivocaremos al hacer felices a 10 personas en lugar de hacer feliz a una sola persona.

Estoy seguro de que mi boleto es absolutamente 100% perfecto, ¿puedo marcarlo como «Listo para el checkin» yo mismo?

Lo siento, no. Siempre es mejor tener otro conjunto de ojos en un ticket. Si tiene problemas para obtener ese segundo conjunto de ojos, consulte las preguntas anteriores.