Agora Voting - Avanzar la interfaz pública de la votación

De Wiki de EGC
Saltar a: navegación, buscar

Descripción del proyecto

En Agora Voting, la interfaz gráfica que muestra la configuración de una votación (antes de que haya resultados) y los resultados (cuando son públicos) es demasiado básica. De cada opción de una pregunta, sólo muestra el título de cada opción, pero no muestra la imagen, url, descripción de la opción si es que los hubiera, y sólo hay un modo de visualización. Todo lo anterior podría mejorarse.

Enlace a la información del proyecto.

Aspectos organizativos

Miembros del equipo

Este grupo esta compuesto por los siguientes miembros:


Se puede acceder a la información relativa al grupo en el portal Ópera en este enlace

Descripción del entorno de desarrollo

El equipo de desarrollo trabajará en una máquina virtual optimizada para VMWare, con sistema operativo Ubuntu 16.04.1 LTS. A la máquina virtual se le asignarán al menos 5500 MB de memoria RAM y dos procesadores. Esta tiene instalada todas las herramientas necesarias para trabajar con el proyecto de Agora Voting desplegado en desarrollo. De esta manera, nuestra máquina virtual corre tres máquinas virtuales en Vagrant, herramienta que ofrece entornos de desarrollo virtualizados, y que corre, en nuestro caso, sobre VirtualBox.

Para el desarrollo, utilizaremos la herramienta Visual Studio Code. Accederemos al código de Agora Voting por medio de SSH gracias a Vagrant, y posteriormente por medio de una carpeta compartida entre la máquina de Vagrant y la anfitriona, desde la cual desarrollaremos directamente desde Visual Studio Code. Para efectuar los cambios, será necesario compilar el código del proyecto por medio del fichero build.sh.

Versiones del software principal que usamos en nuestra máquina virtual:

  • VirtualBox 5.0.24
  • Vagrant 1.8.1
  • Visual Studio Code 1.7.1

Gestión de código

Para el desarrollo del trabajo se ha creado una Organización en Github

Esta organizacion contiene los fork de los repositorios de Agora Voting relacionados con la interfaz gráfica.

Gestión de la comunicación

El gestionará la comunicación de la siguiente forma:

  • Grupo de Whatsapp: se usará para convocar al grupo a reuniones y cuestiones menores de gestión.
  • Canal de Slack: será el medio de comunicación escrita cuando el grupo esté trabajando en el desarrollo del proyecto. Asimismo, Slack será usado cuando sea necesario compartir alguna porción de código fuente.
  • Hangouts: se realizarán llamadas para para efectuar las reuniones del grupo, ya sea para cuestiones de gestión o desarrollo del proyecto.
  • De forma presencial: el grupo se podrá reunir de manera presencial para cuestiones cuya trascendencia lo requiera.

Con esta estrategia de comunicación se espera que la comunicación en el grupo fluya de forma adecuada, puesto que se ha definido correctamente en qué casos se debe usar cada canal. Todos los miembros del grupo estarán siempre al corriente de las decisiones tomadas.

Gestión de incidencias

Para la gestión de incidencias se usarán las issues de Github.

Dado que nuestro proyecto no depende exclusivamente de los desarrolladores del mismo, si no de Agora Voting, vamos a diferenciar dos tipos de incidencias:

  • Incidencias internas: serán aquellas que surjan dentro del alcance definido del proyecto de desarrollo.
  • Incidencias externas: aquellas incidencias ajenas al alcance de este proyecto, es decir, cualquier incidencia que no tenga nada que ver con la mejora de la interfaz de usuario, habiendo sido heredada de Agora Voting.


Incidencias internas

En primer lugar, describiremos cómo vamos a gestionar las incidencias internas.

Se usará la funcionalidad de issues que GitHub provee para llevar a cabo la gestión de las mismas. Las issues serán creadas en el repositorio que esté relacionado en mayor medida con la incidencia. En caso de que este no sea identificable, las issues se gestionan dentro del repositorio de agora-gui-elections.

Las issues se podrán catalogar de distintas formas:

  • Bug: indica que se ha encontrado un fallo que afecta a la correcta funcionalidad de la aplicación.
  • Help wanted: indica que se necesita ayuda para resolver algún bug o para cumplir un milestone.
  • Enhancement: indica que en esa issue se propondrá una mejora.
  • Question: indica que la issue contiene una pregunta que debe ser resuelta.

