Cabina de votaciones - 17 18

Miembros del grupo

- Ignacio José Alés López, coordinador del grupo.
- Juan Carlos López Muñoz, gestor de incidencias.
- Jorge Gordo Aguilar, programador.
- Antonio Rodríguez Artacho, programador.
- Javier Román Bayar, programador.

Resumen del trabajo

Nuestro trabajo consistirá en realizar el apartado de cabina de votación que consiste en permitir mediante el uso de un conjunto de métodos la posibilidad de que los usuarios puedan votar anónimamente teniendo en cuenta las restricciones posibles que puedan existir.

Modelo de uso del repositorio

En esta sección se describirá cómo se gestionará el código fuente y otros productos resultados del trabajo realizado por el grupo.

Se dispone de dos repositorios, en uno de ellos se guardará la documentación del proyecto (https://github.com/EGC-G2-Trabajo-1718/egc-cabinas) y en el otro se pondrá el código del programa (https://github.com/EGC-G2-Trabajo-1718/cabina-de-votacion).

Commits

Los commits se realizarán cada día que se realice alguna tarea correspondiente con el proyecto y deben tener el siguiente formato:

 <razón>:<título>
 (<colaboradores>)
 <cuerpo>
 (IMPORTANTE
 <detalles importantes>)

Se describirán cada componente del formato ahora:
- razón: Consitirá en la causa de la subida del commit, que puede ser uno de los siguientes: fix (arreglo), add (funcionalidad añadida), doc (documentación de código o otros).
- título: Resumen, de menos de 20 palabras del commit.
- colaboradores: Miembros del grupo que han ayudado en la realización del trabajo.
- cuerpo: Explicación más en profundidad del contenido del commit.
- IMPORTANTE: Sección donde se describe un detalle importante.
- detalles importantes: Detalles a destacar para otros miembros del grupo.

Ramas

La gestión de ramas será la siguiente:
- master: Contendrá una versión funcionando y con las funcionalidades confirmadas por el equipo de integración. Se considera usable para producción.
- dev: Contendrá una versión en funcionamiento, pero puede contener problemas de código o conflictos con otras funcionalidades, necesitará un testeo en entorno de pre producción.
- <funcionalidad>: Esta rama contendrá una versión master del código y desarrollará una funcionalidad para la próxima versión del programa.
- <miembro>: Esta rama será personal para cada uno de los desarrolladores y no será modificada por otros miembros del grupo. Podrá contener código en cualquier estado (por ejemplo sin compilar correctamente).

El funcionamiento para pasar de una rama a otra será el siguiente. - miembro a funcionalidad: Los miembros que tengan asignada la funcionalidad podrán modificar y realizar merge de la rama personal a la funcionalidad.
- funcionalidad a dev: Para poder actualizar dev, se deberá realizar un pull request y se realizarán pruebas de que el funcionamiento de la funcionalidad es correcta).
- dev a master: Se realizará un nuevo pull request, donde se indicarán los cambios de una versión de master a otra. De nuevo pasará por un periodo de pruebas para asegurar que funciona de forma correcta.

Al implementarse el sistema de integración continua, se usarán Pull Requests para pasar de una rama a otra, como se ve en el apartado anterior. El Pull Request no podrá ser aceptado hasta que la integración continua indique que la nueva versión es compilable y aprueba los tests indicados. Una vez se obtenga una versión correcta, el jefe del proyecto (Ignacio José Alés López) eligirá o él mismo realizará una evaluación del código y hará comentarios pertinentes. Si se decide que el pull request es válido, se procederá a confirmar el merge de las ramas.

Incidencias

Las incidencias realizadas a nuestro módulo deben seguir el siguiente formato:

 Título: (descripción breve del error, debe ser reconocible entre otros posibles errores, por lo que mencionar acción, resultado incorrecto...)
 Grupo: (grupo al que pertenece el creador de la incidencia o grupos a los que le influyen la incidencia)
 Prioridad: (¿Es necesario tener la solución cuanto antes o es un pequeño detalle a arreglar?. Podrá tener los siguiente valores: Baja, Media, Alta)
 Descripción: (Descripción textual del error, un resumen del problema o mejora).
 (Si aplicable) Pasos para reproducir: (Lista de acciones que se debe realizar para que se produzca el error, cuanto más preciso mejor)

Además, se asignará a un miembro del grupo para gestionar la incidencia, por parte del gestor de incidencias. Se asignará labels que mostrarán el estado de la incidencia y tendrá los siguiente valores:

- Estado: Puede ser Por iniciar, En progreso y Por revisar.
- Prioridad: Será asignada por el gestor de la incidencia, según sea necesario. Podrá ser Baja prioridad o Muy importante.
- Otros: Estos serán los labels creados por defecto en Github y serán asignados por el gestor de incidencias como sea necesario.