Importante
Por favor, informe problemas de seguridad solo a security@djangoproject.com. Se trata de una lista privada solo accesible para desarrolladores Django experimentados y confiables durante mucho tiempo, y sus archivos no son públicos. Para obtener más detalles, por favor vea nuestras políticas de seguridad.
Antes de informar un bug en el rastreador de tickets considere estos puntos:
Check que alguien no ha presentado ya el informe de bug mediante searching o ejecutando custom queries en el seguimiento de tickets.
No utilices el sistema de tickets para hacer preguntas de soporte. Utiliza el Fórum Django o el servidor Discord de Django para eso.
No reabran los problemas que han sido marcados como «wontfix» sin encontrar un consenso para hacerlo en el Fórum Django.
No utilices el seguimiento de tickets para discusiones largas, ya que es probable que se pierdan. Si un ticket particular es controvertido, por favor mueve la discusión al Fórum Django.
Los informes de bug bien escritos son incrediblemente útiles. Sin embargo, hay una cierta cantidad de sobrecarga involucrada en trabajar con cualquier sistema de seguimiento de bugs, por lo que su ayuda para mantener nuestro seguimiento de tickets tan útil como sea posible se aprecia. En particular:
Hazlo: lee el FAQ para ver si tu problema podría ser una pregunta bien conocida.
Hazlo: pide en Fórum Django o el `servidor Discord de Django`_* primero* si no estás seguro de si lo que ves es un bug.
Hazlo: escribe informes de bugs completos, reproducibles y específicos. Debes incluir una descripción clara y concisa del problema, y un conjunto de instrucciones para replicarlo. Añade la mayor cantidad posible de información de depuración: fragmentos de código, casos de prueba, trazas de excepciones, capturas de pantalla, etc. Un pequeño caso de prueba es la mejor manera de informar un bug, ya que nos da una forma útil para confirmar el bug rápidamente.
No hagas: publica en `Fórum Django`_* solo* para anunciar que has presentado un informe de bug. Todos los tickets se envían a otra lista, django-updates, la cual es seguida por desarrolladores e interesados miembros de la comunidad; los vemos al momento de ser presentados.
Para entender el ciclo de vida de tu ticket una vez que lo hayas creado, consulta Triage de tickets.
Si tu bug afecta algo visual en naturaleza, hay unas pocas directrices adicionales que debes seguir:
Incluye capturas de pantalla en tu ticket que sean la equivalente visual de un caso de prueba mínimo. Muestra el problema, no las personalizaciones locas que has hecho a tu navegador.
Si el problema es difícil de mostrar utilizando una imagen estática, considera capturar un breve screencast. Si tu software lo permite, captura solo la zona relevante de la pantalla.
Si estás ofreciendo una parche que cambia la apariencia o comportamiento de la interfaz de usuario de Django, debes adjuntar capturas de pantalla/screencasts antes y después. Los tickets faltantes son difíciles para los triadores de evaluar rápidamente.
Las capturas de pantalla no te eximen de otras buenas prácticas de informe. Asegúrate de incluir URLs, fragmentos de código y instrucciones paso a paso sobre cómo reproducir el comportamiento visible en las capturas de pantalla.
Asegúrate de establecer la bandera UI/UX en el ticket para que los interesados puedan encontrar tu ticket.
Si el problema se relaciona con accesibilidad, por favor vincula a la normativa relevante accessibility standard si corresponde.
Estamos siempre tratando de hacer que Django sea mejor, y tus solicitudes de características son una parte clave de eso. Aquí hay algunas pautas sobre cómo hacer una solicitud de manera más efectiva:
Evaluate si la idea de característica requiere cambios en el núcleo de Django. Si tu idea puede desarrollarse como una aplicación o módulo independiente — por ejemplo, quieres soportar otro motor de base de datos — probablemente sugeriremos que lo desarrolles de manera independiente. Luego, si tu proyecto recopila suficiente apoyo de la comunidad, podemos considerarlo para su inclusión en Django.
Propón la característica en el proyecto new feature ideas de GitHub (no en el rastreador de tickets) creando un nuevo elemento en la columna Idea. Este es donde la comunidad y el Consejo Directivo evalúan nuevas ideas para el ecosistema Django. Este paso es especialmente importante para propuestas grandes o complejas. Preferimos discutir cualquier cambio significativo al núcleo de Django antes de que comience cualquier desarrollo. En algunos casos, una característica puede ser más adecuada como un paquete de terceros, donde puede evolucionar independientemente del ciclo de lanzamiento de Django.
Describe claramente y concisamente qué característica falta y cómo te gustaría verla implementada. Incluye código de ejemplo (no funcional es OK) si es posible.
Explica por qué quieres la característica. Explicar un caso de uso mínimo ayudará a los demás a entender dónde encaja, y si ya hay otras formas de lograr lo mismo.
Ver también: Documentación de nuevas características.
Los informes de una regresión del rendimiento o sugerencias de optimizaciones de rendimiento deben proporcionar benchmark y comandos para que el rastreador de tickets pueda reproducirlos.
Ver los Benchmarks de django-asv para más detalles sobre los benchmarks existentes de Django.
Cuando sea posible, nos esforzamos por alcanzar un consenso aproximado. Las reacciones con emojis se utilizan en las issues dentro del proyecto new feature ideas de GitHub para rastrear la retroalimentación de la comunidad. Los siguientes significados se asignan a cada reacción:
¡Claro! Aquí tienes las traducciones de los textos originales:
Me opongo a esta característica o creo que causaría problemas para mí o Django.
No tengo una opinión fuerte sobre esta característica.
Esta característica parece ser una adición directa y beneficiosa.
El Consejo de Dirección revisará regularmente las ideas en el proyecto, moviendo aquellas con apoyo de la comunidad a través de los siguientes estadios:
Idea
Aprobado - Refinamiento de la idea - Creación del equipo
En progreso
Solución en funcionamiento - Revisión - Retroalimentación
Necesita mantenimiento (solo Django)
He aquí las traducciones de los textos originales:
A veces, se pueden desarrollar discusiones sobre ideas de características o la dirección de Django en el Foro de Django. Estas discusiones pueden incluir votaciones informales, que siguen el estilo de votación inventado por Apache y utilizado en sí mismo en Python, donde los votos se dan como +1, +0, -0 o -1. Traducidos aproximadamente, estos votos significan:
+1: «Me encanta la idea y estoy fuertemente comprometido con ella.»
+0: «Suena bien a mí.»
-0: «No me entusiasma, pero no me opondré en el camino.»
-1: «Me opongo firmemente y estaría muy descontento de ver que la idea se convierta en realidad.»
Aunque estos votos son informales, se tomarán muy en serio. Después de un período de votación adecuado, si surge una clara consenso, seguiremos los votos.
may 31, 2026