-
Notifications
You must be signed in to change notification settings - Fork 0
Información sobre Issues y tareas
Los Issues son una forma genérica de incidencias del proyecto. Pueden abrirse Issues para reportar bugs, para sugerir mejoras, para preguntar cómo hacer algo con el proyecto, etc.
Además, nosotros los usaremos para asignar y controlar las tareas definidas en la planificación.
##### Etiquetas
Las tareas llevarán siempre etiquetas especiales: La etiqueta Tarea o Reunión, dependiendo de si es una tarea individual o se corresponde con una reunión de todo el equipo; y una de las etiquetas No funcional, Modelo, Diseño, Lógica o Pruebas dependiendo del área al que pertenezca. Algunas tareas pueden no llevar ninguna de estas últimas etiquetas.
Los Issues de tareas se incluirán siempre dentro de un Milestone (hito) correspondiente al Sprint.
Las tareas sólo las creará el jefe de desarrollo (Rafa Vázquez), o la persona específica designada por él para ello.
Sólo la persona asignada a la tarea puede cerrar su tarea. En caso de que la tarea esté directamente relacionada con el desarrollo de código, se debe contar previamente con la aprobación del jefe de desarrollo mediante un Pull Request aceptado, referenciando en éste a la tarea. Una vez el jefe de desarrollo apruebe el resultado, la tarea se podrá cerrar.
Para referenciar una tarea desde un Pull Request, commit o comentario se pone el símbolo # seguido del número de la tarea. Ej: #1
##### Comentarios Cualquier miembro del equipo puede comentar en la tarea, incluida la persona asignada, para aportar información, opinar o reportar sobre el estado actual de dicha tarea. No hay limitación en cuanto a los comentarios.
##### Visualización En la interfaz de GitHub hay filtros para ver todas las recetas a las que se está asignado, o las tareas que faltan por completar para un Milestone (Sprint). Los miembros deberán revisar periódicamente las tareas pendientes, y asegurarse de que van cumpliendo las suyas en cuanto les sea posible por las dependencias.
Ojo con el filtro de Milestones, que no se desactiva solo, hay que quitarlo a conciencia. Si no, no aparecerán las tareas externas a ese Milestone.
Cualquier miembro del equipo puede crear otros Issues siempre que no sean tareas. Por ejemplo, se puede crear un Issue para reportar un bug que se ha encontrado a posteriori, se puede crear un Issue para comentar y discutir una idea que se tenga para mejorar la aplicación, que puede entrar en la planificación del siguiente Sprint.
Estos Issues se deben marcar con la etiqueta correspondiente. Ya hay etiquetas predefinidas para tipos comunes de Issues como bug, enhancement o question. Si ninguna etiqueta se ajusta al tipo de Issue que se desea crear, se puede proponer al jefe de desarrollo introducir una nueva etiqueta.
##### Cierre El jefe de desarrollo se encargará de cerrar los Issues cuando sea conveniente.