Resumo

  • O Processo do W3C determina mitigação adequada e oportuna quando uma decisão anulada já produziu consequências e afirma que os aspectos acolhidos da objeção não estão plenamente tratados até lá. Ele não define o registro público que comprova essa passagem.
  • A Vibration API teve acompanhamento real, inclusive um relatório de implementação concluído. Ainda assim, a trilha precisa ser reconstruída entre relatório do Conselho, issue técnico, issue de carta, pull request e revisão estratégica, sem um ato único de fechamento.
  • Um registro de custódia de mitigação do Conselho deve separar a sugestão não vinculante da solução aprovada pelo órgão competente e relacionar cada aspecto acolhido a responsável, poder, prazo, prova e declaração datada.

Anular a decisão não desfaz o que ela já provocou

O Conselho do W3C entra em cena depois que uma Formal Objection não foi resolvida pelos meios ordinários. Sua tarefa principal é binária: confirmar ou anular a decisão questionada. Os argumentos que justificam a anulação passam a ser os aspectos acolhidos da objeção.

Só que a realidade não é binária. Uma decisão pode ter inserido texto em publicação, mudado o estágio de uma especificação, estruturado uma carta ou criado dependências de trabalho. Retirar sua autoridade não apaga automaticamente esses efeitos.

Por isso o Processo acrescenta uma obrigação posterior. Se a decisão anulada já teve consequências ligadas aos aspectos acolhidos, o Conselho deve sugerir como mitigá-las. A Equipe fica responsável por assegurar que partes responsáveis adotem medidas adequadas em tempo hábil. Os aspectos acolhidos não são considerados plenamente tratados antes disso.

Há, portanto, um estado institucional aberto depois do julgamento. A decisão caiu; a reparação ainda precisa percorrer outra cadeia de autoridade. O texto nomeia esse estado, mas não exige um artefato público que o acompanhe até o fim.

A limitação de poder é deliberada. A recomendação concreta do Conselho não vira ordem técnica. A Equipe não recebe o poder novo de despublicar um documento, redigir a especificação ou substituir o consenso do grupo. Cada parte age com competências já existentes.

Esse desenho protege a autonomia técnica. Também divide a responsabilidade: o Conselho identifica o problema, outro ator decide o remédio e a Equipe impede o esquecimento. Sem uma ficha comum, é possível ter bastante trabalho e pouca clareza sobre o encerramento.

Três padrões sem o respectivo comprovante

Uma mitigação deve ser adequada. Isso exige comparar a medida com cada fundamento acolhido, e não apenas apontar que um issue foi movimentado. O registro precisa dizer qual consequência está sendo corrigida e que evidência demonstra o resultado.

Ela deve ocorrer de maneira oportuna. Não é necessário impor o mesmo prazo a uma correção editorial e a uma mudança técnica complexa. Mas deve haver uma meta do caso, uma data de revisão e uma explicação quando o caminho se alongar.

Por fim, a objeção deve chegar ao estado de plenamente tratada. A regra não nomeia quem declara esse estado, onde a decisão aparece, como o autor da objeção é avisado nem como uma declaração incorreta pode ser retificada. A terminologia de fechamento existe sem o ato probatório correspondente.

Vibration API: o acompanhamento existe, a junção não

No fim de 2024, uma revisão do Advisory Committee avaliou tornar obsoleta a Recomendação Vibration API (Second Edition). Foram apresentadas duas Formal Objections. O Devices and Sensors Working Group decidiu no TPAC 2024 regredir o documento e continuar o trabalho em um novo Candidate Recommendation Snapshot. Uma objeção foi resolvida; a outra chegou ao Conselho.

Em 10 de agosto de 2025, o Conselho acolheu a objeção restante. O relatório registrou que a situação já havia mudado. O documento era então um Candidate Recommendation Draft, que não podia ser declarado obsoleto pela regra citada. O Grupo já o havia regredido para poder continuar o trabalho e tratar as preocupações.

O Conselho não determinou um texto técnico final. Recomendou continuidade do processo de publicação, documentação da experiência de implementação no issue 33 e um plano concreto, com justificativa persuasiva, na próxima renovação da carta. Esse plano poderia ou não envolver lançamento em vários grandes mecanismos de navegador, mas deveria permitir uma avaliação informada.

O trabalho posterior é visível. O issue 33 foi fechado como concluído em 1º de maio de 2026 após a atualização do relatório de implementação. O processo da carta de 2026 vinculou a recomendação do Conselho. O issue 781 acompanhou o plano e o relatório. Mais tarde, o pull request 809 propôs trajetórias explícitas para especificações de um único mecanismo, inclusive mudança de status para Vibration caso uma segunda implementação não surgisse. Ele foi fechado sem merge. A carta prosseguiu por outras revisões e pelo exame do Advisory Committee.

Nada disso autoriza dizer que houve inércia. A pergunta é outra: qual desses eventos encerrou qual aspecto acolhido?

A regressão anterior já era mitigação ou apenas contenção provisória? O fechamento do issue 33 resolveu parte da objeção ou apenas entregou um insumo para uma decisão futura? O plano de recharter foi satisfeito por outra redação, substituído por solução consensual distinta ou ainda não recebeu declaração oficial?

O relatório do Conselho prova julgamento e recomendações. O relatório da Equipe prova história processual. O issue técnico prova uma tarefa. O issue de carta prova uma cobrança no refinamento. Pull requests provam propostas de texto. O issue de estratégia prova o caminho mais amplo da carta. Nenhum deles é identificado como livro-mestre do estado “plenamente tratado”.

