Diferencia entre revisiones de «Equipo de integración general - 17 18 - G2»

De Wiki de EGC
Saltar a: navegación, buscar
(Procedimiento general para la gestión de incidencias)
Línea 17: Línea 17:
 
Puede acceder a nuestro proyecto en Opera [http://opera.eii.us.es/egc/public/trabajo/ver/id/74 aquí]
 
Puede acceder a nuestro proyecto en Opera [http://opera.eii.us.es/egc/public/trabajo/ver/id/74 aquí]
  
== Formato para detallar tecnologías elegidas ==
+
== Formatos y procedimientos ==
 +
 
 +
=== Formato para detallar tecnologías elegidas ===
 
  '''Subsistema''': <Nombre del subsistema/equipo>
 
  '''Subsistema''': <Nombre del subsistema/equipo>
 
  '''Lenguaje/Herramienta''': <Lenguaje/herramienta escogida y versión>
 
  '''Lenguaje/Herramienta''': <Lenguaje/herramienta escogida y versión>
Línea 25: Línea 27:
 
  '''Necesita Base de datos''': <Sí/No> (En caso afirmativo explicar cuál se está empleando y su versión)
 
  '''Necesita Base de datos''': <Sí/No> (En caso afirmativo explicar cuál se está empleando y su versión)
  
== Formato general para detallar incidencias ==
+
=== Formato general para detallar incidencias ===
 
Las incidencias pueden emplearse no solo para fallos.
 
Las incidencias pueden emplearse no solo para fallos.
 
  '''Título''': <breve título sobre la incidencia>
 
  '''Título''': <breve título sobre la incidencia>
Línea 38: Línea 40:
 
     ''question'': (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión
 
     ''question'': (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión
  
== Procedimiento general para la gestión de incidencias ==
+
=== Procedimiento general para la gestión de incidencias ===
 
# Establecer a un miembro del equipo el rol de gestor de incidencias.
 
# Establecer a un miembro del equipo el rol de gestor de incidencias.
 
# Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
 
# Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.

Revisión del 20:06 27 nov 2017

Miembros

  • Gonzalo Delgado Chaves
  • Jesús Rivas Jiménez
  • Javier Sánchez Parra
  • Mohammed Alaoui Mhammedi
  • Roberto García Calero

Repositorio GitHub

El repositorio de GitHub del equipo será accesible aquí

Opera

Puede acceder a nuestro proyecto en Opera aquí

Formatos y procedimientos

Formato para detallar tecnologías elegidas

Subsistema: <Nombre del subsistema/equipo>
Lenguaje/Herramienta: <Lenguaje/herramienta escogida y versión>
Sistema de gestión de bibliotecas: <Herramienta que se usa para añadir bibliotecas/dependencias> (Ej: Java->Maven, Python->pip)
Bibliotecas: <Listado de bibliotecas usadas en el desarrollo.>
   Nombre_Biblioteca1: <versión>
Necesita Base de datos: <Sí/No> (En caso afirmativo explicar cuál se está empleando y su versión)

Formato general para detallar incidencias

Las incidencias pueden emplearse no solo para fallos.

Título: <breve título sobre la incidencia>
Prioridad: a seleccionar entre distintos valores: urgente, alto, medio, bajo.
Estado: pendiente, en curso, finalizado. Los dos primeros estados deberían meterse como etiquetas en GitHub, el último estado se prouduce cuando se cierra la incidencia en GitHub.
Descripción: <descripción detallada del error>
   La descripción puede incluir imagenes o la salida emitida por el fallo.
Etiquetas: <etiquetas de GitHub para clasificar las incidencias>
   enhancement: propuesta de mejora
   bug: fallos encontrados en el sistema
   help wanted: incidencia que puede ser resuelta por un miembro del equipo pero que ha sido atendida previamente por otro
   question: (a usar solo entre miembros del equipo) dudas sobre un commit en concreto, hay que referenciar el commit en cuestión

Procedimiento general para la gestión de incidencias

  1. Establecer a un miembro del equipo el rol de gestor de incidencias.
  2. Cuando se registre una incidencia, el gestor deberá evaluar la prioridad, asignar las etiquetas correspondientes (si faltasen) y un responsable de la incidencia.
  3. El responsable trabajará en la incidencia. Si un commit cierra una incidencia deberá incluir en el cuerpo del commit "Closes #<id de la incidencia>"

Las incidencias pueden incluirse en Proyectos de GitHub.

Estas diapositivas incluyen información complementaria: https://github.com/InnosoftDaysPresidencia/Presidencia/raw/master/GitHub/Gu%C3%ADa%20de%20GitHub%20Classroom.pdf