¡Gracias por preguntar! Hemos escrito un documento completo dedicado a esta pregunta. Se titula Colaborando con Django.
No te preocupes: ¡no estamos ignorándote!
Es importante comprender que hay una diferencia entre «un ticket se está ignorando» y «un ticket aún no ha sido atendido». El sistema de tickets de Django contiene cientos de tickets abiertos, con diversos grados de impacto en la funcionalidad del usuario final, y los desarrolladores de Django deben revisarlos y priorizar.
En lo que respecta a eso: las personas que trabajan en Django son todas voluntarias. Como resultado, la cantidad de tiempo que tenemos para trabajar en el marco es limitada y variará de semana en semana dependiendo de nuestro tiempo libre. Si estamos ocupados, puede que no podamos dedicar tanto tiempo a Django como podríamos desear.
La mejor forma de asegurarse de que los tickets no se queden atascados en el camino al check-in es hacerlo lo más fácil posible, incluso para alguien que no esté muy familiarizado con esa área del código, entender el problema y verificar la solución:
¿Hay instrucciones claras sobre cómo reproducir el error? Si esto afecta una dependencia (como Pillow), un módulo de contribución o una base de datos específica, ¿las instrucciones son lo suficientemente claras incluso para alguien que no está familiarizado con ella?
Si hay varias ramas vinculadas al ticket, ¿es claro qué hace cada una, cuáles pueden ignorarse y cuáles importan?
¿La modificación incluye una prueba de unidad? Si no, ¿hay una explicación muy clara sobre por qué no? Una prueba expresa concisamente qué problema hay y muestra que la rama resuelve efectivamente el problema.
Si tu contribución no es adecuada para su inclusión en Django, no la ignoraremos – la cerraremos. Por lo tanto, si tu ticket sigue abierto, no significa que te estemos ignorando; solo significa que aún no hemos tenido tiempo de revisarlo.
Un mensaje educado y bien tiempo en el foro/rama es una forma de obtener atención. Para determinar el momento adecuado, debes mantener un ojo en la programación. Si publicas tu mensaje justo antes del plazo de entrega de una versión, no es probable que obtengas la clase de atención que necesitas.
Recordatorios suaves en el canal #contribuyendo-getting-started del servidor de Discord Django.
Otra forma de obtener tracción es reunir varios tickets relacionados. Cuando alguien se sienta a revisar un bug en una área que no ha tocado durante un tiempo, puede llevar unos minutos recordar todos los detalles finos sobre cómo funciona esa zona del código. Si recopilas varias correcciones de bugs menores en un grupo con un tema similar, creas un objetivo atractivo, ya que el costo de ponerse al día en una área de código se puede distribuir entre varios tickets.
Por favor, abstente de enviar correos electrónicos a personas individuales o de repetir el mismo problema una y otra vez. Este tipo de comportamiento no te otorgará ninguna atención adicional —ciertamente no la que necesitas para que se aborde tu problema.
En serio - no estamos ignorándote. Si tu contribución no es adecuada para incluirse en Django, cerraremos el ticket. Para todos los demás tickets, necesitamos priorizar nuestros esfuerzos, lo que significa que algunos tickets se abordarán antes que otros.
Uno de los criterios que se utiliza para priorizar las correcciones de errores es el número de personas que probablemente serán afectadas por un error determinado. Los errores que tienen el potencial de afectar a muchas personas suelen tener prioridad sobre aquellos que son casos de borde.
Otra razón por la que un bug puede ser ignorado durante un tiempo es si el bug es síntoma de un problema más grande. Si bien podemos dedicar tiempo a escribir, probar y aplicar muchos pequeños cambios, a veces la solución correcta es reconstruir. Si se ha propuesto o está en curso una reconstrucción o refactorización de un componente particular, puede encontrar que los bugs que afectan ese componente no recibirán tanta atención. De nuevo, se trata de priorizar recursos escasos. Al concentrarnos en la reconstrucción, podemos cerrar todos los pequeños bugs al mismo tiempo y, con suerte, prevenir otros pequeños bugs de aparecer en el futuro.
Independientemente de la razón, ten en cuenta que aunque puedas encontrar un problema específico con frecuencia, no necesariamente significa que todos los usuarios de Django lo encuentren igualmente. Los usuarios diferentes utilizan Django de maneras diferentes, poniendo a prueba diferentes partes del código bajo condiciones diferentes. Cuando evaluamos las prioridades relativas, estamos tratando generalmente de considerar las necesidades de la comunidad en su conjunto, en lugar de priorizar el impacto en un usuario particular. Esto no significa que pensamos que tu problema es insignificante – solo que en el tiempo limitado que tenemos disponible, siempre erraremos del lado de hacer felices a 10 personas en lugar de hacer feliz a una sola persona.
Lo siento, no. Siempre es mejor obtener otra mirada en un ticket. Si tienes problemas para obtener esa segunda mirada, consulta las preguntas anteriores.
may 31, 2026