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.
¿Cuándo y cómo podría recordarle al equipo principal sobre un parche que me atañe?¶
Un mensaje cortés y a tiempo a la lista de correos es una forma de llamar la atención. Para determinar el momento adecuado, usted necesita estar pendiente del calendario. Si envía su mensaje cuando los desarrolladores principales están intentando resolver una funcionalidad con fecha de entrega o gestionar una fase de planificación, no recibirá el tipo de atención que requiere. Sin embargo, si centra la atención en un ticket cuando los desarrolladores principales están prestando particular atención a los bugs, justo antes del sprint de corrección de bugs o en la preparación para una versión beta, por ejemplo, probablemente tendrá una respuesta productiva.
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 ganar terreno es agrupar varios tickets relacionados. Cuando los desarrolladores principales se sientan a corregir un bug en un área con la que no han tenido contacto durante un tiempo, puede tomar unos minutos recordar todos los pequeños detalles de cómo funciona esa área de código. Si usted agrupa varias correcciones de errores menores en un grupo temático similar, lo hace un blanco atractivo, ya que el esfuerzo de proponer ponerse al día en un área de código se puede extender a diferentes tickets.
Por favor, absténgase de enviar correos personales a los desarrolladores principales o de exponer el mismo problema una y otra vez. Este tipo de comportamiento no le permitirá obtener especial atención, ciertamente no el tipo de atención que necesita para que su bug preferido sea atendido.
¡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 los bugs pueden ser ignorados por un tiempo es que sean síntomas de un problema mayor. Aunque podemos pasar tiempo escribiendo, probando y aplicando grandes cantidades de parches pequeños, algunas veces la solución correcta es reconstruir. Si la reconstrucción o refactorización de un componente en particular ha sido propuesta o está en marcha, notará que los errores que afectan a ese componente no recibirán mucha atención. De nuevo, esto es solo una cuestión de priorizar los escasos recursos con los que contamos. Al concentrarnos en la reconstrucción, podemos cerrar todos los pequeños errores de una vez y afortunadamente prevenir la aparición de otros pequeños errores en el futuro.
Cualquiera que sea la razón, por favor tenga en cuenta que aunque usted puede obtener un error en particular con regularidad, no significa necesariamente que cada usuario de Django obtendrá el mismo error. Los diferentes usuarios utilizan Django de diferentes maneras, dando prioridad a diferentes partes del código en diferentes condiciones. Cuando evaluamos las prioridades relativas, por lo general tratamos de tener en cuenta las necesidades de toda la comunidad, no sólo la gravedad para un usuario en particular. Esto no quiere decir que creemos que su problema no es importante, sólo que en el poco tiempo que tenemos disponible, siempre vamos a decantarnos por hacer felices a 10 personas en lugar de hacer feliz a 1.
