Diferencia entre revisiones de «Gestión del programa - 17 18 - G1»
De Wiki de EGC
| (No se muestran 8 ediciones intermedias de 2 usuarios) | |||
| Línea 76: | Línea 76: | ||
<li> Database </li> | <li> Database </li> | ||
<li> Code </li> | <li> Code </li> | ||
| + | <li> Investigation </li> | ||
</ul> | </ul> | ||
<li> Prioridad </li> | <li> Prioridad </li> | ||
| Línea 98: | Línea 99: | ||
<li> Enhancement </li> | <li> Enhancement </li> | ||
<li> Bug </li> | <li> Bug </li> | ||
| + | </ul> | ||
| + | </ul> | ||
| + | <li> Procedencia | ||
| + | <ul> | ||
| + | <li> No se añade ninguna etiqueta si es una incidencia interna. </li> | ||
| + | <li> external </li> | ||
</ul> | </ul> | ||
</li> | </li> | ||
| Línea 106: | Línea 113: | ||
</ul> | </ul> | ||
| − | |||
=== Gestión de código === | === Gestión de código === | ||
| Línea 121: | Línea 127: | ||
<Tipo> : puede tomar los siguientes valores: | <Tipo> : puede tomar los siguientes valores: | ||
<ul> | <ul> | ||
| − | <li> | + | <li> New (nuevo archivo) </li> |
| − | <li> | + | <li> Update(actualización de un archivo) </li> |
| − | |||
| − | |||
</ul> | </ul> | ||
</li> | </li> | ||
| − | <li><Título del commit>: | + | <li><Título del commit>: lo más descriptivo posible.</li> |
<li><Cuerpo del commit>: se indicará de forma más detallada el commit.</li> | <li><Cuerpo del commit>: se indicará de forma más detallada el commit.</li> | ||
| − | <li><Pie del commit>: | + | <li><Pie del commit>: indicará el issue al que hace referencia, de la siguiente forma: Closes ó Refers #(número de Issue)</li> |
</ul> | </ul> | ||
Ejemplo de commit: | 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.''' | '''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.''' | ||
| Línea 143: | Línea 147: | ||
'''Closes #14''' | '''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. | |
| + | |||
| + | |||
| + | [[Archivo:Ramas GP EGC.png]] | ||
| + | |||
| + | Siendo R1...R5: fraagucan, fraordmed, juarodreg, feltrimar y pabpinjim. | ||
Revisión actual del 12:59 15 ene 2018
Contenido
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:
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
</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.