Por isso, issue aberto não prova violação; issue fechado não prova encerramento institucional. Um patch incorporado comprova mudança, não a suficiência em relação ao fundamento acolhido. Falta a ligação autorizada.

O issue 751 delimitou o que a mitigação não é

O issue 751 do repositório do Processo discute desde 2023 se recomendações do Conselho seriam obrigatórias, se poderiam afetar outros consensos e se a Equipe receberia poderes amplos demais.

As respostas públicas fixaram uma distinção importante. A sugestão do Conselho não vincula o órgão responsável a uma solução específica. Mas, se uma decisão anulada já produziu efeitos, esses efeitos não podem permanecer indefinidamente. Algo precisa desfazê-los, neutralizá-los ou mitigá-los, e a Equipe deve garantir que o assunto não seja esquecido.

O Grupo continua formando consenso. A Equipe não escreve a especificação. Dentro de poderes existentes, pode cobrar o presidente, usar a autoridade de nomeação já prevista, impedir uma publicação que não cumpra requisitos de transição ou recorrer a mecanismos de regressão e abandono. Não pode inventar uma forma de apagar publicação passada.

Ainda houve discordância editorial. Alguns queriam que o Processo mostrasse mais claramente o papel de quem tomou a decisão original. Um participante disse que o fluxo parecia mandar a questão à Equipe e deixar “a mágica acontecer”. A defesa foi que a substância já estava correta e precisava ser genérica. O issue foi adiado como melhoria de redação.

Uma frase dessa discussão contém o requisito operacional: o autor da objeção não deve ser obrigado a acompanhar por meses ou anos a resolução. Isso não lhe dá veto sobre o remédio; atribui à instituição o dever de publicar o estado.

A defesa mais forte é a flexibilidade

Não se deve prescrever um remédio idêntico para todos os casos. A decisão original pode ter vindo de um grupo, presidente, Team, TAG, AB ou autoridade de carta. Mandar sempre o caso de volta ao Working Group seria errado.

O Conselho também não pode virar comitê técnico superior. O órgão responsável pode encontrar uma solução diferente e melhor, amparada por implementação, patentes e consenso. Além disso, os repositórios do W3C já oferecem muita documentação, enquanto deliberações do Conselho, material de membros, votos individuais, medidas de pessoal e assessoria jurídica podem merecer restrição.

Esses argumentos justificam um registro leve e campos protegidos. Não justificam que o fechamento seja inferido. É possível mostrar função, data, autoridade e evidência pública sem expor o conteúdo confidencial.

O registro de custódia da mitigação

Sempre que o Conselho anular uma decisão que já teve efeitos, seu relatório deve abrir um registro versionado. A Equipe manteria o estado; cada parte responsável registraria sua decisão e prova.

O registro precisa reunir:

  • relatório do Conselho, data e versão do Processo;
  • decisão anulada e aspectos acolhidos;
  • consequências existentes e artefatos afetados;
  • papel institucional responsável por cada item;
  • autoridade ordinária que permite agir;
  • sugestão do Conselho marcada como não vinculante;
  • solução aceita, modificada ou alternativa;
  • dependências, data-alvo ou próxima revisão, estado e motivo de atraso;
  • publicação, avanço ou carta mantidos em espera;
  • teste de aceitação que ligue evidência a cada aspecto;
  • situação da notificação ao objetor e ao decisor original, respeitada a confidencialidade;
  • autoridade apta a considerar a medida adequada;
  • declaração datada de encerramento, ou informação expressa de que ela ainda não existe;
  • correções, decisões posteriores, appeals e novas Formal Objections;
  • fronteira entre informação pública e restrita.

O Grupo pode escolher um caminho diferente do sugerido e registrar como ele responde ao mesmo problema. Não surge um novo recurso: uma nova decisão continua sujeita ao procedimento comum. A Equipe também não ganha poder, pois toda ação deve apontar para uma competência anterior.

O ganho central é separar atividade de conclusão. Reunião, issue e patch provam movimento. Mitigação adequada exige evidência confrontada com o problema que o Conselho acolheu.

Limites do que se pode afirmar

O material público não comprova que o W3C descumpriu prazo interno, que a mitigação de Vibration continua inadequada ou que qualquer pessoa evitou o Conselho. O fechamento do issue 33 e a permanência do issue 781 são fatos, mas nenhum decide sozinho o estado do Processo.

O fechamento sem merge do pull request 809 não prova rejeição substantiva nem inexistência de plano equivalente. Controvérsias posteriores da carta de 2026 incluíram outros assuntos e não devem ser usadas retroativamente contra o caso de 2025.

A conclusão é estrutural: o W3C nomeia um estado posterior ao julgamento do Conselho, mas não exige uma peça pública que o conduza ao encerramento.

Fontes

  1. Processo do W3C de 18 de agosto de 2025 — mitigação
  2. Editor’s Draft atual do Processo — mitigação
  3. Process issue 751 — efeitos colaterais da decisão do Conselho
  4. Guia do W3C — Formal Objections e Conselho
  5. Relatório do Conselho sobre Vibration API, segunda rodada
  6. Relatório da Equipe sobre a objeção da Vibration API
  7. Vibration issue 33 — atualizar o relatório de implementação
  8. Charter issue 781 — plano recomendado pelo Conselho
  9. Strategy issue 530 — carta 2026 do Devices and Sensors WG
  10. Pull request 809 — planos por especificação
  11. Guide issue 173 — quem são os decisores
  12. Process issue 1029 — quando publicar o relatório do Conselho
  13. Heng Lu — The Multi-Stakeholder Mirage
  14. Heng Lu — On the Agency Problem at the Core of Internet Governance