Prioridad del gestor de incidencias y errores

From Joomla! Documentation

This page is a translated version of the page Bug and Issue Tracker Priority and the translation is 56% complete.

Outdated translations are marked like this.
Other languages:
català • ‎Deutsch • ‎English • ‎español • ‎français • ‎हिन्दी • ‎Bahasa Indonesia • ‎Nederlands • ‎русский

Para entender cómo se realiza un seguimiento de los problemas e incidencias según su prioridad, aquí hay un escenario común que ocurre con frecuencia.

Ha estado tratando de solucionarlo durante horas, nadie en los foros ha sido capaz de ayudarle, el problema parece no estar contemplado en la documentación y probablemente también se le esté agotando el tiempo. Es hora de enviar el problema al rastreador. Después de todo ese esfuerzo, seguro que parece un problema crítico. Por tanto, selecciona un nivel de prioridad alto.

¿Qué ocurre entonces? Alguien del JBS va y lo cambia a prioridad media. ¿Por qué hacen eso? ¿Significa que su problema no es importante y no se tratará? ¿Que son gente mala a la que no les importan los demás? Por supuesto que no. Simplemente resulta que el grupo de trabajo de desarrollo tiene unas definiciones bastante estrictas sobre los niveles de prioridad.

Definiciones de prioridad

Las incidencias (bugs) son priorizadas de acuerdo con las siguientes características:

Prioridad 1 → Alta/Crítica

La parte troncal de Joomla no está funcionando en absoluto. Partes significativas del código fuente están rotas, evitando el funcionamiento de operaciones clave. Posibles ejemplos serían el inicio de sesión, la instalación, instaladores de extensiones, errores javascript que impiden guardar o acciones similares, etc. También incluye la generación de errores fatales de PHP.

Prioridad 2 → Media-alta/Mayor

Partes del código fuente están impidiendo el correcto funcionamiento de forma seria, o causando una pérdida importante en una función concreta.

Prioridad 3 → Media/Normal

Problemas que están impidiendo un comportamiento anunciado, pero la aplicación sigue siendo viable. Algunos ejemplos podrían ser; parámetros que no funcionan como se supone que deberían, archivos de idioma que no cargan como cabría esperar, etc.

Prioridad 4 → Baja/Menor

Pérdida menor de función y comportamiento molesto en general. Puede incluir problemas poco comunes específicos de una plataforma o navegador concretos que aunque pueden ser técnicamente importantes en esos entornos, representan una minoría. También incluye cadenas de traducción faltantes.

Prioridad 5 → Muy Baja/Trivial

Problemas cosméticos, palabras mal deletreadas, objeto desalineado gráficamente, problemas poco comunes con parámetros, etc.

¿Qué significa esto?

Antes que nada, si no es dentro de los primeros pocos días tras el lanzamiento de una nueva versión y no implica un problema de seguridad, a menos que esté usando subversion o una "nightly build" lo más probable es que nunca vea o necesite informar sobre una incidencia de prioridad 1 (alta). Esto es porque si hay alguna incidencia de este tipo abierta en la base de código, no habrá un nuevo lanzamiento. De hecho lo mismo es aplicable para las de prioridad 2 (media alta). Una incidencia de prioridad 1 real en una versión recién lanzada es algo que desencadenaría una nueva versión. Una incidencia de prioridad 1 o 2 en una rama de la base de código impediría que se produjera un lanzamiento programado. Esto es grave, porque cada nueva versión contiene muchas soluciones a problemas y mejoras, de modo que no lanzarla impide a la mayor parte de la comunidad obtenerlas. Forzar el lanzamiento de una nueva versión no programada también es algo serio, pues significa que el trabajo en otras cosas se detiene mientras todos los esfuerzos son puestos en tener lista esa nueva versión.

La única excepción sería si descubre un problema de seguridad importante, pero el gestor de incidencias no es el lugar para informar sobre la mayoría de los problemas de seguridad.

Esto no significa que nunca haya incidencias de prioridad 1 o 2. Una de prioridad 1 se puede desarrollar (http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=11225) en el código fuente de Joomla! actual que se encuentra en Subversión. Subversión es donde se realizan todos los cambios al código fuente.

De modo que, antes de decidir marcar una incidencia como prioridad 1 o 2, piense si realmente garantizaría todas esas cosas.

La mayoría de las incidencias son de prioridad 3, media. Sin embargo, algunas son de prioridad 4 o 5. ¿Significa eso que si marca su incidencia como prioridad 4 o 5 no será solucionada? En absoluto. Si se trata de un problema fácil de solucionar, especialmente si proporciona un parche o propone código para solucionarlo, se atenderá sobre la marcha. Algunos miembros del JBS se especializan informalmente en problemas con los idiomas o el CSS u otros temas que normalmente se encuentran en las incidencias de prioridad 4 o 5. De modo que no tenga la sensación de que necesita marcar una incidencia como prioridad 3 para que sea atendida.