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.

Otherwise, before reporting a bug or requesting a new feature on the ticket tracker, consider these points:

• 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.
• Don’t reopen issues that have been marked «wontfix» without finding consensus to 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.

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.
• Do write complete, reproducible, specific bug reports. You must include a clear, concise description of the problem, and a set of instructions for replicating it. Add as much debug information as you can: code snippets, test cases, exception backtraces, screenshots, etc. A nice small test case is the best way to report a bug, as it gives us a helpful way to confirm the bug quickly.
• Don’t post to django-developers only to announce that you have filed a bug report. All the tickets are mailed to another list, django-updates, which is tracked by developers and interested community members; we see them as they are filed.

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:

• Include screenshots in your ticket which are the visual equivalent of a minimal test case. Show off the issue, not the crazy customizations you’ve made to your browser.
• 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 that changes the look or behavior of Django’s UI, you must attach before and after screenshots/screencasts. Tickets 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.

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:

• Make sure the feature actually requires changes in Django’s core. If your idea can be developed as an independent application or module — for instance, you want to support another database engine — we’ll probably suggest that you develop it independently. Then, if your project gathers sufficient 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 others understand where it fits in, and if there are already other ways of achieving the same thing.

If there’s a consensus agreement on the feature, then it’s appropriate to create a ticket. Include a link to the discussion on django-developers in the ticket description.

As with most open-source projects, code talks. If you are willing to write the code for the feature yourself or, even better, if you’ve already written it, it’s much more likely to be accepted. Fork Django on GitHub, create a feature branch, and show us your work!

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

Cómo tomamos decisiones

Whenever possible, we strive for a rough consensus. To that end, we’ll often have informal votes on django-developers or the Django Forum about a feature. In these votes we follow the voting style invented by Apache and used on Python itself, where votes are given as +1, +0, -0, or -1. Roughly translated, these votes mean:

• +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.»

Although these votes are informal, they’ll be taken very seriously. After a suitable voting period, if an obvious consensus arises we’ll follow the votes.

However, consensus is not always possible. If consensus cannot be reached, or if the discussion toward a consensus fizzles out without a concrete decision, the decision may be deferred to the steering council.

Internally, the steering council will use the same voting mechanism. A proposition will be considered carried if:

• There are at least three «+1» votes from members of the steering council.
• There is no «-1» vote from any member of the steering council.

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

Since this process allows any steering council member to veto a proposal, a «-1» vote should be accompanied by an explanation of what it would take to convert that «-1» into at least a «+0».

Votes on technical matters should be announced and held in public on the django-developers mailing list or on the Django Forum.