Cómo informar sobre incidencias y problemas

From Joomla! Documentation

This page is a translated version of the page Filing bugs and issues and the translation is 100% complete.

Other languages:
català • ‎English • ‎español • ‎français • ‎Bahasa Indonesia • ‎italiano • ‎Nederlands • ‎português • ‎русский • ‎svenska • ‎Türkçe • ‎中文(台灣)‎

Para informar acerca de una incidencia en el gestor de incidencias de Joomla!, necesitará crear un elemento del gestor. Una vez el elemento es creado, los desarrolladores comprobarán su validez y actuarán en consecuencia. Si desea ayudar a probar parches para Joomla, por favor siga estas instrucciones sobre cómo hacerlo.

Informando sobre incidencias

Registrar una cuenta en GitHub

Necesitará registrar una cuenta en GitHub; el Gestor de Incidencias de Joomla! usa estas cuentas para autenticarse en el sistema.

Cómo acceder al gestor de incidencias de Joomla!

Compruebe si la incidencia sobre la que quiere informar ya ha sido comunicada

Una serie de filtros muestran los elementos del gestor a los que se puede acceder haciendo clic en el botón "Herramientas de búsqueda" en la parte superior de la lista. Pase el ratón sobre el título de los elementos del gestor para ver su contenido. Si el problema que está experimentando no ha sido comunicado aún, haga clic en el botón "Nuevo elemento" en la zona principal de navegación.

Se mostrará una nueva pantalla y, una vez ahí, mientras más información proporcione más fácil será para los desarrolladores.

Introduzca tantos datos como pueda. Puede activar los consejos para cada campo cambiando el selector "Modo de vista" en la parte derecha de la pantalla de Pro a Ayuda.

  • Prioridad: Use el nivel predeterminado "Medio" salvo que conozca el código lo suficiente como para elegir otro modo.
  • Build: Escriba aquí la(s) versión(es) afectada(s) por el problema.
  • Categorías: Este es un poco más complicado. Use "Administración" si no conoce uno mejor.
  • Título: un breve resumen del problema.
  • Descripción: Detalles del problema. Consulte la sección siguiente para obtener más información.
  • Subidas: A los usuarios se les permite subir imágenes en los informes. La información sobre los requisitos de carga aparece en el formulario del informe.

Proporcione un resumen

Describa en unas pocas palabras los problemas que ha encontrado. Normalmente es una buena idea usar elementos existentes del gestor como ejemplo si es la primera vez que informa de un fallo.

Ejemplos:

  • Interfaz público: Advertencia tal y tal.
  • Interfaz de administración: no se puede guardar el artículo cuando "nombredelplugin" está publicado.

Aviso: procure ser descriptivo en su resumen, pues este será lo primero que los desarrolladores verán cuando estén hojeando el gestor en busca de algo que arreglar.

Proporcione detalles sobre la incidencia

Para proporcionar la mayor información posible, el gestor rellena el campo de descripción con una plantilla que contiene 5 subsecciones:

  • Pasos para reproducir la incidencia: pasos detallados sobre cómo otra persona puede reproducir su incidencia.
  • Resultado esperado: lo que cree que debería ocurrir al realizar los pasos anteriores.
  • Resultado real: lo que realmente sucede al realizar los pasos anteriores
  • Información del sistema: información acerca del entorno en el que está configurado su sistema. Esto podría incluir el navegador que está usando, la versión PHP de su servidor o el tipo de base de datos que su sitio está usando. Para obtener resultados óptimos, debe copiar estos datos de la vista Información del Sistema de su sitio -puede acceder a dicha vista iniciando sesión en la parte administrativa del sitio.
  • Comentarios adicionales: cualquier información adicional no proporcionada anteriormente que podría ser beneficiosa para la depuración y resolución del problema.

El formato general debería ser algo como:

  1. "Esto es exactamente lo que hice."
  2. "Esto es lo que pasó."
  3. "Esto es lo que creo que debería haber pasado."
  4. "Otra información, posible solución, parche de código propuesto."

Cuantos más detalles, mejor. También, es importante reproducir la incidencia utilizando los datos de ejemplo de Joomla!, o con instrucciones claras y fáciles de cómo configurarlo. Recuerde que los demás no tendrán acceso a la base de datos de su sitio, por lo que tendrá que ser capaz de decirle a alguien cómo ver la incidencia con los datos que ya están disponibles en el sitio de muestra.

Ejemplo A

Lo que hice
empecé con el sitio de prueba. Todo estaba bien. Activé "nombredeplugin". Intenté guardar cualquier artículo desde la interfaz administrativa.
Lo que pasó
me sale una pantalla en blanco y artículo no se guarda.
Lo que debería haber pasado
los artículos deberían guardarse correctamente.
Información adicional
Estos son los plugins habilitados al mismo tiempo. SEF está activado (o desactivado). Mi sitio está en una subcarpeta. También observo que... etc. Creo que tales y tales archivos son el problema (si sabe lo que está hablando).

Ejemplo B

Lo que hice
acceder a la interfaz administrativa. Clic en el menú "menu_name".
Lo que ocurrió
la página que se abrió estaba en blanco.
Lo que debería haber sucedido
El Menú debería haber abierto correctamente.
Otra información
cualquier otro menú funciona correctamente, etc.

