Reportar incidencias en un proyecto de GitLab

Antes de liberar una aplicación, se prueba en diferentes escenarios para asegurarse que todo funciona como debe. En algunas ocasiones no es posible hacer todas las comprobaciones y los usuarios que usan la aplicación encuentran un bug. No es algo malo y se puede solucionar avisando al programador y dándole toda la información necesaria para replicar el bug y poder arreglarlo. La forma de reportar el fallo depende de cada aplicación. Si la aplicación usa Git, probablemente tendrá el código fuente publicado en GitLab o en GitHub. Esta información la indicarán en la página oficial de la aplicación. Veremos a continuación los pasos para reportar un bug en GitLab en el proyecto de Ubuntu Touch para el PinePhone. Es un ejemplo que se puede extrapolar a cualquier otro proyecto.

Incidencia, bug o nueva función

El primer punto es diferenciar los tres términos. Dentro de la terminología de GitLab una incidencia (issue) puede ser tanto un bug como una nueva función. Digamos que tenemos una forma genérica de decir, “aquí hay algo que no funciona o puede funcionar de otra forma”. Un bug sería, al pulsar la pantalla del teléfono la cafetera me prepara un café. Una nueva función podría ser que al llamar a una persona aparezca un holograma en 3D delante de nosotros.  En principio hay que hacer reportes con cabeza. Es importante dar todos los detalles porque eso simplifica mucho la vida al programador.

Listado de Issues en el PinePhone

Listado de incidencias en el PinePhone

Revisar antes de reportar

Al entrar en una incidencia podemos ver más detalles relacionados. También pueden los usuarios indicar si les ocurre igual o funciona todo bien. En muchas ocasiones es más complicado forzar el fallo que encontrar la solución. Por estar razón es muy importante dar toda la información necesaria.

Detalles de una incidencia

Detalles de una incidencia

He comentado que cualquier usuario puede reportar incidencias en GitLab. Ésto que es una ventaja, también es un inconveniente porque hace necesario dedicar tiempo a gestionar las incidencias. Podemos tener una incidencia que sólo dice el problema pero no la forma de forzarlo. Otra puede estar duplicada varias veces o estar mal categorizada.

Como regla general, antes de crear una incidencia hay que revisar las incidencias anteriores. En estos momentos Ubuntu Touch tiene muchas incidencias reportadas (algunas desde 2017). Habrán seguramente incidencias que ya se han arreglado (pero no se han cerrado), incidencias duplicadas, etc. Para solucionar ese problema hace falta tiempo para encargarse de la organización de las incidencias. Mientras lo consiguen, lo mejor que podemos hacer es revisar que no esté reportada antes. Si lo está, hay que leer toda la información de la incidencia y completar la información que falte.

Tiempos para resolver una incidencia

Aquí tenemos un pequeño problema. El número de programadores es reducido y trabajan en Ubuntu Touch en su tiempo libre (muchas veces de forma altruista). Por lo general, no se puede dar una estimación del tiempo que tardará en resolverse una incidencia. Puede ser una tontería, como una traducción incorrecta, o algo más complejo que implique cambios en muchas partes del sistema. Sólo después de analizarlo se podrá ver si es viable corregirla en ese momento o hay que ponerla a la cola de cosas pendientes. Los recursos son limitados y hay que atacar primero las incidencias que afectan a más usuarios.

Otros datos de las incidencias

En GitLab hay varios roles de usuarios. El más básico permite reportar la incidencia, añadiendo un título y una descripción.

Datos de la incidencia

Datos de la incidencia

Si nos fijamos en el lateral de una incidencia que ya exista, hay más elementos. Entre ellos está el hito (el siguiente lanzamiento del programa), los tiempos estimados o las etiquetas. Estos campos no están disponibles directamente para el rol más básico. Las personas que tengan un rol superior podrán organizar las incidencias y asignarlas a una versión concreta del programa. Un detalle que simplifica mucho el proceso es usar las etiquetas. Las etiquetas permiten acceder de forma rápida a todos las incidencias que tienen asociada esa etiqueta. Por ejemplo, podemos ver de forma rápida las incidencias que afectan al PinePhone.

Etiquetas en GitLab

Etiquetas en GitLab

Conclusiones

En esta entrada hemos visto los pasos para reportar una incidencia en GitLab. Nos hemos centrado en el proyecto de Ubuntu Touch para el PinePhone pero lo explicado aquí se puede adaptar a cualquier otro proyecto. Es normal que un proyecto tenga incidencias, ya sean bugs o funciones nuevas. Eso significa que hay usuarios usándolo y que encuentran cosas que no funcionan como deberían. Algunas veces serán bugs y otras serán cuestiones de diseño. Por ejemplo, se puede considerar como bug que la barra del lanzador de aplicaciones de Ubuntu Touch esté siempre fija en el escritorio. En realidad, está diseñado de esa forma para que los usuarios que conocer por primera vez vean la barra y puedan trabajar con el dispositivo. Para solucionar estos casos, se suelen usar los comentarios de la incidencia ya que permiten participar en una conversación y que todo quede registrado.

Reportar una incidencia sólo hace que sea conocida por el programador. No implica que se resolverá con la máxima prioridad posible. Todo ésto queda a discreción del programador. Si una incidencia afecta a muchos usuarios, tendrá prioridad. Si no hay suficiente información y afecta a pocos usuarios, tardará más en resolverse. Lo importante antes de reportar una incidencia es comprobar si ya estaba reportada antes. Puede parecer un trabajo extra que no aporta nada, pero ayuda mucho al desarrollo. Una cosa está clara. Si el tiempo es limitado y hay mucho ruido (en forma de incidencias repetidas o sin información), habrá menos tiempo para dedicarse a la programación.

0 comentarios

Dejar un comentario

¿Quieres unirte a la conversación?
Siéntete libre de contribuir!

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.