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.

Envié una solución de un bug hace varias semanas. ¿Por qué están ignorando mi contribución?

¡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 hay varias ramas enlazadas al ticket, ¿se tiene claro que hace cada uno, cuáles pueden ser ignorados y cuales son importantes?

• ¿El cambio incluye pruebas unitarias? Si no, ¿existe una explicación clara de por qué no? Una prueba expresa de forma resumida cuál es el problema y muestra que la rama realmente lo corrige.

Si su contribución no es adecuada para incluirlo en Django, no la ignoraremos – cerraremos el ticket. Así que si su ticket aún esta abierto, no significa que lo estemos ignorando; es solo que no hemos tenido tiempo para revisarlo.

¿Cómo y cuándo debo recordarle al equipo de un cambio importante para mí?

Un mensaje respetuoso y oportuno en los foros/ramas es una forma de obtener atención. Para saber el momento oportuno, necesita estar pendiente del calendario. Si envía un mensaje poco antes de la fecha límite de lanzamiento, es poco probable que tenga 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 bug en un área que no ha tocado por un tiempo, puede tomar unos minutos recordar todos los detalles minuciosos de cómo funciona esa área de código. Si recopila varias soluciones de bugs menores relacionados a 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 múltiples 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 se los he recordado varias veces y siguen ignorando mi contribución!

De verdad - no le estamos ignorando. Si su contribución no es adecuada para incluirlo en Django, cerraremos el ticket. Para los demás tickets, necesitamos priorizar nuestro 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 bug se este ignorando por un tiempo es si el bug es un síntoma de un problema mayor. Aunque podríamos invertir tiempo escribiendo, probando y aplicando un montón de cambios pequeños, a veces la mejor solución es reconstruir. Si una reconstrucción o refactorización ha sido propuesto o esta en marcha, es posible que los bugs que afecten ese componente no reciban tanta atención. Una vez más, se trata de priorizar nuestros escasos recursos. Concentrándonos en la reconstrucción, podremos cerrar todos los pequeños bugs a la vez y con suerte evitar que aparezcan otros pequeños bugs 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 ticket es absolutamente 100% perfecto, ¿puedo marcarlo yo mismo como «Listo Para Revisión»?

Lo siento, pero no. Siempre es mejor tener una segunda opinión en un ticket. Si tiene problemas para obtener esa segunda opinión, consulte las preguntas anteriores.