# documentación de Django - 3.2.11.dev

# Cómo informar de errores y solicitar funcionalidades

Importante

Por favor, informe los problemas de seguridad solo a security@djangoproject.com. 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:

- 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.
- If you’re offering a patch which 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 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

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.

However, consensus is not always possible. If consensus cannot be reached, or if the discussion towards a consensus fizzles out without a concrete decision, the decision may be deferred to the 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.