Gestión del programa - 17 18 - G1

Miembros

• Francisco Aguilar Cano
• Francisco Javier Ordóñez Medina
• Juan Antonio Rodríguez Regidor (Coordinador)
• Felipe Trinidad Márquez
• Pablo Pino Jiménez

Función y dependencias

La función principal de nuestro subsistema es almacenar y añadir información referente a la programación del congreso.

Nuestro subsistema tiene una unica dependencia:

• Gestion de visualización de programa.

Objetivos

Cumplir los siguientes incrementos:

• Cambiar el soporte de lectura de Excel a Drive y otras plataformas.
• Implementar un sistema de gestión de estados para permitir la previsualización del programa antes de publicarlo.
• Implementar un sistema de gestión de versiones para permitir pasar de una a otra.
• Implementar un sistema de caché, para leer menos veces el documento.

Enlaces de interés

Repositorio de GitHub

El repositorio de GitHub del equipo será accesible en este enlace.

Grupo de Opera

El portal del proyecto en Opera será accesible en este enlace.

Gestión de código e incidencias

Gestión de incidencias

Para la gestión de incidencias se hará uso de los Issues de GitHub de la siguiente forma:

• Cada Issue representará una tarea o un problema encontrado por el grupo.
• Cada Issue será situado en un proyecto interno al repositorio, siendo actualizado entre las distintas fases según corresponda a su avance. Las fases son:
  • TO DO
  • En progreso
  • En espera/ con problemas
  • En revisión
  • Hecho
• Para cada avance o actualización de un Issue, se hará un comentario dentro de la Issue especificando el cambio y su motivo (si procede).
• Una vez terminado un Issue se debe añadir un comentario de cierre y se debe colocar en la columna "Hecho".
• Cada Issue debe ser etiquetado en funcion de:
• Temática
• Documentation
• Database
• Code
• Investigation
• Prioridad
• Critical
• High
• Medium
• Low
• Estado
• New
• Accepted (sólo para cambios)
• Started
• Fixed
• Verified
• Duplicate (cambios y bugs)
• Wontfix (cambios y bugs)
• Tipo
  • Enhancement
  • Bug
• Procedencia
  • No se añade ninguna etiqueta si es una incidencia interna.
  • external

Durante el avance del Issue se irán actualizando las etiquetas, en el proyecto y en los comentarios.

</ul>

Gestión de código

Formato de Commits

<Tipo> : <Título del commit> 
 
<Cuerpo del commit> 
 
<Pie del commit>

• <Tipo> : puede tomar los siguientes valores:
  • New (nuevo archivo)
  • Update(actualización de un archivo)
• <Título del commit>: lo más descriptivo posible.
• <Cuerpo del commit>: se indicará de forma más detallada el commit.
• <Pie del commit>: indicará el issue al que hace referencia, de la siguiente forma: Closes ó Refers #(número de Issue)

Ejemplo de commit:

Update : votar más de una vez 
 
Se ha solucionado el bug de que un usuario pueda votar más de una vez para la misma votación. Antes un usuario podía votar en repetidas ocasiones, ahora un mismo usuario sólo puede votar una vez por votación. 
 
Closes #14

Ramas

Gestionaremos el proyecto añadiéndo una rama para cada miembro del equipo, los progresos de estas ramas se volcarán a la rama de desarrollo y de esta se volcará a la rama master, que contendrá el código funcional estable.

Siendo R1...R5: fraagucan, fraordmed, juarodreg, feltrimar y pabpinjim.