[Reunión Equipo] Acuerdos adoptados generales - Arquisoft/radarin_es3a GitHub Wiki

Geolocalización almacenada en los Pods

Se tiene en cuenta la posibilidad de guardar la información de geolocalización de cada usuario de forma continuada en su Pod, haciendo su ubicación revisable en tiempo real por el resto de usuarios. Se desestima en favor de guardar información cada X intervalo de tiempo, pudiendo un usuario actualizar manualmente en cualquier momento (evita tiempos de carga más grandes, y saturación de información). Pendiente de posterior revisión, la carga de datos directamente en los Pods puede seguir siendo excesiva.

Tipo de log in

Posibilidad de emplear usuario y contraseña frente a posibilidad de manejar un log in a través del WebID de un usuario. En favor de la arquitectura de Solid, se favorece la idea de usar WebId.

React vs Angular

Se comenta la posibilidad de emplear React o Angular para el desarrollo del proyecto. Teniendo en cuenta el desconocimiento de ambas herramientas, pero tomando en consideración un mayor apoyo del profesorado hacia React y su marco de trabajo más similar a herramientas empleadas por varios miembros del equipo con anterioridad, se decide emplear React.

React.js vs React Native

Se toma en consideración el empleo de React.js frente a React Native, descartando el último al decidir realizar el proyecto con un sistema web tan solo (sin desarrollar una aplicación móvil per se). Esta decisión está motivada por la falta de experiencia de la mayoría de miembros del equipo con el desarrollo de aplicaciones móviles.

Sistema de cuentas

Se comenta la posibilidad de mantener un servidor para la aplicación web donde se almacene de forma somera información del registro de usuarios y su lista de amigos, con tal de que cada usuario pueda hacer log in en el sistema desde cualquier dispositivo sin sufrir un reseteo de datos. Se contrasta con la posibilidad de almacenar la información de los amigos agregados en el Pod de cada usuario, accediendo la aplicación a dicha información en el momento necesario. El debate sigue abierto a fecha de redacción.

Trabajo con GitHub e issues

Se acuerda la creación de un mayor número de issues, reflejando un espectro mayor de actividades llevadas a cabo y pendientes de hacer, con el fin de tener una mejor trazabilidad del trabajo realizado.

Manejo de ramas en Git

Se acuerda no tocar la rama "master" hasta que todo el equipo se haya reunido, y acordado hacerlo bajo revisión. Se trabajará principalmente en la rama "develop", empleando subramas para los cambios que cada miembro del equipo necesite incluir.