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.

Três tipos de sala:
| Tipo | O 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
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 schemeAs 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
- Inicie o servidor, faça login e abra
/rooms. - 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. - Os demais entram pela lista do lobby ou abrindo
/rooms/<CODE>. - 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:
<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
| Endpoint | Método | Quem |
|---|---|---|
/rooms, /rooms/<code> | GET | usuários autenticados (páginas) |
/rooms/api/list, /rooms/api/disagreements | GET | usuários autenticados |
/rooms/api/create | POST | conforme who_can_create |
/rooms/api/<code>/join, /leave, /vote, /message, /presence | POST | membros |
/rooms/api/<code>/state, /events?since=N | GET | membros |
/rooms/api/<code>/reveal, /advance, /close | POST | anfitrião |
/rooms/api/<code>/export | GET | anfitrião ou administrador |
Leitura adicional
- Psicometria — habilidade por anotador e dificuldade por item; as salas são onde você resolve os problemas de livro de códigos que ela aponta
- Adjudicação e discordância — a contraparte assíncrona dos huddles
- Como escrever diretrizes de anotação
- Documentação de origem