Las issues generadas por el equipo de desarrollo tendrán el siguiente ciclo de vida:

  • Serán abiertas por uno de los miembros del equipo de desarrollo.
  • A la incidencia se la catalogará de alguna de las formas descritas anteriormente, mediante la asignación de labels. También, en la medida de lo posible, se asignará la issue a un milestone.
  • El equipo de desarrollo discutirá y valorará si la incidencia está lo suficientemente bien descrita, y si realmente es relevante dentro del alcance del proyecto. Si la issue no pasa este proceso, se pedirá en la misma o bien mayor información, en cuyo caso se etiquetará con la tag “needs-info”, o bien se cerrará de forma inmediata (“wont-fix”). En caso de que la issue esté clasificada como un bug, será obligatorio que algún miembro del equipo verifique que existe tal incidencia. Si una vez verificada, se comprueba que no existe tal incidencia, será cerrada, con el label “works-for-me”.
  • Si la issue ha sido aceptada, el equipo de desarrollo tratará de resolver la incidencia. Las issues aceptadas tendrán la etiqueta “accepted”. Si se trata de algo relativamente sencillo y concreto, se asignará a un único miembro del equipo. De lo contrario, se implicará a más de un miembro a resolver la misma.
  • Una vez resuelta una incidencia, es posible que necesite ser testeada, en cuyo caso será etiquetada con la etiqueta “needs-test”. Una vez que se haya comprobado que la incidencia ha sido resuelta, se procederá a hacer un commit, en cuyo caso la incidencia será cerrada. Las issues que han sido resueltas de forma satisfactoria, se etiquetarán como “fixed”.


Incidencias externas

Pasamos a describir ahora cómo vamos a gestionar las incidencias externas.

Para este tipo de incidencias volveremos a usar la funcionalidad de issues de GitHub, pero dichas incidencias serán creadas en el repositorio agora-dev-box, repositorio que pertenece al equipo de Agora Voting.

Dichas incidencias serán catalogadas en función del sistema de etiquetas que siga el equipo de desarrollo de Agora Voting. Y además, serán descritas de la misma forma que las internas, que será detallada a continuación.

A partir de este momento la gestión de dicha incidencia y su ciclo de vida pasa a formar parte del equipo de desarrollo de Agora Voting.


Descripción de incidencias

Descripción de una issue:

  • Debe contener una alta cantidad de detalles.
    • Se debe dar información suficiente para poder reproducir el fallo
    • Se debe exponer la salida esperada y la respuesta obtenida.
    • Se debe detallar información tales como las versiones que se está usando, sistema operativo, etc.
    • Otra información como snippet de código, del que se cree que puede venir la incidencia, ficheros que pueden estar involucrados, o traza del error
    • Se deben evitar ambigüedades.
  • No se debe crear una issue, si ya se reportó anteriormente.

Gestión de tareas

El equipo anteriormente descrito utilizará un tablero de Trello para gestionar las tareas. El tablero en cuestión es el siguiente: https://trello.com/b/6fCAIWso/trabajo-egc El tablero se compone de seis listas:

  • Not planned yet: contendrá las tareas que se han detectado pero aún no han sido planificadas.
  • To Do: tareas planeadas que no han sido comenzadas.
  • Working in progress: toda tarjeta contenida en esta lista, estará siendo ejecutada por al menos un miembro del equipo.
  • In review: las tarjetas añadidas a la lista de revisión, están pendientes de ser revisada por el equipo o algún miembro en concreto.
  • Done: es la lista de tareas que han sido finalizadas.
  • Locked: contiene aquellas tareas planeadas o no planeadas, en la que en algún momento de su ciclo de vida se detectó la imposibilidad o no necesidad de llevarla a cabo.

También se usará la herramienta Toggl para gestionar el tiempo invertido en las tareas del proyecto.

Documentación y entregables

Actas de reuniones

Diario de grupo

Obtenido de «https://1984.lsi.us.es/wiki-egc/index.php?title=Agora_Voting_-_Avanzar_la_interfaz_pública_de_la_votación&oldid=5610»