Ejemplo de la vida real

  • Lo que hice
  1. Comencé con el sitio web de muestra.
  2. Añadí un artículo sin publicar desde la zona administrativa, con Sección=FAQ, Categoría=General
  3. En los parámetros avanzados del artículo, establecí Mostrar Título como "No", e iconos Imprimir, PDF y Email como "Ocultar".
  4. Guardé el artículo y navegué a la parte pública del sitio. Inicié sesión en la parte pública como administrador y navegué al elemento de menú Páginas de Ejemplo > Categoría en formato Blog
  • Lo que ocurrió: el artículo recién añadido es mostrado, pero no hay icono de editar en el que hacer clic en la parte pública.
  • Lo que debería haber ocurrido: el icono de editar debería ser mostrado, permitiendo al usuario final de la parte pública editar este artículo.
  • Otra información: esto sólo pasa con la plantilla rhuk_milkyway. Cambiando este código [código propuesto] en el archivo [nombre y ruta del archivo], línea(s) #, el problema parece resolverse en mi sistema.

Proponer un parche directamente al repositorio de Joomla! en GitHub

Si desea proponer una solución ofreciendo directamente el código dentro de Joomla!, puede hacerlo mediante la emisión de una "propuesta de parche" (pull request) en el repositorio de código de Joomla! en GitHub.com, ubicado aquí: https://github.com/joomla/joomla-cms

Este proceso requiere un poco de conocimiento acerca de los Sistemas de Control de Código Fuente (SCM por sus siglas en inglés) y de Git en particular. Si ya sabe qué es el SCM Git y cómo funciona, el proceso es sencillo:

  • Regístrese para obtener una cuenta gratuita en GitHub.com
  • Bifurque el repo de Joomla!
  • Switch to the "staging" branch if you wish to propose a fix for the current Joomla! 3.x release or to the "3.x-dev" branch if you want to propose a fix for the next Joomla! Version 3.x.
  • Añada/actualice los archivos de Joomla! relacionados en la rama adecuada y después haga clic en el botón "revisar & comparar" - más información sobre esto aquí https://help.github.com/articles/using-pull-requests - para iniciar el proceso de envío de "pull request".

Consejos y trucos adicionales

Los informes de incidencias bien escritos son increíblemente útiles. Sin embargo, trabajar con cualquier sistema de seguimiento de incidencias produce una cierta cantidad de sobrecarga de trabajo, por lo que se apreciará su ayuda en mantener nuestro gestor de tickets lo más útil posible. En particular:

  • Lea las preguntas frecuentes para ver si su problema es uno ya conocido.
  • Busque en el gestor para ver si su problema ya ha sido comunicado.
  • Do ask on bug reporting forums for Joomla 3.x first if you're not sure if what you're seeing is a bug.
  • Escriba informes de incidencias específicos, reproducibles y completos. Incluya tanta información como le sea posible, con fragmentos de código, casos prácticos, etc. Un ejemplo mínimo que ilustre la incidencia con un pequeño caso práctico es el mejor informe de error posible.
  • No utilice el sistema de seguimiento para hacer preguntas de soporte. Utilice para eso los foros oficiales de Joomla! o el canal IRC en freenode #joomla.
  • No utilizar los gestores de incidencias para hacer peticiones de nuevas características a gran escala. Nos gusta hablar de grandes cambios para el núcleo de Joomla! en los foros de desarrolladores antes de ponernos a trabajar en ellos.
  • No reabra problemas que han sido marcados como "not a bug" (no es un fallo). Esta marca significa que se ha tomado la decisión que no podemos o no queremos solucionar este problema en particular. Si no está seguro del porqué, por favor pregunte en los foros de desarrolladores.
  • No utilice el gestor para largos debates, porque son propensos a perderse. Si un elemento en particular del gestor es controvertido, mueva la discusión a developer forums.

Informando sobre problemas de seguridad

Informe sobre problemas de seguridad en security [arroba] joomla [punto] org. Esta es una lista privada accesible únicamente a desarrolladores de confianza que llevan mucho tiempo colaborando con el proyecto, y sus archivos no son accesibles públicamente.

En el caso de una vulnerabilidad en Joomla! confirmada, se realizarán las siguientes acciones:

  • Acusar recibo, al informador, de la recepción del informe y que la solución está próxima. Se dará un calendario aproximado y se le pedirá al informador de que mantenga el problema secreto hasta que se haga público.
  • Detener cualquier otro desarrollo mientras sea necesario para desarrollar una solución, incluyendo parches sobre la versión actual y las dos precedentes.
  • Determinar una fecha de publicación para anunciar la vulnerabilidad y su corrección. Para tratar de mitigar una posible "carrera armamentista" entre los que deben aplicar el parche y aquellos que tratan de explotar el agujero, no anunciaremos los problemas de seguridad inmediatamente.
  • Anunciar públicamente la vulnerabilidad y la corrección en la fecha acordada. Esto probablemente signifique una nueva versión de Joomla!, aunque en algunos casos puede tratarse simplemente de parches para las versiones actuales.