Diferencia entre revisiones de «Gestión de integración con redes sociales - 17 18 - G2»

De Wiki de EGC
Saltar a: navegación, buscar
(Ramas (branches))
Línea 74: Línea 74:
 
=== Ramas (branches) ===
 
=== Ramas (branches) ===
 
Disponemos de nueve ramas:
 
Disponemos de nueve ramas:
# Una rama por cada red social, donde se implementará la funcionalidad de cada una por separado.
+
# Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
# Una rama '''develop''' que integre todas las funcionalidades de las redes sociales.
+
# Una rama '''develop''' que integre todas las funcionalidades implementadas.
 
# Una rama principal o '''master''' para los entregables.
 
# Una rama principal o '''master''' para los entregables.
 
# Una rama '''hotfix''' para errores detectados en producción.
 
# Una rama '''hotfix''' para errores detectados en producción.
  
 
[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]
 
[[Archivo:Ramas-integracion-rrss.png|723px|thumb|center|Ramas|link=https://1984.lsi.us.es/wiki-egc/images/egc/3/31/Ramas-integracion-rrss.png]]

Revisión del 21:16 25 dic 2017

Miembros

  • Luis Miguel García (coordinador)
  • Carlos Ruano
  • Daniel Martínez
  • Alberto Gómez
  • Cristian Galán
  • Juan Huerta

Objetivos del subsistema

Crear un plugin para WordPress para integrar varias redes sociales en el sistema, que permita mejorar la visibilidad de éste y fomentar la interacción con los usuarios. Por otro lado, se van a integrar seis redes sociales: Twitter, Reddit, Facebook, Instagram, Google+ y LinkedIn. Los usuarios podrán compartir contenido personalizado en sus redes sociales o seguir a los perfiles oficiales. Por último, se integrarán widgets que muestren las últimas publicaciones realizadas en redes sociales (últimos tweets, publicaciones en Facebook…).

Repositorio

Disponemos de un repositorio en GitHub.

Gestión de incidencias (issues)

Procedimiento

Un miembro del equipo será el encargado de canalizar todas las incidencias que se registren. Cuando se encuentre un error o surja una petición de cambio, se seguirá unos pasos:

  1. Se registrará la incidencia en GitHub con el formato adecuado y las etiquetas que correspondan, que se explicará a continuación.
  2. Cuando se registre una incidencia, el encargado de gestionar las incidencias deberá asignar a un responsable, la asociará con un milestone y añadirá más etiquetas si fuera pertinente.
  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>".

Nota: se deben añadir comentarios a la incidencia que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

Formato

Se seguirá el formato propuesto por el equipo de integración con algunas modificaciones.

Plantilla para issues

Etiquetas (labels)

Existen diferentes tipos:

  1. Etiquetas de estado:
    1. pending: aún no ha sido atendida por el encargado de gestionar las incidencias.
    2. in progress: se ha asignado a un responsable para solucionar la incidencia.
    3. finished: ya ha sido resuelta.
  2. Etiquetas de tipo:
    1. enhancement: propuesta de mejora.
    2. bug: fallos encontrados en el sistema.
    3. help wanted: incidencia que puede ser resuelta por un miembro del equipo, pero que ha sido atendida previamente por otro.
    4. question: a usar sólo entre miembros del equipo para dudas sobre un commit. Éste debe ser referenciado en la descripción.
    5. new functionality request: para solicitar formalmente una nueva funcionalidad en el sistema.
    6. duplicate: cuando la incidencia está duplicada. Se debe referenciar a la indecencia original.
    7. invalid: cuando la incidencia no cumpla con el formato propuesto.
    8. wontfix: cuando se ha decidido no darle una solución a la incidencia por alguna razón que debe ser explicada en los comentarios.

Además, cada red social tiene su propia etiqueta.

Gestión de tareas

Habrá un encargado de crear las tareas. Para gestionar las tareas, se utilizará el kanban de GitHub. Para ello, se ha creado un proyecto.

La persona encargada de una tarea lo único que tendrá que hacer es ir moviéndola por los diferentes estados que pueda estar ésta: TO DO, IN PROGRESS y DONE.

Nota: se deben añadir comentarios a la tarea que permitan seguir una traza de la evolución de la misma y las decisiones tomadas.

Gestión del código

Commits

Se seguriá el formato propuesto por el equipo de integración.

<tipo>: <título del commit>
(espacio)
<cuerpo del commit>
(espacio)
Closes #<número de la incidencia/tarea en GitHub>

Ejemplo:

fix: redirección errónea tras hacer like

Después de que el usuario haga clic en el botón like de Facebook, éste no era redireccionado a la ventana de login. Ahora el usuario es redireccionado a esta ventana.

Closes #5

Ramas (branches)

Disponemos de nueve ramas:

  1. Una rama por cada desarrollador, donde se implementará la funcionalidad asignada a cada uno.
  2. Una rama develop que integre todas las funcionalidades implementadas.
  3. Una rama principal o master para los entregables.
  4. Una rama hotfix para errores detectados en producción.
Ramas