Salles multijoueur

Nouveau dans la v2.7.0

Les salles multijoueur transforment l'annotation, tâche solitaire, en séance partagée et en direct. Un groupe d'annotateurs travaille sur le même élément au même moment, la dynamique de groupe étant mesurée et pas seulement rendue possible. Aucun LLM, aucun service externe, aucune nouvelle dépendance.

Trois types de salle :

L'intérêt des salles de normalisation

Les équipes d'annotation tiennent déjà des réunions de normalisation en partage d'écran, et le résultat finit dans les notes de quelqu'un. Les salles font de cette séance une partie de l'outil et l'instrumentent.

• L'aveugle d'abord. Avant la révélation, les membres voient qui a voté, jamais quoi. C'est appliqué côté serveur, donc les premières impressions sont réellement indépendantes.
• La révélation est une mesure. Les votes à l'aveugle deviennent immuables une fois révélés. Chaque changement postérieur à la révélation est enregistré avec le vote de départ, le vote d'arrivée et la majorité du moment, ce qui vous donne un relevé de conformité par membre.
• L'indicateur d'α répond à « est-ce que ça valait le coup ? » L'α de Krippendorff est calculé deux fois sur les éléments révélés : sur les votes à l'aveugle, et sur les votes actuels. L'écart mesure le gain de normalisation de la séance, à l'écran pendant qu'elle se déroule.

Configuration

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

Les salles votent sur un seul schéma à choix unique (radio ou likert). Si schema n'est pas défini, le premier schéma de ce type dans annotation_schemes est utilisé.

Mener une séance

1. Démarrez le serveur, connectez-vous et ouvrez /rooms.
2. Créez une salle (type et nombre d'éléments). Elle reçoit un code de six lettres comme MKT4QP. Les codes évitent les glyphes ambigus pour que vous puissiez les lire à voix haute.
3. Les autres rejoignent depuis la liste du hall, ou en ouvrant /rooms/<CODE>.
4. On vote, l'hôte révèle, on discute dans le chat latéral, on change de vote si l'on est convaincu, puis l'hôte avance. Après le dernier élément, la salle se ferme sur un récapitulatif de séance, et l'hôte peut télécharger le journal complet des événements.

Huddles

Choisir Huddle à la création remplit la salle avec tous les éléments sur lesquels les annotateurs sont actuellement en désaccord pour le schéma de la salle, jusqu'à 200. Les annotations d'origine apparaissent au-dessus du panneau de vote, en contexte. Les désaccords sont calculés en direct à partir de l'état d'annotation, il n'est donc pas nécessaire d'activer le sous-système d'arbitrage.

Séances Shadow

Dans une salle shadow, tout le monde sauf l'hôte entre comme observateur. Les observateurs ne peuvent pas voter, mais ils voient les votes, les révélations et les sélections de texte de l'hôte avec environ 1,5 seconde de latence. La sélection courante de l'hôte est surlignée en ambre sur l'écran des observateurs.

Persistance et reprise après incident

Chaque salle repose sur un journal d'événements. Chaque mutation (rejoindre, voter, révéler, changer, message, avancer, fermer) ajoute une ligne JSON à :

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

L'état de la salle est un pur rejeu de ce journal, si bien que les salles en cours survivent à un redémarrage du serveur. Le journal sert aussi de piste d'audit de la séance : votes à l'aveugle, horodatages, discussion, et chaque changement postérieur à la révélation avec son contexte de majorité. GET /rooms/api/<CODE>/export (hôte ou administrateur) renvoie le journal et les métriques calculées en JSON.

Avec persist_votes: true (la valeur par défaut), le vote final de chaque membre sur un élément révélé est écrit dans son état d'annotation habituel lorsque l'hôte avance. Le travail fait en salle compte comme de vraies annotations et alimente tous les chemins d'export existants.

Les clients se synchronisent en sondant /events avec un curseur. Il n'y a pas de WebSockets, donc les salles fonctionnent aussi bien sous le serveur de développement multithread que sous n'importe quel déploiement WSGI.

Récapitulatif de l'API

Pour aller plus loin

• Psychométrie — aptitude par annotateur et difficulté par élément ; les salles sont l'endroit où l'on corrige les problèmes de livre de codes qu'elle signale
• Arbitrage et résolution du désaccord — la contrepartie asynchrone des huddles
• Rédiger des consignes d'annotation
• Documentation source