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.
Do write complete, reproducible, specific bug reports. You must\ninclude a clear, concise description of the problem, and a set of\ninstructions for replicating it. Add as much debug information as you can:\ncode snippets, test cases, exception backtraces, screenshots, etc. A nice\nsmall test case is the best way to report a bug, as it gives us a\nhelpful way to confirm the bug quickly.
Don’t post to django-developers only to announce that you have filed a\nbug report. All the tickets are mailed to another list, django-updates,\nwhich is tracked by developers and interested community members; we see them\nas they are filed.
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:
\nMake sure the feature actually requires changes in Django’s core. If your\nidea can be developed as an independent application or module — for\ninstance, you want to support another database engine — we’ll probably\nsuggest that you develop it independently. Then, if your project gathers\nsufficient community support, we may consider it for inclusion in 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.
Explain why you’d like the feature. Explaining a minimal use case will help\nothers understand where it fits in, and if there are already other ways of\nachieving the same thing.
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.
\nAs with most open-source projects, code talks. If you are willing to write the\ncode for the feature yourself or, even better, if you’ve already written it,\nit’s much more likely to be accepted. Fork Django on GitHub, create a feature\nbranch, and show us your work!
\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 toward 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