Otherwise, before reporting a bug or requesting a new feature on the\nticket tracker, consider these points:
\nCompruebe 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.
Don’t reopen issues that have been marked «wontfix» without finding consensus\nto do so on 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.
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:
\nLea 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.
\nSi su informe de error o solicitud de funcionalidad se refiere a algo de caracter visual, hay algunas pautas adicionales a seguir:
\nIncluya 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.
If you’re offering a patch which changes the look or behavior of Django’s\nUI, you must attach before and after screenshots/screencasts.\nTickets lacking these are difficult for triagers to assess quickly.
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.
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:
\nAsegú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.
If there’s a consensus agreement on the feature, then it’s appropriate to\ncreate a ticket. Include a link the discussion on django-developers in the\nticket description.
\nAl 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!
\nConsulte también: :ref: documentando nuevas funcionalidades.
\nSiempre 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:
\n+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.
\nHowever, consensus is not always possible. If consensus cannot be reached, or\nif the discussion towards a consensus fizzles out without a concrete decision,\nthe decision may be deferred to the technical board.
\nEl consejo técnico utilizará internamente el mismo mecanismo de votación. Una propuesta se considerará adoptada si:
\nHay 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.
\nYa 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”.
\nLas votaciones sobre cuestiones técnicas se deberían anunciar y llevar a cabo públicamente en la lista de correos django-developers.
\n