Diferencia entre revisiones de «Gestión de integración con redes sociales - 17 18 - G1»
Línea 55: | Línea 55: | ||
Para la etapa de pruebas e integración, montaremos en un contenedor Docker la pagina web del congreso junto con su base de datos. De esta forma, podremos probar en un entorno simulado el funcionamiento del plugin desarrollado a fin de obtener el mejor resultado posible. | Para la etapa de pruebas e integración, montaremos en un contenedor Docker la pagina web del congreso junto con su base de datos. De esta forma, podremos probar en un entorno simulado el funcionamiento del plugin desarrollado a fin de obtener el mejor resultado posible. | ||
+ | |||
+ | <h1><b>Protocolos</b></h1> | ||
+ | <h2><b>Formato de gestión de incidencias</b></h2> | ||
+ | El repositorio distribuido utilizado será GitHub, en el realizaremos toda la gestión de las incidencias. Se entiende por incidencia tanto incidencias, como cambios, como tareas que sean necesarias para llevar una correcta gestión de la planificación. | ||
+ | A continuación detallaremos el formato que se ha de seguir para la creación de issues: | ||
+ | <ol> | ||
+ | <li>Título</li> | ||
+ | <ul> | ||
+ | <li>Deberá aportar una información clara y concisa sobre el issue, sin exceder los 100 carácteres.</li> | ||
+ | </ul> | ||
+ | <li>Descripción</li> | ||
+ | <ol> | ||
+ | <li> Para tareas: </li> | ||
+ | <ul> | ||
+ | <li>Incluir información detallada sobre lo que debe hacerse para la finalización de la tarea. </li> | ||
+ | <li>Incluir el resultado o los resultados que se deben obtener tras la finalización de la misma. </li> | ||
+ | </ul> | ||
+ | <li> Para cambios: </li> | ||
+ | <ul> | ||
+ | <li>Incluir información detallada sobre la modificación que debe hacerse. </li> | ||
+ | <li>Nombrar mediante el @xxxxx a la persona que le afecte dicha modificación. </li> | ||
+ | <li>Incluir el resultado o los resultados que se deben obtener tras la finalización de la misma. </li> | ||
+ | </ul> | ||
+ | <li> Para issues/incidencias: </li> | ||
+ | <ul> | ||
+ | <li>Incluir información detallada sobre el bug encontrado. </li> | ||
+ | <li>Incluir los pasos para la reproducción del problema.</li> | ||
+ | <li>Incluir que se debería esperar y que se a obtenido.</li> | ||
+ | <li>Incluir la versión del producto que se ha usado.</li> | ||
+ | <li>Incluir información adicional que pueda resultar relevante para la identificación y corrección del error (Opcional).</li> | ||
+ | </ul> | ||
+ | </ol> | ||
+ | <li>Asignación de responsable</li> | ||
+ | <ul> | ||
+ | <li>Asignar un responsable por incidencia. En caso de que se considere necesario asignar varios responsables a una misma por su complejidad, deberá dividirse la incidencia en tantas incidencias como se consideren necesarias</li> | ||
+ | </ul> | ||
+ | |||
+ | </ol> |
Revisión del 16:06 9 dic 2017
Contenido
Miembros
- David Dominguez Vázquez
- Eusebio García Plasencia
- Hanna Cheikh Malaaynine
- Jorge García García
- Miguel Caraballo de la Rosa
Repositorio de GitHub
El repositorio de GitHub del equipo será accesible en este enlace Cualquier cambio o documentación importante añadida a él se notificará a los coordinadores en el momento.
Opera
El portal del proyecto en Opera será accesible en este enlace
Entorno
Para el desarrollo del plugin de redes sociales del Wordpress del congreso, usaremos:
Función | Nombre | Versión |
---|---|---|
Lenguaje | JavaScript | - |
Conexión | PHP | 7.1.7 |
Editor js | Visual Studio Code | 1.18.1 |
Base de datos | MySql | 4.7.0 |
Página Web | Wordpress | 4.8.4 |
Contenedor | Docker | 4.8.4 |
Plugin heredado | Simple Share Adder Buttons | 4.6 |
Para la etapa de pruebas e integración, montaremos en un contenedor Docker la pagina web del congreso junto con su base de datos. De esta forma, podremos probar en un entorno simulado el funcionamiento del plugin desarrollado a fin de obtener el mejor resultado posible.
Protocolos
Formato de gestión de incidencias
El repositorio distribuido utilizado será GitHub, en el realizaremos toda la gestión de las incidencias. Se entiende por incidencia tanto incidencias, como cambios, como tareas que sean necesarias para llevar una correcta gestión de la planificación. A continuación detallaremos el formato que se ha de seguir para la creación de issues:
- Título
- Deberá aportar una información clara y concisa sobre el issue, sin exceder los 100 carácteres.
- Descripción
- Para tareas:
- Incluir información detallada sobre lo que debe hacerse para la finalización de la tarea.
- Incluir el resultado o los resultados que se deben obtener tras la finalización de la misma.
- Para cambios:
- Incluir información detallada sobre la modificación que debe hacerse.
- Nombrar mediante el @xxxxx a la persona que le afecte dicha modificación.
- Incluir el resultado o los resultados que se deben obtener tras la finalización de la misma.
- Para issues/incidencias:
- Incluir información detallada sobre el bug encontrado.
- Incluir los pasos para la reproducción del problema.
- Incluir que se debería esperar y que se a obtenido.
- Incluir la versión del producto que se ha usado.
- Incluir información adicional que pueda resultar relevante para la identificación y corrección del error (Opcional).
- Asignación de responsable
- Asignar un responsable por incidencia. En caso de que se considere necesario asignar varios responsables a una misma por su complejidad, deberá dividirse la incidencia en tantas incidencias como se consideren necesarias