Salas multijugador

Nuevo en v2.7.0

Las salas multijugador convierten la anotación de una tarea solitaria en una sesión compartida y en directo. Un grupo de anotadores trabaja sobre el mismo elemento a la vez, con la dinámica social medida y no solo permitida. Sin LLM, sin servicios externos y sin dependencias nuevas.

Tres tipos de sala:

Para qué sirven las salas de normalización

Los equipos de anotación ya hacen reuniones de normalización por pantalla compartida, y el resultado acaba en los apuntes de alguien. Las salas convierten esa sesión en parte de la herramienta y la instrumentan.

• Primero a ciegas. Antes de la revelación, los miembros ven quién ha votado pero nunca qué. Esto se aplica en el servidor, así que las primeras impresiones son de verdad independientes.
• La revelación es una medición. Los votos a ciegas quedan inmutables una vez revelados. Cada cambio posterior a la revelación se registra con el voto de partida, el voto de llegada y cuál era la mayoría en ese momento, lo que te da un registro de conformidad por miembro.
• El medidor de α responde a "¿ha valido la pena?" El α de Krippendorff se calcula dos veces sobre los elementos revelados: con los votos a ciegas y con los votos actuales. La diferencia es la mejora que aporta la sesión, en pantalla mientras ocurre.

Configuración

rooms:
  enabled: true
  who_can_create: any      # "any" logged-in user, or "admin" only
  persist_votes: true      # final votes write into members' annotation state
  poll_interval_ms: 1500   # client sync cadence (500–30000)
  max_members: 12          # per room (2–100)
  schema: sarcasm          # optional; defaults to the first radio/likert scheme

Las salas votan sobre un único esquema de opción simple (radio o likert). Si no defines schema, se usa el primer esquema de ese tipo que haya en annotation_schemes.

Cómo llevar una sesión

1. Arranca el servidor, inicia sesión y abre /rooms.
2. Crea una sala (tipo y número de elementos). Recibe un código de seis letras como MKT4QP. Los códigos evitan glifos ambiguos para que puedas leerlos en voz alta.
3. El resto se une desde la lista del vestíbulo o abriendo /rooms/<CODE>.
4. Se vota, el anfitrión revela, se discute en el chat lateral, se cambia el voto si alguien te convence y el anfitrión avanza. Tras el último elemento la sala se cierra con un resumen de la sesión, y el anfitrión puede descargar el registro completo de eventos.

Huddles

Elegir Huddle al crear la sala la llena con todos los elementos en los que los anotadores discrepan actualmente según el esquema de la sala, hasta 200. Las anotaciones originales aparecen sobre el panel de votación como contexto. Las discrepancias se calculan en vivo a partir del estado de anotación, así que no hace falta activar el subsistema de adjudicación.

Sesiones Shadow

En una sala shadow todo el mundo entra como observador salvo el anfitrión. Los observadores no pueden votar, pero ven los votos, las revelaciones y las selecciones de texto del anfitrión con alrededor de 1,5 segundos de latencia. La selección actual del anfitrión se resalta en ámbar en la pantalla de los observadores.

Persistencia y recuperación ante caídas

Cada sala se basa en eventos. Cada mutación (entrar, votar, revelar, cambiar, mensaje, avanzar, cerrar) añade una línea JSON a:

<output_annotation_dir>/rooms/room-<CODE>.jsonl

El estado de la sala es una reproducción pura de ese registro, así que las salas en curso sobreviven a un reinicio del servidor. El registro sirve además como pista de auditoría de la sesión: votos a ciegas, marcas de tiempo, discusión y cada cambio posterior a la revelación con su contexto de mayoría. GET /rooms/api/<CODE>/export (anfitrión o administrador) devuelve el registro junto con las métricas calculadas en JSON.

Con persist_votes: true (el valor por defecto), el voto final de cada miembro sobre un elemento revelado se escribe en su estado de anotación habitual cuando el anfitrión avanza. El trabajo hecho en la sala cuenta como anotaciones reales y entra en todas las rutas de exportación existentes.

Los clientes se sincronizan sondeando /events con un cursor. No hay WebSockets, así que las salas funcionan igual con el servidor de desarrollo multihilo que con cualquier despliegue WSGI.

Resumen de la API

Lecturas adicionales

• Psicometría — capacidad por anotador y dificultad por elemento; las salas son donde se arreglan los problemas de manual que esa página detecta
• Adjudicación y resolución del desacuerdo — la contraparte asíncrona de los huddles
• Cómo escribir directrices de anotación eficaces
• Documentación de origen