Skip to content

Salas multijogador

Conduza sessões ao vivo de norming e calibração dentro do Potato. Votos às cegas, revelação pelo anfitrião, discussão e um medidor em tempo real do alfa de Krippendorff que mostra o quanto a sessão valeu.

Novo na v2.7.0

As salas multijogador transformam a anotação de tarefa solitária em uma sessão compartilhada e ao vivo. Um grupo de anotadores trabalha no mesmo item ao mesmo tempo, com as dinâmicas sociais medidas, e não apenas viabilizadas. Sem LLM, sem serviços externos, sem novas dependências.

Uma sala de norming ao vivo: votos às cegas revelados, um medidor de concordância em tempo real e uma troca de voto por conformidade registrada.

Três tipos de sala:

TipoO que acontece
Norming (alinhamento)Todo mundo vota às cegas, o anfitrião revela, o grupo discute e qualquer um pode mudar seu voto. Um medidor de concordância ao vivo compara o α às cegas com o α depois da discussão.
Huddle (adjudicação)Percorre os itens em que sua equipe discorda no momento, com as anotações originais de cada um exibidas como contexto. Uma sessão de adjudicação ao vivo.
Shadow (observação)Os anotadores em treinamento entram como observadores e assistem ao anfitrião anotar em tempo real, inclusive qual parte do texto ele destaca.

Por que salas de norming

Equipes de anotação já fazem reuniões de norming por compartilhamento de tela, e o resultado fica nas anotações de alguém. As salas colocam a sessão dentro da ferramenta e a instrumentam.

  • Às cegas primeiro. Antes da revelação, os membros veem quem votou, mas nunca o quê. Isso é imposto no servidor, então as primeiras impressões são de fato independentes.
  • A revelação é uma medição. Os votos às cegas ficam imutáveis assim que são revelados. Toda mudança posterior à revelação é registrada com o voto de origem, o voto de destino e qual era a maioria naquele momento, o que dá um registro de conformidade por membro.
  • O medidor de α responde “valeu a pena?” O α de Krippendorff é calculado duas vezes sobre os itens revelados: nos votos às cegas e nos votos atuais. A diferença é o ganho de alinhamento da sessão, na tela enquanto ela acontece.

Configuração

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

As salas votam sobre um único esquema de escolha única (radio ou likert). Se schema não for definido, é usado o primeiro esquema desse tipo em annotation_schemes.

Conduzindo uma sessão

  1. Inicie o servidor, faça login e abra /rooms.
  2. Crie uma sala (tipo e quantidade de itens). Ela recebe um código de seis letras como MKT4QP. Os códigos evitam glifos ambíguos, então dá para lê-los em voz alta.
  3. Os demais entram pela lista do lobby ou abrindo /rooms/<CODE>.
  4. Vote, o anfitrião revela, discutam no chat lateral, mude o voto se for convencido e o anfitrião avança. Depois do último item, a sala fecha com um resumo da sessão, e o anfitrião pode baixar o log completo de eventos.

Huddles

Escolher Huddle na criação preenche a sala com todos os itens em que os anotadores discordam no momento segundo o esquema da sala, até 200. As anotações originais aparecem acima do painel de votação como contexto. As discordâncias são calculadas ao vivo a partir do estado de anotação, então o subsistema de adjudicação não precisa estar habilitado.

Sessões shadow

Em uma sala shadow, todos entram como observadores, menos o anfitrião. Os observadores não podem votar, mas veem os votos, as revelações e as seleções de texto do anfitrião com cerca de 1,5 segundo de latência. A seleção atual do anfitrião fica destacada em âmbar nas telas dos observadores.

Persistência e recuperação de falhas

Toda sala é baseada em eventos. Cada mutação (entrada, voto, revelação, mudança, mensagem, avanço, fechamento) acrescenta uma linha JSON a:

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

O estado da sala é uma reprodução pura desse log, então as salas ativas sobrevivem a uma reinicialização do servidor. O log serve também como trilha de auditoria da sessão: votos às cegas, timestamps, discussão e cada mudança posterior à revelação com seu contexto de maioria. GET /rooms/api/<CODE>/export (anfitrião ou administrador) retorna o log mais as métricas calculadas em JSON.

Com persist_votes: true (o padrão), o voto final de cada membro em um item revelado é gravado no seu estado normal de anotação quando o anfitrião avança. O trabalho feito na sala conta como anotação real e flui para todos os caminhos de exportação existentes.

Os clientes se sincronizam consultando /events com um cursor. Não há WebSockets, então as salas funcionam tanto no servidor de desenvolvimento com threads quanto em qualquer implantação WSGI.

Resumo da API

EndpointMétodoQuem
/rooms, /rooms/<code>GETusuários autenticados (páginas)
/rooms/api/list, /rooms/api/disagreementsGETusuários autenticados
/rooms/api/createPOSTconforme who_can_create
/rooms/api/<code>/join, /leave, /vote, /message, /presencePOSTmembros
/rooms/api/<code>/state, /events?since=NGETmembros
/rooms/api/<code>/reveal, /advance, /closePOSTanfitrião
/rooms/api/<code>/exportGETanfitrião ou administrador

Leitura adicional