Resumo

  • A versão 2.14 do Bugzilla, de 2001, mudou o tratamento de votos que antes podiam sumir após alterações de configuração ou de produto.
  • As cotas e os limites de confirmação ficavam com a administração; responsáveis pelas correções continuavam cuidando de prioridade, dependências e prazo previsto.

Arrumar um arquivo costuma ser uma atividade discreta. No Bugzilla dos primeiros anos, a arrumação podia fazer uma pequena plateia desaparecer. Bastava mover um problema para outro produto: os votos que ele havia recebido eram apagados. O bug seguia firme. Quem queria vê-lo corrigido perdia lugar na contagem.

Uma reclamação de fevereiro de 2000 ajuda a entender o custo. No registro 28882, Matthew Tuck relatou que uma mudança nas regras de votação havia derrubado da lista dos dez primeiros um problema que apoiava. Algumas pessoas tinham perdido todos os votos naquele registro. Sua sugestão era reduzir as escolhas ao novo limite. Para uma regra que prometia diminuir, zerar parecia excesso de dedicação.

O próprio pedido precisou sobreviver à fila. Foi encerrado como inválido em fevereiro de 2001, reaberto no mesmo dia e marcado como corrigido em agosto. A discussão encontrou uma dificuldade concreta: diminuir o máximo por bug era fácil; diminuir a quantidade total disponível para uma pessoa exigia escolher quais dos seus interesses seriam sacrificados. A conta dependia de uma decisão sobre preferências.

Um pouco de desordem para salvar a memória

As notas da versão 2.14 explicaram a solução. Se os votos de alguém em um único bug ultrapassassem o máximo, seriam reduzidos até esse máximo, com aviso ao usuário. Se a pessoa ultrapassasse a cota total de um produto, o sistema conservaria o excesso. Ela só poderia alterar seus votos para resolver a distribuição acima da cota. Aquela versão não adotava outra providência para obrigá-la a fazer isso.

Era uma escolha administrativa bastante reveladora: aceitar uma conta temporariamente fora do limite para preservar o que alguém tinha escolhido. A mudança de produto também deixava de apagar automaticamente todos os votos. O relatório ganhava transporte melhor; seus apoiadores já não eram tratados como embalagem descartável.

Em 2002, o manual de administração que acompanhava o Bugzilla 2.16 mostrava quem regulava essa participação. Para cada produto, era possível definir a cota por pessoa, o máximo por pessoa em um bug e o total necessário para promover automaticamente um registro de UNCONFIRMED para NEW. Cota pessoal igual a zero desligava a votação. Limiar igual a zero desligava a promoção automática. O botão do usuário tinha uma sala de controles nos fundos.

Alguém ainda precisava sentar para corrigir

O manual de uso daquela versão também apresentava responsável, prioridade, gravidade, versão pretendida e dependências. A prioridade servia para o responsável ordenar os próprios bugs. Uma correção podia esperar por outra. Os votos ajudavam a enxergar a demanda enquanto a distribuição das horas continuava exigindo trabalho humano.

A contribuição da web estava nesse lugar persistente para reunir vontades. Um usuário encontrava o problema, acrescentava apoio e podia acompanhar mudanças. Para manter essa conversa útil, o projeto precisava conservar as escolhas durante reorganizações e encaminhá-las a pessoas com tarefas definidas. A história é pequena, mas diz muito sobre participação online: até uma boa ideia pode perder o público dentro de um arquivo mal transportado.