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.

Por otra parte, antes de informar de un error o solicitar una nueva funcionalidad, por favor tenga en cuenta estos aspectos generales:

• 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 utilice el sistema de tickets para realizar preguntas de soporte. Utilice la lista django-users o el canal #`django`_ IRC para eso.

• No reabra problemas que un desarrollador principal haya marcado como “wontfix”. Esta marca significa que se tomó la decisión de que un problema en particular no puede ser solucionado y por lo tanto no se invertirá más tiempo en el mismo. Si no está seguro del por qué, por favor pregunte en django-developers.

• No utilice el rastreador de tickets para discusiones largas porque son propensas a perderse. Si un ticket determinado es controvertido, por favor traslade la discusión a django-developers.

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.

• Primero pregunte en django-users or #django si no está seguro de que lo que ve es un bug.

• Escriba informes de errores específicos, completos y reproducibles. Debe incluir una descripción clara y concisa del problema y un conjunto de instrucciones para replicarlo. Añada toda la información de depuración posible: fragmentos de código, casos de pruebas, backtraces de excepción, capturas de pantalla, etc. Un caso de prueba pequeño y agradable es la mejor forma de informar un error, ya que nos proporciona una forma fácil de comprobar el error rápidamente.

• ** No** envíe mensajes a django-developers solo para anunciar que usted ha presentado un informe de error. Todos los tickets se envían a otra lista, django-updates, que es seguida por los desarrolladores y miembros de la comunidad interesados; los vemos como los 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 su reporte de tickets, que son el equivalente visual de un caso de prueba mínimo. Muestre el problema, no las extensas personalizaciones que ha realizado 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 usted presenta un parche que cambia la apariencia o el comportamiento de la interfaz de usuario de Django, usted debe adjuntar las capturas de pantalla y videos del antes y el después. Los reportes de tickets que carecen de estas son difíciles de evaluar de manera rápida por parte de los evaluadores y desarrolladores principales.

• 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 de que la funcionalidad en realidad requiere cambios en el núcleo de Django. Si su idea se puede desarrollar como una aplicación o módulo independiente, por ejemplo, usted desea soportar otro motor de base de datos, probablemente vamos a aconsejarle que lo desarrolle de forma independiente. Entonces, si el proyecto reúne suficiente apoyo de la comunidad, podemos considerarlo para su inclusión en Django.

• En primer lugar, solicite la funcionalidad en la lista django-developers, no en el rastreador de tickets. Sera leída con mayor atención si está en la lista de correo. Esto es aún más importante para las solicitudes de funcionalidades a gran escala. Nos gusta discutir sobre cualquier gran cambio en el núcleo de Django en la lista de correo antes de trabajar realmente en él.

• 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. En algunos casos esto es obvio, pero como Django está diseñado para ayudar a los desarrolladores reales a hacer trabajo real, tendrá que explicarlo, si no es obvio por qué la funcionalidad sería útil.

Si los desarrolladores principales están de acuerdo sobre la funcionalidad, entonces es pertinente crear un reporte de tickets. Incluya un enlace a la discusión realizada en django-developers en la descripción del ticket.

Al igual que con la mayoría de los proyectos de código abierto, el código habla. Si usted está dispuesto a escribir el código para la funcionalidad o, aún mejor, si ya lo ha escrito, es mucho más probable de que sea aceptado. Sólo haga un fork de Django en GitHub, cree una rama de la funcionalidad y ¡Muéstrenos su trabajo!

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

Cómo tomamos decisiones

Siempre que es posible, nos esforzamos para llegar a un consenso aproximado. Para ello, con frecuencia tendremos votaciones informales en django-developers acerca de una funcionalidad. En estas votaciones se sigue el estilo de votación inventado por Apache y utilizado en Python, donde los votos se emiten como +1, +0, -0 o -1. Traducidos libremente, 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 en django-developers son informales, se tomarán muy en serio. Después de un período de votación razonable, si se alcanza un consenso claro nos guiaremos por las votaciones.

Sin embargo, el consenso no siempre es posible. Si no se puede llegar a un consenso, o si el debate para lograr el consenso decae sin tomar una decisión concreta, cualquier: ref: miembro del equipo principal <core-team> puede remitir la decisión al :ref: Consejo Técnico <technical-board>.

El consejo técnico utilizará internamente el mismo mecanismo de votación. Una propuesta se considerará adoptada si:

• Hay al menos tres votos “+1” de miembros del consejo técnico.

• No hay votos “-1” de cualquier miembro del consejo técnico.

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

Ya que este proceso le permite a cualquier miembro del consejo técnico vetar una propuesta, un voto “-1” debería ser acompañado por una explicación de lo que haría falta para transformar ese “-1” en al menos un “+0”.

Las votaciones sobre cuestiones técnicas se deberían anunciar y llevar a cabo públicamente en la lista de correos django-developers.