💻TIC – Infraestructura y soporte técnico

1. Revisión de entregables previstos

El equipo facilitador recordó que el proyecto debe avanzar con lógica de Producto Mínimo Viable (MVP) para evitar bloqueos. Se revisaron los entregables iniciales: propuesta de infraestructura, MVP técnico, estimación de recursos y protocolos de mantenimiento. Se acordó afinar detalles y cerrar esta documentación en próximas sesiones técnicas.

2. Condiciones del despliegue

Se presentó el nombre provisional de la plataforma: Ágora, actualmente en proceso de validación por el área de Comunicación. Se trabaja sobre la posibilidad de avanzar inicialmente con el dominio agora.ehu.eus y un entorno de pruebas asociado, froga.agora.ehu.eus. siempre que la normativa interna lo permita. El equipo técnico de la EHU, responsable de garantizar la coherencia en la asignación y estructura de los nombres de dominio, revisará las condiciones y procedimientos para los subdominios y comunicará los pasos a seguir una vez confirmados, todo ello a la espera de que el equipo de Comunicación avance en los aspectos relacionados con la identidad, el nombre definitivo y la coherencia institucional del dominio.

3. Infraestructura: modalidad de instalación

Se revisaron las distintas opciones para el despliegue técnico, analizando tanto la instalación en servidores propios de la EHU como la opción en modalidad SaaS. Aunque inicialmente se consideró avanzar hacia un despliegue on‑premise, se identificaron necesidades adicionales de análisis técnico, dimensionamiento y disponibilidad de recursos que podrían ralentizar el inicio del proyecto.

Con el fin de asegurar una puesta en marcha ágil y evitar bloqueos en esta fase inicial, se decidió desplegar EHUagora en modalidad SaaS de forma provisional. Este enfoque permitirá comenzar a trabajar con la plataforma mientras se completa el estudio detallado para valorar, en una fase posterior, una posible migración a servidores propios.

El equipo técnico explicó que su despliegue habitual se basa en Docker, incluyendo Postgres y Redis, y que la arquitectura podría adaptarse fácilmente si en el futuro se opta por una instalación propia. Se señaló la importancia de contar con una estimación precisa de cores y RAM para prever cargas de uso intensivo, como votaciones o procesos de participación muy concurridos.

4. Crecimiento y escalabilidad

El grupo destacó la importancia de que la plataforma pueda crecer sin bloqueos y responder a incrementos de uso. Se resumieron los elementos clave:

• Necesidad de una estimación precisa de recursos (cores, RAM y carga máxima), especialmente para momentos de alta participación como votaciones.

• El despliegue inicial en modalidad SaaS ofrece elasticidad y estabilidad mientras se completa el análisis para una posible migración futura a servidores propios.

• La arquitectura de Decidim (Docker, Postgres, Redis) es modular y escalable, permitiendo ampliar la infraestructura cuando sea necesario.

• Se identificaron escenarios de crecimiento que deberán revisarse más adelante: aumento de usuarios, cargas intensivas y costes de escalado.

En conjunto, se consideró que el modelo SaaS facilita iniciar el proyecto con garantías mientras se estudia la arquitectura definitiva.

5. Repositorio de código

Se acordó que la EHU tendrá un repositorio propio por motivos de soberanía tecnológica. Actualmente se prefiere GitLab, conforme a los usos internos. Sin embargo, dado que el despliegue inicial será en modalidad SaaS, se decidió posponer la decisión definitiva sobre si el repositorio estable se alojará en GitLab o GitHub hasta una fase posterior del proyecto, cuando se clarifique si habrá migración a servidores propios y cuál será el flujo técnico definitivo.

6. Autenticación y gestión de participantes

Se revisaron los métodos disponibles: LDAP, SAML, Izenpe, BAQ y OAuth. El grupo coincidió en que el acceso debe realizarse mediante las credenciales institucionales. Libo Revilla indicó que SAML es preferible por su robustez y facilidad técnica, y se comprometió a enviar las especificaciones necesarias.

En este punto se recuperó también la reflexión trabajada previamente en los documentos de participación sobre la frontera de datos: la universidad dispone de colectivos con credenciales activas pero con niveles de vinculación muy distintos, lo que impacta directamente en la calidad y fiabilidad de los datos para LDAP y otras integraciones.

Se discutió la definición de comunidad universitaria, distinguiendo entre colectivos plenamente reconocidos (PDI, PTGAS y estudiantado) y perfiles en la "frontera" (Ikerbasque, alumnado externo o casos excepcionales). Se señaló que algunos datos no son suficientemente fiables y requieren revisión. Además, se acordó que inicialmente se trabajará únicamente con las identidades que se encuentran dentro de la frontera de datos, es decir, aquellas cuya vinculación y fiabilidad están plenamente garantizadas para los sistemas de autenticación institucional.

7. Estimación de recursos técnicos

Se plantearon escenarios para mantenimiento, soporte y escalabilidad. Se discutió la posibilidad de que, en un futuro, la EHU pudiera contribuir al core de Decidim, aunque actualmente los equipos internos no trabajan con Ruby y este enfoque debería ser planteado más a medio-largo plazo.

8. Temas pendientes

Los temas que permanecen abiertos y que deben desarrollarse con base en los documentos de referencia del proyecto (orden del día TECH, documentación funcional, experiencias previas y marco de participación) son los siguientes:

8.1 Activación del grupo de trabajo para integrar LDAP con Decidim

• Puesta en marcha formal del grupo técnico responsable de definir e implementar la autenticación institucional en EHUagora.

• Revisión de atributos disponibles en LDAP/SAML, alineados con los criterios recogidos en los documentos de participación sobre “frontera de datos” y definición operativa de «comunidad universitaria».

• Evaluación del mecanismo de alta inicial, metadatos mínimos y posibles necesidades de importación programada de cuentas, tal como se detalla en el orden del día del grupo TECH.

8.2 Validación del nombre de dominio

• El equipo de Comunicación y el equipo técnico deberán validar conjuntamente la idoneidad del nombre agora.ehu.eus, asegurando coherencia institucional y consistencia con la identidad digital de la universidad.

• La aprobación es necesaria para activar el mecanismo interno de verificación de dominios y avanzar en su asignación formal.

• Esta validación se enmarca en las prácticas descritas en el documento de Marco de Despliegue y en la necesidad de unificar criterios para futuros espacios participativos.

8.3 Documento de protocolo del servicio SaaS

El documento deberá incorporar, ampliando lo previsto en el orden del día y la documentación técnica:

• Mantenimiento evolutivo, preventivo y correctivo.

• Modelo de soporte interno: Nivel 1 (Komunikatik) y Nivel 2 (equipo técnico especializado), con sus protocolos de escalado.

• Seguridad y monitorización: cifrado HTTPS, logs auditables, copias de seguridad diarias, protocolos ante incidentes y responsables.

• Integración de servicios de terceros necesarios (analítica, geolocalización, votación segura, verificación…), recogidos en los documentos de necesidades funcionales.

• Gestión de credenciales, roles administradores y trazabilidad de acciones.

• Actualizaciones, control de cambios y reglas de versión.

• Procedimientos de contingenci