OpenSlides 4.3 en colegios: padrón, mociones y voto
Un caso para ordenar asambleas de colegios profesionales con OpenSlides: padrón, agenda, mociones, permisos, votación y respaldo verificable.
Una asamblea se desordena rápido cuando el padrón, las mociones y el conteo de votos viven en archivos separados. En un colegio profesional de Cuyo con 1.800 matriculados, la credencial plastificada sirve para entrar, pero no explica quién puede votar, qué moción cambió ni qué acta queda al final. OpenSlides ordena esa sesión si se configura con roles, agenda, respaldo y prueba previa. ## Dónde aparece el incidente OpenSlides publicó la versión 4.3.0 el 2 de junio de 2026. Su README lo define como un sistema web para gestionar y proyectar agenda, mociones y elecciones de una asamblea. Esa frase alcanza para ubicar el caso: colegios, cámaras y asociaciones que ya tienen reuniones formales, pero todavía cierran con planillas y conteo manual. La documentación de instalación indica uso de Docker y Docker Compose, y registra que OpenSlides 4.3 actualiza PostgreSQL de 15 a 17. Ese dato corrige una suposición frecuente: una asamblea digital no es solo una pantalla para votar; también es una base con usuarios, permisos, mociones, archivos y rastros que deben volver después de un corte. El antagonista es la versión impresa de la moción. Una hoja cambia durante el cuarto intermedio, otra queda en la mesa de acreditación y la comisión revisora recibe dos textos parecidos. Cuando alguien pide el historial, la secretaria tiene que unir credenciales, firmas, votos y acta.
Cómo funciona por dentro
El flujo empieza antes de la asamblea. Administración importa padrón, matrícula, estado habilitado, grupo y correo. Luego carga agenda, mociones, listas de oradores, candidatos y documentos. Cada participante entra con usuario propio o recibe credencial temporal. La mesa define quién puede ver, hablar, proponer, votar o administrar. OpenSlides guarda reuniones, usuarios, grupos, agenda, mociones, elecciones, archivos y resultados. El componente de voto procesa la elección o moción. El proyector muestra agenda, lista de oradores, texto vigente y resultado. PostgreSQL guarda el estado de la aplicación. Redis y servicios internos sostienen sesiones, actualizaciones y comunicación entre módulos según el despliegue. Los permisos son el punto que decide la calidad del sistema. Un matriculado activo vota. Un invitado lee agenda. Secretaría carga documentos. La junta electoral administra votaciones. La comisión directiva consulta reportes. Un técnico opera proyección sin editar padrón ni resultados. La acreditación necesita su propio cierre. El sistema debe marcar presente, ausente, habilitado para votar y observado. Ese estado evita discutir al final si una persona entró tarde, votó por error o quedó registrada con matrícula vencida. El changelog de OpenSlides muestra mejoras sostenidas en participantes, permisos, mociones, elecciones, listas de oradores y voto delegado. Para una institución local, esa historia de producto importa porque la herramienta ya nació alrededor de asambleas, no de encuestas genéricas.
Qué se instala o configura primero
La pila inicial usa OpenSlides 4.3, Docker Compose, PostgreSQL 17, dominio con HTTPS, correo, backup de base, copia de archivos y roles por grupo. El primer entregable verificable es una asamblea de prueba con veinte usuarios, dos mociones, una elección, lista de oradores y acta exportada. Con tipo de cambio oficial vendedor de referencia a ARS 1.453 por dólar consultado el 16 de junio, un servidor de USD 35 a 80 mensuales queda entre ARS 50.855 y ARS 116.240. El piloto demanda 32 a 56 horas: instalación, padrón de prueba, grupos, agenda, plantilla de mociones, prueba de voto, respaldo y simulacro de recuperación. UMSA puede acompañar un primer evento sin prometer una asamblea perfecta. El objetivo operativo es más medible: que cada persona habilitada tenga un estado, que cada moción tenga versión vigente, que cada voto tenga cierre y que cada archivo pueda abrirse después.
Dónde se rompe y cómo probarlo
El primer riesgo es un padrón sucio. La señal aparece cuando una matrícula inactiva puede votar o cuando una persona activa queda afuera. La prueba importa padrón con altas, bajas y duplicados, luego verifica quién entra y quién recibe rechazo. El segundo riesgo es una moción sin versión vigente. La señal aparece cuando el texto proyectado y el PDF descargado no coinciden. La prueba modifica una moción, registra motivo y confirma que la vista pública muestre el texto correcto. El tercer riesgo es una votación sin corte claro. La señal aparece cuando la mesa declara cierre y siguen entrando votos. La prueba abre, cierra y bloquea una elección de ensayo, con usuario testigo y registro de hora. El cuarto riesgo es depender de internet del salón. La prueba corta conectividad externa, mantiene red local si el despliegue lo permite y verifica qué pantallas siguen disponibles. Si todo cae, el plan B debe decir quién imprime padrón, quién toma votos y cómo se carga el resultado. El quinto riesgo es una copia incompleta. La guía de instalación incluye comandos de dump y restauración de PostgreSQL. La prueba toma un dump, levanta el sistema en otro host, abre agenda, mociones, usuarios y resultados. La asamblea termina cuando el acta puede reconstruirse sin pedir favores a la memoria de nadie.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.