¡Gracias por preguntar! Hemos redactado un documento entero para esta pregunta. Se titula Contribuyendo con Django.
¡No te preocupes: No te estamos ignorando!
Es importante entender que existe una diferencia entre “un reporte siendo ignorado” y “un reporte que no ha sido atendido aún”. El sistema de reportes de Django contiene cientos de reportes abiertos, de varios grados de impacto en la funcionalidad del usuario final, y 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 en dependencia de nuestro tiempo libre. Si estamos ocupado, es posible que no podamos emplear todo el tiempo en Django como quisiéramos.
La mejor forma de asegurarse que los reportes no quedan colgados en el camino a ser chequeados es resolviéndolo, incluso para algunos que podrían no estar familiarizados con esa área del código, para entender el problema y verificar el arreglo:
¿Existen instrucciones claras sobre cómo reproducir el error? Si esto toca alguna dependencia (como Pillow), un módulo de contribución o base de dato específica. ¿Son lo suficientemente claras esas instrucciones incluso para alguien no familiarizado con ello?
Si existen varios parches adjuntados al reporte, ¿Se tiene claro qué hace cada uno, cuáles pueden ser ignorados y cuál importa?
¿Incluye el parche las 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 arregla.
Si tu parche no tiene posibilidad de ser incluido en Django, no lo ignoraremos – simplemente cerraremos el reporte. Así que si tu reporte todavía permanece abierto, no significa que te estamos ignorando; es solo que no hemos tenido tiempo de mirarlo aún.
Un mensaje cortés y a tiempo a la lista de correos es una forma de ser atendido. Para determinar el momento adecuado necesitas vigilar calendario. Si publicas tu mensaje cuando los desarrolladores principales intentan resolver una funcionalidad con plazo o gestionar una fase planificada, no recibirás el tipo de atención requerida. Sin embargo, si centras la atención en un reporte cuando los desarrolladores principales prestan particular atención a los fallos – antes del sprint de arreglo de falllos, o en la preparación para una liberación beta, por ejemplo – probablemente tendrás una respuesta productiva.
Ligeros recordatorios por IRC también pueden funcionar – nuevamente, estatégicamente cronometrado si es posible. Durante un sprint de reparación de fallos sería un buen momento.
Otra forma de ganar terreno es agrupar varias incidencias relacionadas. Cuando los desarrolladores principales se sientan a corregir un error 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, usted lo hace un blanco atractivo, ya que el esfuerzo de proponer acelerar en un área de código se puede extender a diferentes incidencias.
Por favor, abstente de enviar correos personales a los desarrolladores principales, o exponer el mismo problema una y otra vez. Este tipo de comportamiento no te permitirá obtener algún tipo de atencióñ – ciertamente no la atención que necesitas para tu fallo.
En serio - no te estamos ignorando. Si tu parche no tiene la posibilidad de ser incluido en Django, cerraremos el reporte. Para todos los otros reportes, necesitamos priorizar nuestros esfuerzos, lo que significa que algunos reportes serán atendidos antes que otros.
Uno de los criterios usados para priorizar el arreglo de fallas es el número de personas que son afectadas por la misma. Las fallas que tienen el potencial de afectar a muchas personas, generalmente tienen mayor prioridad respecto a los casos esporádicos.
Otra razón por la que los fallos pueden ser ignorados por un tiempo es que este sea síntoma de un problema mayor. Mientras 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ás que los fallos que afectan a ese componente no tendrán mucha atención. Nuevamente, 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 fallos de una vez y afortunadamente prevenir la prevención de otros pequeños fallos en un 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 persona.
ago. 01, 2016