Cabina de telegram - 17 18 - G1

Miembros

• Francisco Manuel Cordero Vela
• Daniel Benítez Rodríguez
• José Manuel Lázaro Domínguez
• José Ángel Romero Adame
• Miguel Ángel Mogrovejo Campero

Objetivos

se trata de crear un bot para la aplicación Telegram que nos permita votar a través de esta herramienta.

Opera

Nuestro proyecto puede encontrarse en el siguiente [1]

Repositorio de GitHub

El repositorio de GitHub del equipo será accesible en este [2] Cualquier cambio o documentación importante añadida a él se notificará a los coordinadores en el momento.

Entorno de trabajo

Para la gestión del código se utiliza Git.

Para la gestión de las incidencias se utiliza GitHub.

Para la comunicación entre el grupo usamos Discord y Telegram.

Para la modificación del código usamos Sublime Text 3.

Para la Implementación usamos Nodejs.

Puerto del entorno de trabajo

Se han asignado el siguiente puerto a nuestro subsistema:

Subsistema	Puerto
Cabina de Télegram	52004

Formateo de commits

Para llevar a cabo las tareas de gestión de cambios, código e incidencias, se hará uso de la plataforma GitHub, siguiendo las directrices expuestas en clase:

Para gestionar el código, se harán commits y push en dichos repositorios siguiendo las pautas especificadas en las diapositivas de clase durante la explicación de la gestión del código fuente (http://1984.lsi.us.es/wikiegc/ index.php/Teor%C3%ADa_-_17/18). A partir de las versiones finales desarrolladas por cada grupo en cada iteración, los integrantes del equipo de Integración indicarán una semana antes de cada milestone si es necesario subir con antelación el avance funcional hecho por cada subgrupo al repositorio del Equipo de Arquitectura e Integración para disponer del código hecho. Los commits en local se harán libremente cuando el equipo estime oportuno, siendo necesario agruparlos en un push con un incremento de subversión en caso de implementar parte de una funcionalidad completa, o en un push con un incremento de versión en caso de implementar dicha funcionalidad al completo. En caso de ser requerido por el equipo de integración, se harán en su repositorio. El número de versionado y su nomenclatura se explican en el punto siguiente. Debido a la libertad de creación de commits, para poder agruparlos de forma más rápida a la hora de hacer un push en el servidor, se seguirá el formato siguiente:

• Título: Incluirá la palabra New o Update dependiendo si es un archivo nuevo o una actualización de uno existente, seguido de un título descriptivo del commit.
• Descripción: Contendrá una explicación más detalla del contenido del commit.
• Pie: Indicará el Issue al que hace referencia el Commit.

Procedimiento de gestión de cambios

Para la gestión de cambios, se procederá de la siguiente manera:

1. Cada grupo que desee plantear un cambio, deberá plantearlo antes dentro de su grupo.
2. Si se rechaza termina el proceso, y si se acepta se traslada dicho cambio al Equipo de Integración.
3. El Equipo de Integración valorará dicho cambio. Si lo rechaza el cambio no se aplicará, y si lo acepta se comunicará a los subgrupos de dicho cambio y se actualizarán los elementos de documentación pertinentes.

Para representar cada cambio en GitHub, se creará un Issue dentro del repositorio del subgrupo correspondiente (el que genera dicho cambio y los que se ven afectados por el mismo) con el formato expresado en el algoritmo de la sección “Formato para incidencias, cambios y tareas” La creación del issue dentro del repositorio X corresponde al subgrupo X y a nadie más.

Procedimiento de gestión de tareas, cambios e incidendias

Para la gestión de las incidencias, se usarán los Issues que GitHub permite gestionar en cada repositorio. El uso de estos Issues está basado en las diapositivas de clase de (Gestión de Incidencias), haciéndose de la siguiente manera:

• Cada grupo es responsable de la gestión de sus Issues.
• Cada Issue representará una tarea o problema encontrado por el grupo.
• Cada Issue será situado en un proyecto interno al repositorio, siendo actualizado entre las fases TO DO, En progreso, En espera/Con problemas, En revisión y Hecho según corresponda a su avance.
• Para cada avance o actualización de un Issue, se hará un comentario dentro de éste especificando el cambio hecho, indicando su motivo si procede.
• Una vez terminado un Issue se debe cerrar con un comentario de cierre y cerrándolo en sí mismo tras colocarlo en la columna Hecho se su proyecto correspondiente.
• Cada Issue será etiquetado en función de su temática, prioridad, estado y tipo. Los tipos son Cambio/Mejora y Bug, que sólo se incluirán en dichos casos. Las temáticas son libres para cada subgrupo. Las prioridades son Critical, High, Medium y Low, y los estados son New, Accepted (sólo para cambios), Started, Fixed, Verified, Duplicate (cambios y bugs) y Wontfix (cambios y bugs).
• Las etiquetas de cada Issue deben ser actualizadas durante el avance del mismo, con su correspondiente actualización en el proyecto y su comentario pertinente.

Directrices de gestión de dudas y documentación

El procedimiento a seguir para plantear y resolver dudas al equipo de integración es el siguiente:

1. Plantear la duda dentro del grupo de trabajo.
2. Contactar con el equipo de integración para indicarle la duda.
3. El equipo de integración creará el issue en su repositorio indicando la duda o incidencia.
4. El equipo de integración asignará a alguien para el seguimiento de dicha duda y su resolución junto con el equipo que la ha planteado.

Respecto al desarrollo de documentos, éstos seguirán el siguiente formato:

• Si se tratan de documentos cuyo contenido sea código, la nomenclatura del archivo subido será: NombreSubgrupo-versión. Las versiones se incrementarán cada vez que el subsistema reciba una nueva funcionalidad completa (por ejemplo el proceso de creación completo de una votación). Las subversiones se incrementarán cada vez que se añada una nueva parte a un proceso funcional completo (por ejemplo añadir el formulario de creación de una votación), y los números de parche se incrementarán cada vez que se solucione un bug dentro de dicha subversión.
• En el caso de documentación de otro tipo, se seguirá el esquema NombreSubgrupo-NombreDocumento, con el fin de aclarar el contenido de dicho archivo.

Independientemente del tipo de documento, a la hora de subirlo al repositorio del Equipo de Integración, deberá hacerse en la carpeta especificada por éste cuando se solicite el documento.

Directrices de gestión de ramas

Cada grupo debe tener en su repositorio una rama principal, con toda la documentación, a partir de la cual saldrán las siguientes ramas secundarias opcionales:

• Ramas que representan diferentes funcionalidades del grupo. Por ejemplo: Scripts MySQL, Entornos…
• Ramas personales de cada miembro del grupo, según estime el coordinador de éste.

Es responsabilidad del coordinador del grupo tanto el decidir qué ramas opcionales usar, si expandirlas con más de ellas, y hacer merge de las mismas cuando se complete cada ciclo del milestone si lo considera oportuno.