Skip to content

Multiplayer Rooms

ノーミングとキャリブレーションのセッションをPotato上でライブに実施します。ブラインド投票、ホストによる公開、議論、そしてそのセッションに何の意味があったかを示すリアルタイムのKrippendorff's αメーターを備えます。

v2.7.0の新機能

Multiplayer Rooms（マルチプレイヤールーム）は、アノテーションを1人きりの作業からライブの共同セッションに変えます。複数のアノテーターが同じアイテムに同時に取り組み、そこで働く社会的な力学は、単に生じるだけでなく測定されます。LLMも外部サービスも新しい依存も不要です。

ライブのノーミングルーム：公開されたブラインド投票、リアルタイムの一致度メーター、記録された同調の切り替え。

ルームの種類は3つです。

種類何が起きるか
Norming全員がブラインドで投票し、ホストが公開し、グループで議論し、誰でも投票を変えられます。ライブの一致度メーターが、ブラインド時のαと議論後のαを並べて表示します。
Huddleチームがいま意見の割れているアイテムを順に見ていきます。全員の元のアノテーションがコンテキストとして表示されます。ライブの裁定セッションです。
Shadow研修中のアノテーターがオブザーバーとして参加し、ホストがアノテーションする様子を、テキストのどこをハイライトしているかも含めてリアルタイムで見ます。

ノーミングルームの意義

アノテーションチームはすでに画面共有でノーミング会議をしていて、その結果は誰かのメモの中に埋もれています。ルームはそのセッションをツールの一部にし、計測できるようにします。

  • まずブラインドで。 公開前、メンバーには誰が投票したかは見えますが、何に投票したかは見えません。これはサーバー側で強制されるので、第一印象は本当に独立しています。
  • 公開そのものが測定になる。 ブラインド投票は公開された時点で変更できなくなります。公開後の変更はすべて、変更前の値、変更後の値、その時点の多数派とともに記録され、メンバーごとの同調の記録になります。
  • αメーターが「やる価値はあったのか」に答える。 Krippendorff's αは公開済みアイテムに対して2回計算されます。ブラインド投票に対してと、現在の投票に対してです。その差がそのセッションのノーミングによる改善分で、進行中に画面に表示されます。

設定

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

ルームでの投票は、1つの単一選択スキーマ（radio または likert）を対象とします。schema を設定しない場合は、annotation_schemes の中で最初に見つかったそうしたスキーマが使われます。

セッションの進め方

  1. サーバーを起動してログインし、/rooms を開きます。
  2. ルームを作成します（種類とアイテム数を指定）。MKT4QP のような6文字のコードが発行されます。紛らわしい字形は避けてあるので、声に出して読み上げられます。
  3. ほかのメンバーはロビーの一覧から、または /rooms/<CODE> を開いて参加します。
  4. 投票し、ホストが公開し、サイドチャットで議論し、納得すれば投票を変え、ホストが次に進めます。最後のアイテムが終わるとルームはセッションのサマリーとともに閉じ、ホストはイベントログ全体をダウンロードできます。

Huddle

作成時に Huddle を選ぶと、そのルームのスキーマでアノテーターの意見がいま割れているアイテムが、最大200件までルームに投入されます。元のアノテーションは投票パネルの上にコンテキストとして表示されます。意見の不一致はアノテーションの状態からその場で計算されるので、裁定サブシステムを有効にしておく必要はありません。

Shadowセッション

シャドウルームでは、ホスト以外の全員がオブザーバーとして参加します。オブザーバーは投票できませんが、ホストの投票、公開、テキスト選択をおよそ1.5秒の遅延で見られます。ホストが現在選択している範囲は、オブザーバーの画面で琥珀色にハイライトされます。

永続化とクラッシュからの復旧

すべてのルームはイベントソーシングされています。各操作（参加、投票、公開、変更、メッセージ、次へ進む、終了）は、次のファイルにJSONを1行追記します。

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

ルームの状態はそのログを再生した結果そのものなので、進行中のルームはサーバーの再起動を乗り越えます。ログはセッションの監査証跡も兼ねます。ブラインド投票、タイムスタンプ、議論、そして公開後のすべての変更が、その時点の多数派とともに残ります。GET /rooms/api/<CODE>/export（ホストまたは管理者）は、ログと計算済みメトリクスをJSONで返します。

persist_votes: true（デフォルト）では、ホストが次に進めるときに、公開済みアイテムに対する各メンバーの最終投票が通常のアノテーション状態に書き込まれます。ルームでの作業は本物のアノテーションとして数えられ、既存のあらゆるエクスポート経路に流れます。

クライアントはカーソル付きで /events をポーリングして同期します。WebSocketsを使わないので、ルームはスレッド化された開発サーバーでも任意のWSGIデプロイでも同じように動きます。

APIの概要

エンドポイントメソッド対象
/rooms、/rooms/<code>GETログイン済みユーザー（ページ）
/rooms/api/list、/rooms/api/disagreementsGETログイン済みユーザー
/rooms/api/createPOSTwho_can_create の設定による
/rooms/api/<code>/join、/leave、/vote、/message、/presencePOSTメンバー
/rooms/api/<code>/state、/events?since=NGETメンバー
/rooms/api/<code>/reveal、/advance、/closePOSTホスト
/rooms/api/<code>/exportGETホストまたは管理者

参考資料