A Economia de Bounties: Transformando Membros Ociosos em Contribuidores Pagos e Rastreáveis

1. Por que as recompensas superam o “quem quer ajudar?”

Chamados por voluntários recebem respostas únicas. Um membro ajuda uma vez, sente-se bem e volta a observar — porque não havia registro, recompensa ou acompanhamento. Uma recompensa transforma a mesma solicitação em um contrato público, precificado e com estado: título, recompensa, proprietário, status e histórico que qualquer pessoa no servidor pode ver.

O preço é o ponto. Uma recompensa de 20 euros por uma tarefa de documentação sinaliza que o trabalho tem valor real. Membros que nunca se voluntariariam respondem a trabalhos precificados, porque o trabalho precificado remove a ambiguidade sobre se seu esforço será reconhecido.

2. O ciclo de vida: quatro comandos, cinco estados

Sovereign implementa recompensas como uma máquina de estados rigorosa: OPEN → IN_PROGRESS → REVIEW → PAID, com um caminho CLOSED explícito para posts abandonados. Qualquer pessoa com uma identidade vinculada pode criar uma recompensa com `/bounty create <Título> | <Valor>` (mínimo de 5 EUR, armazenado em centavos), navegar pelas abertas com `/bounty list`, assumir uma com `/bounty claim <ID>`, e enviar o trabalho finalizado com `/bounty done <ID>`.

A máquina de estados faz o trabalho de moderação para você. Uma recompensa não pode ser reivindicada duas vezes, o criador não pode reivindicar seu próprio post, e apenas o trabalhador atribuído pode enviar. Cada transição notifica a pessoa certa: o criador recebe uma DM quando sua recompensa é reivindicada e novamente quando o trabalho é enviado, e o envio chega no Dashboard Exchange para aprovação.

Os fundos são liberados apenas após aprovação explícita no Dashboard. Isso mantém o ciclo humano onde importa — a confiança — e automatizado em todos os outros lugares.

// Command routing and the guard clauses that make the state machine safe
switch (action) {
  case 'create': return await createBounty(tenantId, member.id, args);   // -> OPEN
  case 'list':   return { reply: await listBounties(tenantId) };         // 5 latest OPEN
  case 'claim':  return await claimBounty(tenantId, member.id, args);    // OPEN -> IN_PROGRESS
  case 'done':   return await completeBounty(tenantId, member.id, args); // IN_PROGRESS -> REVIEW
}

// Guards enforced inside the transition functions:
// - status must match the expected state or the command is rejected
// - creatorId !== workerId   (no self-claims)
// - only the assigned workerId may call /bounty done
// Funds are released after owner approval: Dashboard > Exchange (REVIEW -> PAID)

3. Ajustando recompensas para que construam retenção, não apenas produção

Recompensas que funcionam são pequenas, específicas e podem ser concluídas em uma noite. Uma comunidade que publica três ou mais recompensas novas por semana dá aos membros um motivo constante para verificar o servidor: o trabalho aberto é uma razão regularmente atualizada para voltar, que é exatamente o comportamento que os engenheiros de retenção estão tentando criar.

A estratégia de crescimento é publicar recompensas para coisas que tornam a comunidade melhor de gerenciar: scripts de onboarding, documentação, criação de clipes, cobertura de moderação, logística de eventos. Cada recompensa concluída é um ativo permanente, não uma entrega única.