Cómo informar de errores y solicitar funcionalidades

Importante

Por favor, informe los problemas de seguridad solo a [e-mail]. Esta es una lista privada solo disponible para desarrolladores de Django altamente confiables y de conocida trayectoria, y sus archivos no son de dominio público. Para más información, por favor consulte nuestra política de seguridad.

En cualquier otro caso, antes de informar sobre un error o solicitar una nueva funcionalidad en el rastreador de tickets, considere estos puntos:

• Compruebe que alguien no haya presentado todavía el error o la solicitud de la funcionalidad mediante la búsqueda o ejecución de peticiones personalizadas en el rastreador de tickets.

• No utilices el sistema de tickets para hacer preguntas de soporte. Utiliza el Django Forum o el Django Discord server para ello.

• No reabras temas que hayan sido marcados como «wontfix» sin encontrar consenso para hacerlo en el Foro Django.

• No utilices el rastreador de tickets para discusiones largas, porque es probable que se pierdan. Si un ticket en particular es controvertido, por favor mueve la discusión al Foro de Django.

Informe de errores

Los informes de errores bien escritos son muy útiles. Sin embargo, hay una cierta cantidad de sobrecarga involucrada en trabajar con cualquier sistema de seguimiento de errores, de modo que su ayuda para mantener nuestro rastreador de tickets tan útil como sea posible es apreciada. En particular:

• Lea las FAQ para ver si su problema puede ser una pregunta frecuente.

• Pregunta en el Django Forum o en el Django Discord server primero si no estás seguro de si lo que ves es un bug.

• Escriba informes de errores completos, reproducibles y específicos. Debe incluir una descripción clara y concisa del problema, y una serie de instrucciones para replicarlo. Añada tanta información de depuración que pueda: fragmentos de código, casos de prueba, trazas de excepciones, capturas de pantalla, etc. Un buen y pequeño caso de prueba es la mejor manera de informar de un error, ya que nos ofrece una manera provechosa de confirmar el error rápidamente.

• **No publiques en Django Forum sólo para anunciar que has enviado un informe de error. Todos los tickets se envían a otra lista, django-updates, que es rastreada por desarrolladores y miembros interesados de la comunidad; los vemos a medida que se presentan.

Para entender el ciclo de vida de su ticket una vez que lo ha creado, consulte: doc: Priorización de tickets.

Reporte de fallos de interfaz de usuario y funcionalidades

Si su informe de error o solicitud de funcionalidad se refiere a algo de caracter visual, hay algunas pautas adicionales a seguir:

• Incluya capturas de pantalla en tus tickets, son el equivalente visual de un mínimo caso de uso. Destaque el problema, no las impresionantes personalizaciones que le ha aplicado a su navegador.

• Si el problema es difícil de mostrar utilizando una imagen fija, considere la captura de un video de tipo screencast de corta duración. Si el software lo permite, capture sólo el área correspondiente de la pantalla.

• Si ha proporcionado un parche que cambia la apariencia o el comportamiento de la UI de Django, debe adjuntar capturas de pantalla o grabaciones del antes y el después. Los tickets que no las incluyen son difíciles de valorar por aquellos que intervienen.

• Las capturas de pantalla no lo eximen de utilizar otras buenas prácticas de presentación de informes. Asegúrese de incluir direcciones URL, fragmentos de código e instrucciones paso a paso sobre cómo reproducir el comportamiento que se observa en las capturas de pantalla.

• Asegúrese de fijar el marcador de UI / UX en el reporte de tickets de manera que los interesados ​​puedan encontrar su reporte.

Solicitando funcionalidades

Siempre estamos tratando de mejorar Django, y sus solicitudes de funcionalidades son una parte de crucial importancia para ello. Estos son algunos consejos sobre cómo hacer una solicitud de forma más eficaz:

• Asegúrese que la funcionalidad realmente necesita cambiar en el núcleo de Django. Si su idea puede ser desarrollada como una aplicación o módulo independiente — por ejemplo, quiere dar soporte a otro gestor de base de datos — probablemente sugeriremos que lo desarrolle independientemente. Entonces, si su proyecto obtiene el suficiente apoyo de la comunidad, tal vez consideremos su inclusión en Django.

• Primero solicita la funcionalidad en el Django Forum, no en el ticket tracker. Se leerá con más atención y llegará a un público más amplio. Esto es aún más importante para las solicitudes de características a gran escala. Nos gusta discutir los grandes cambios en el núcleo de Django antes de trabajar en ellos.

• Describa de forma clara y concisa cuál es la funcionalidad que falta y cómo le gustaría que fuera implementada. Incluya ejemplo de código (si es no funcional está bien) si es posible.

• Explique por qué le gustaría la funcionalidad. Explicar un mínimo caso de uso ayudará al resto comprender dónde se debe incluir, y si ya hay otras maneras de realizar lo mismo.

Si se llega a un consenso sobre la funcionalidad, entonces es apropiado crear un ticket. Incluya un enlace a la discusión en la descripción del ticket.

Como en la mayor parte de los proyectos de código abierto, el código importa. Si estás dispuesto a escribir el código para la funcionalidad por ti mismo o, incluso mejor, si ya lo has escrito, es mucho más probable que sea aceptado. ¡Crea una copia de Django (fork) en GitHub, crea una rama específica para la funcionalidad y muéstranos tu trabajo!

Consulte también: :ref: documentando nuevas funcionalidades.

Solicitar optimizaciones de rendimiento

Los informes de una regresión de rendimiento, o las optimizaciones de rendimiento sugeridas, deben proporcionar puntos de referencia y comandos para que el triager del ticket los reproduzca.

Consulta la django-asv benchmarks para más detalles de los benchmarks existentes de Django.

Cómo tomamos decisiones

Siempre que sea posible, nos esforzamos por alcanzar un consenso aproximado. Para ello, a menudo hacemos votaciones informales en el Foro Django sobre una característica. En estas votaciones seguimos el estilo de votación inventado por Apache y utilizado en el propio Python, donde los votos se dan como +1, +0, -0, o -1. Traducido a grandes rasgos, estos votos significan:

• +1: «Me encanta la idea y estoy firmemente comprometido con ella.»

• +0: «Me parece bien.»

• -0: «No me gusta, pero no me interpondré en el camino.»

• -1: «Estoy totalmente en desacuerdo y estaría muy descontento de ver que la idea se haga realidad.»

Aunque estas votaciones son informales, se tomarán muy en serio. Tras un periodo de votación adecuado, si surge un consenso evidente seguiremos las votaciones.

Sin embargo, el consenso no siempre es posible. Si no es posible alcanzarlo, o si el debate para llegar a un consenso se desvanece sin llegar a una decisión concreta, la decisión puede aplazarse al consejo de dirección.

Internamente, el Consejo Director utilizará el mismo mecanismo de votación. Una propuesta se considerará aprobada si

• Hay al menos tres votos «+1» de miembros del Consejo de Dirección.

• No hay voto «-1» de ningún miembro del Consejo de Dirección.

Los votos deberían ser presentados dentro de una semana.

Dado que este proceso permite a cualquier miembro del Consejo Director vetar una propuesta, un voto de «-1» debería ir acompañado de una explicación de lo que haría falta para convertir ese «-1» en al menos un «+0».

Las votaciones sobre cuestiones técnicas deben anunciarse y celebrarse en público en el Foro Django.