Skip to content

Multiplayer-Räume

Norming- und Kalibrierungssitzungen live in Potato durchführen. Blinde Abstimmungen, eine Aufdeckung durch den Host, Diskussion und eine Echtzeitanzeige von Krippendorffs Alpha, die zeigt, was die Sitzung gebracht hat.

Neu in v2.7.0

Multiplayer-Räume machen aus der Annotation statt einer Einzelarbeit eine gemeinsame Sitzung in Echtzeit. Eine Gruppe von Annotatoren bearbeitet dasselbe Element zur selben Zeit, wobei die Gruppendynamik gemessen und nicht bloß ermöglicht wird. Kein LLM, keine externen Dienste, keine neuen Abhängigkeiten.

Ein Live-Norming-Raum: aufgedeckte blinde Abstimmungen, eine Echtzeitanzeige der Übereinstimmung und ein protokollierter Konformitätswechsel.

Drei Raumtypen:

TypWas dort passiert
Norming (Normierung)Alle stimmen blind ab, der Host deckt auf, die Gruppe diskutiert, und jeder darf seine Stimme ändern. Eine Live-Anzeige der Übereinstimmung stellt das blinde α dem α nach der Diskussion gegenüber.
Huddle (Adjudikation)Geht die Elemente durch, bei denen das Team derzeit uneinig ist, mit den ursprünglichen Annotationen aller als Kontext. Eine Adjudikationssitzung in Echtzeit.
Shadow (Hospitation)Angelernte treten als Beobachter bei und sehen dem Host in Echtzeit beim Annotieren zu, samt der Textstelle, die er hervorhebt.

Wozu Norming-Räume

Annotationsteams halten ihre Norming-Meetings ohnehin per Bildschirmfreigabe ab, und das Ergebnis landet in den Notizen von irgendjemandem. Räume machen die Sitzung zum Teil des Werkzeugs und instrumentieren sie.

  • Zuerst blind. Vor der Aufdeckung sehen die Mitglieder, wer abgestimmt hat, aber nie was. Das wird serverseitig durchgesetzt, sodass die ersten Eindrücke wirklich unabhängig sind.
  • Die Aufdeckung ist eine Messung. Blinde Stimmen sind nach der Aufdeckung unveränderlich. Jede Änderung danach wird protokolliert, mit dem alten Wert, dem neuen Wert und der Mehrheit in diesem Moment, was ein Konformitätsprotokoll pro Mitglied ergibt.
  • Die α-Anzeige beantwortet „Hat sich das gelohnt?" Krippendorffs α wird über die aufgedeckten Elemente zweimal berechnet: auf den blinden Stimmen und auf den aktuellen Stimmen. Der Abstand ist der Norming-Gewinn der Sitzung, sichtbar während sie läuft.

Konfiguration

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

Räume stimmen über ein einzelnes Einfachauswahl-Schema ab (radio oder likert). Ist schema nicht gesetzt, wird das erste Schema dieser Art in annotation_schemes verwendet.

Eine Sitzung durchführen

  1. Server starten, anmelden und /rooms öffnen.
  2. Einen Raum anlegen (Typ und Elementanzahl). Er bekommt einen sechsstelligen Code wie MKT4QP. Die Codes vermeiden mehrdeutige Zeichen, damit man sie vorlesen kann.
  3. Andere treten über die Liste in der Lobby bei oder indem sie /rooms/<CODE> öffnen.
  4. Abstimmen, der Host deckt auf, im Seiten-Chat diskutieren, die Stimme ändern, wenn man überzeugt ist, und der Host geht weiter. Nach dem letzten Element schließt der Raum mit einer Zusammenfassung der Sitzung, und der Host kann das vollständige Ereignisprotokoll herunterladen.

Huddles

Wird beim Anlegen Huddle gewählt, füllt sich der Raum mit allen Elementen, bei denen die Annotatoren beim Schema des Raums derzeit uneinig sind, bis zu 200. Die ursprünglichen Annotationen erscheinen als Kontext über dem Abstimmungspanel. Uneinigkeiten werden live aus dem Annotationsstand berechnet, das Adjudikations-Subsystem muss also nicht aktiviert sein.

Shadow-Sitzungen

In einem Shadow-Raum tritt jeder außer dem Host als Beobachter bei. Beobachter können nicht abstimmen, sehen aber die Stimmen, Aufdeckungen und Textmarkierungen des Hosts mit rund 1,5 Sekunden Verzögerung. Die aktuelle Auswahl des Hosts wird auf den Bildschirmen der Beobachter bernsteinfarben hervorgehoben.

Persistenz und Absturzsicherheit

Jeder Raum ist event-sourced. Jede Änderung (Beitritt, Stimme, Aufdeckung, Wechsel, Nachricht, Weitergehen, Schließen) hängt eine JSON-Zeile an:

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

Der Raumzustand ist ein reines Replay dieses Protokolls, laufende Räume überstehen also einen Serverneustart. Das Protokoll dient zugleich als Prüfpfad der Sitzung: blinde Stimmen, Zeitstempel, Diskussion und jede Änderung nach der Aufdeckung samt ihrem Mehrheitskontext. GET /rooms/api/<CODE>/export (Host oder Admin) gibt das Protokoll zusammen mit den berechneten Metriken als JSON zurück.

Mit persist_votes: true (der Standard) wird die endgültige Stimme jedes Mitglieds zu einem aufgedeckten Element in dessen regulären Annotationsstand geschrieben, sobald der Host weitergeht. Arbeit im Raum zählt als echte Annotation und fließt in jeden bestehenden Exportpfad.

Clients synchronisieren sich, indem sie /events mit einem Cursor abfragen. Es gibt keine WebSockets, Räume funktionieren also unter dem threaded Dev-Server ebenso wie unter jedem WSGI-Deployment.

API-Übersicht

EndpunktMethodeWer
/rooms, /rooms/<code>GETangemeldet (Seiten)
/rooms/api/list, /rooms/api/disagreementsGETangemeldet
/rooms/api/createPOSTgemäß who_can_create
/rooms/api/<code>/join, /leave, /vote, /message, /presencePOSTMitglieder
/rooms/api/<code>/state, /events?since=NGETMitglieder
/rooms/api/<code>/reveal, /advance, /closePOSTHost
/rooms/api/<code>/exportGETHost oder Admin

Weiterführende Informationen