Skip to content

Stanze multiplayer

Conduci sessioni di norming e calibrazione dal vivo dentro Potato. Voti alla cieca, rivelazione da parte dell'host, discussione e un indicatore in tempo reale dell'alpha di Krippendorff che mostra quanto è valsa la sessione.

Novità della v2.7.0

Le stanze multiplayer trasformano l'annotazione da attività solitaria a sessione condivisa e dal vivo. Un gruppo di annotatori lavora sullo stesso elemento nello stesso momento, con le dinamiche sociali misurate e non soltanto rese possibili. Nessun LLM, nessun servizio esterno, nessuna nuova dipendenza.

Una stanza di norming dal vivo: voti alla cieca rivelati, un indicatore di accordo in tempo reale e un cambio di voto per conformità registrato.

Tre tipi di stanza:

TipoChe cosa succede
Norming (allineamento)Tutti votano alla cieca, l'host rivela, il gruppo discute e chiunque può cambiare il proprio voto. Un indicatore di accordo dal vivo confronta l'α alla cieca con l'α dopo la discussione.
Huddle (aggiudicazione)Percorre gli elementi su cui il tuo team è attualmente in disaccordo, mostrando come contesto le annotazioni originali di ciascuno. Una sessione di aggiudicazione dal vivo.
Shadow (osservazione)Chi è in formazione entra come osservatore e guarda l'host annotare in tempo reale, compresa la parte di testo che evidenzia.

Perché le stanze di norming

I team di annotazione fanno già riunioni di norming in condivisione schermo, e i risultati finiscono negli appunti di qualcuno. Le stanze rendono la sessione parte dello strumento e la strumentano.

  • Prima alla cieca. Prima della rivelazione i membri vedono chi ha votato ma mai che cosa. Il vincolo è applicato lato server, quindi le prime impressioni sono davvero indipendenti.
  • La rivelazione è una misurazione. I voti alla cieca diventano immutabili una volta rivelati. Ogni cambiamento successivo alla rivelazione viene registrato con il voto di partenza, quello di arrivo e quale fosse la maggioranza in quel momento, il che ti dà un registro di conformità per ciascun membro.
  • L'indicatore di α risponde a «ne è valsa la pena?» L'α di Krippendorff viene calcolato due volte sugli elementi rivelati: sui voti alla cieca e sui voti attuali. La differenza è il guadagno di allineamento della sessione, a schermo mentre accade.

Configurazione

yaml
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

Le stanze votano su un unico schema a scelta singola (radio o likert). Se schema non è impostato, viene usato il primo schema di questo tipo presente in annotation_schemes.

Condurre una sessione

  1. Avvia il server, accedi e apri /rooms.
  2. Crea una stanza (tipo e numero di elementi). Riceve un codice di sei lettere come MKT4QP. I codici evitano i glifi ambigui così puoi leggerli ad alta voce.
  3. Gli altri entrano dall'elenco della lobby, oppure aprendo /rooms/<CODE>.
  4. Si vota, l'host rivela, si discute nella chat laterale, si cambia voto se convinti e l'host avanza. Dopo l'ultimo elemento la stanza si chiude con un riepilogo della sessione, e l'host può scaricare il log completo degli eventi.

Huddle

Scegliere Huddle alla creazione riempie la stanza con tutti gli elementi su cui gli annotatori sono attualmente in disaccordo secondo lo schema della stanza, fino a 200. Le annotazioni originali compaiono sopra il pannello di voto come contesto. I disaccordi vengono calcolati dal vivo a partire dallo stato di annotazione, quindi non serve abilitare il sottosistema di aggiudicazione.

Sessioni shadow

In una stanza shadow tutti entrano come osservatori tranne l'host. Gli osservatori non possono votare, ma vedono i voti, le rivelazioni e le selezioni di testo dell'host con circa 1,5 secondi di latenza. La selezione corrente dell'host è evidenziata in ambra sugli schermi degli osservatori.

Persistenza e ripristino dopo un crash

Ogni stanza è basata su eventi. Ogni mutazione (ingresso, voto, rivelazione, cambiamento, messaggio, avanzamento, chiusura) aggiunge una riga JSON a:

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

Lo stato della stanza è una pura riproduzione di quel log, quindi le stanze attive sopravvivono a un riavvio del server. Il log funge anche da traccia di audit della sessione: voti alla cieca, timestamp, discussione e ogni cambiamento successivo alla rivelazione con il suo contesto di maggioranza. GET /rooms/api/<CODE>/export (host o amministratore) restituisce il log più le metriche calcolate in JSON.

Con persist_votes: true (il valore predefinito), il voto finale di ogni membro su un elemento rivelato viene scritto nel suo normale stato di annotazione quando l'host avanza. Il lavoro svolto nella stanza conta come annotazione reale e confluisce in tutti i percorsi di esportazione esistenti.

I client si sincronizzano interrogando /events con un cursore. Non ci sono WebSocket, quindi le stanze funzionano allo stesso modo con il server di sviluppo multithread e con qualsiasi deployment WSGI.

Riepilogo dell'API

EndpointMetodoChi
/rooms, /rooms/<code>GETutenti autenticati (pagine)
/rooms/api/list, /rooms/api/disagreementsGETutenti autenticati
/rooms/api/createPOSTsecondo who_can_create
/rooms/api/<code>/join, /leave, /vote, /message, /presencePOSTmembri
/rooms/api/<code>/state, /events?since=NGETmembri
/rooms/api/<code>/reveal, /advance, /closePOSThost
/rooms/api/<code>/exportGEThost o amministratore

Ulteriori letture