Gestion del Repositorio - Giratina-Votacion/decide GitHub Wiki

Nuestra gestión del repositorio se puede dividir en 3 partes: commits, incidencias y taras.

1 . GESTIÓN DE LOS COMMITS

Nuestro equipo seguirá la siguiente estructura a la hora de realizar un commit:

Commit correspondiente a la tarea #x, donde x es la tarea que ha realizado y de la cual ha comiteado y hecho push al repositorio.

Puede haber 2 tipos de commits: los que suponen un incremento del sistema y los que por alguna razón no se ha llegado hasta ese incremento.

  • Commit con incremento completo: simplemente seguir la estructura mencionada arriba y cerrar la tarea.
  • Commit sin incremento completo: se debe a que un miembro del equipo ha comenzado una tarea, ha realizado cambios pero tiene errores o no sabe como continuar, en tal caso se subirá al repositorio todos los cambios realizados y una explicacion en la tarea correspondiente para que los demás sepan que han hecho y puedan ponerse a terminar la tarea. En el caso de que no se pueda resolver, esa tarea sera movida a la columna Dropped, si por el contrario se consigue realizar se documentará que es lo que fallaba en el primer commit realizado para que todo el mundo sea consciente de ello.

2 . GESTIÓN DE LAS TAREAS

Hemos creado para ello un proyecto en nuestro repositorio que consta de 5 columnas:

  • To do: donde se colocan las tareas recién creadas y aun nadie se ha puesto a trabajar en ellas.
  • In progress: cuando se empieza a realizar una tarea se mueve la tarea de la columna To do a In progress.
  • Done: cuando se completa una tarea satisfactoriamente, la tarea se mueve de In progress a Done.
  • Incidencias: tareas con problemas de código encontrados en la realización del proyecto, una vez que se han solucionado se cierran y se mueven a la columna Done.
  • Dropped: tareas que por algun motivo no se han completado, pero se ha invertido un tiempo significativo en estas y en la que hay pequeños cambios, se dejan en esta columna para dejar constancia de nuestro trabajo, aunque no haya llevado a ninguna parte.

Las tareas deben tener la máxima información posible en su body sobre su descripción, y comentarios si hace falta por parte del realizador de la tarea si hay que puntualizar en algunos aspectos de la tarea.

Las etiquetas para nuestras tareas son las siguientes:

  • low priority: para tareas con baja prioridad.
  • medium priority: para tareas con prioridad media.
  • high priority: para tareas con prioridad alta.
  • critical priority: para tareas muy importantes sin las cuales no podemos cerrar el proyecto.
  • enhacement: incremento funcional (para tareas de código como nuevas características o tests)
  • documentation: para tareas de documentación.
  • bug: para tareas de incidencias.
  • continuous integration: para tareas de integración con Travis.
  • deployment: para tareas con Heroku.

3 . GESTIÓN DE LAS INCIDENCIAS

Las incidencias en nuestro proyecto pueden surgir por el desarrollo del subsistema votación, de la integración con otros sistemas, depuración o refactorización del código. El proceso de incidencia sigue estos pasos:

  1. Identificación de la incidencia.
  2. Documentar la incidencia lo máximo que se pueda con informes de error y posibles causas.
  3. Evolución de la incidencia.
  4. Cierre de la incidencia.

  • Cuando un usuario encuentra una incidencia, lo primero que debe hacer es dejar constancia de la misma abriendo una tarea en la columna Incidencias, aportando documentación y posibles causas por las que dicha incidencia ocurre. Luego esa incidencia es asignada al usuario o usuarios responsables y se marca una prioridad que puede ser baja, media o alta, teniendo mayor preferencia aquellas incidencias con una etiqueta de prioridad alta, y una preferencia mas baja aquellas incidencias con una etiqueta de prioridad baja. Ademas se marca también con la etiqueta _bug _si es un problema de código.

  • Si durante el desarrollo de la incidencia surgen nuevos problemas, hay que ir comentándolo en la tarea de dicha incidencia, para dejar constancia y para que otros miembros del grupo vean los problemas y puedan ayudar en caso de que el usuario responsable no sea capaz de solucionar el error.

  • Una vez que la incidencia se ha solucionado, documentar que pasos se ha llevado a cabo para su solución por si en algún futuro le vuelve a ocurrir la misma incidencia a otro usuario que le sirva de apoyo y pueda completar la tarea mucho mas rápido. Mover dicha incidencia de la columna Incidencias a Done

  • Hacer referencia en el body de la incidencia, a que tarea corresponde dicha incidencia.