Resumo

  • Em 10 de agosto, a W3C Team iniciou o refinement de uma proposta de Carta para o Immersive Web Working Group. O aviso indicou o issue 564 para a discussão pública e a lista confidencial w3c-ac-forum para discussões de Membros.
  • A seção 4.2 do W3C Process exige que todos os issues apresentados contra a proposta sejam formalmente tratados e que as resoluções sejam acompanhadas num disposition of comments, com destaque para o que não foi resolvido por consenso.
  • O issue público já contém uma cadeia verificável: um bloqueio de segurança, uma resposta e o PR 862; perguntas da APA, respostas e o PR 865. No corte de 30 de agosto, os dois PRs permaneciam abertos e sem merge.
  • Confidencialidade não é falha. As seções 7.2 e 7.3 protegem informação Member-only e permitem uma versão pública não atribuída, feita pela autoridade competente, que comunique o necessário sem expor o original.
  • O registro comum deveria trazer classe do problema, versão e seção afetadas, resposta, diff público ou justificativa para não alterar, estado do consenso, próxima autoridade e histórico. Não precisa revelar nomes, mensagens, contagem de contribuições nem detalhes que identifiquem um Membro.
  • Participação fornece evidência e conhecimento, não um voto de AC nem um mandato genérico do público. Refinement, Team Decision, AC Review e W3C Decision continuam separados.

Canais diferentes podem cumprir funções diferentes

O aviso de 10 de agosto não escondeu a bifurcação. A discussão pública foi direcionada ao repositório Strategy; os Membros também receberam a possibilidade de discutir num fórum reservado. Há um Chartering Facilitator e um período estimado até 7 de setembro para a mesma proposta.

O canal público favorece precisão: linha citável, patch, histórico e revisão por quem não pertence à instituição. O canal protegido pode acomodar um cronograma de implementação não anunciado, uma restrição contratual ou uma avaliação que perderia qualidade se o autor tivesse de expor sua organização. Obrigar toda contribuição a ser pública pode produzir menos informação, não mais legitimidade.

Isso não prova que a lista reservada foi usada, tampouco que tenha dominado a discussão. A disponibilidade de um canal não é evidência de conteúdo. A pergunta é estrutural: se qualquer uma das portas puder alterar a mesma Carta, qual registro público mostrará o percurso até o texto?

O ponto de junção deve ser a disposição, não a mensagem. O conteúdo bruto permanece sob sua regra de acesso. Uma camada pública pode registrar que uma classe de problema chegou a uma cláusula, recebeu resposta e terminou em mudança, justificativa de não mudança ou estado pendente.

O issue 564 mostra por que “aberto” e “fechado” são insuficientes

Na revisão de segurança, um participante comparou o termo “sections” da proposta com “separate sections” do template vigente para o tratamento de segurança e privacidade. Chamou o comentário de blocking e fixou a condição de encerramento. A resposta reconheceu a diferença e abriu o PR 862. O revisor disse que consideraria o bloqueio resolvido quando houvesse merge.

Problema, resposta, mudança proposta e condição de fechamento são quatro estados. Como o PR ainda estava aberto, seria incorreto dizer que o texto já estava corrigido. Também seria incorreto dizer que a observação foi ignorada.

A APA trouxe outro formato: questões sobre plane e mesh detection, o calendário do WebGPU e a continuidade do WebGL, CSS Spatial Layout e haptics. A resposta explicou fronteiras e abriu o PR 865. A APA disse que as perguntas iniciais tinham sido respondidas, mas levantou depois uma dúvida adicional sobre “detection”, “tracking” e “sensing”.

O rótulo geral de aprovado ou rejeitado não serve. Algumas questões receberam resposta, um patch continuou sem merge e uma dúvida terminológica seguiu viva. Um bom disposition desce ao nível da questão.

Os 14 comentários exibidos também não medem representação. Uma pessoa pode fazer cinco perguntas; várias podem ajustar uma palavra. Silêncio pode significar concordância, abstenção, desconhecimento ou falta de autoridade. Atividade não é voto.

O Process liga cada issue a uma resolução

Para iniciar o refinement, a Team publica a proposta, explica como participar, anuncia um período de pelo menos 28 dias e nomeia o Facilitator. Durante essa fase ocorre a wide review. O Facilitator busca consenso entre os participantes; se não o encontra, pode pedir uma Team Decision e a justificativa deve ser documentada.

A regra central determina que todos os issues contra o texto sejam formalmente tratados e suas resoluções acompanhadas num disposition of comments que destaque questões não resolvidas por consenso.

Essa exigência é mais forte que um link para uma conversa. Ela requer conexão entre entrada, resposta e estado. Mas não elimina as regras de confidencialidade nem exige a publicação literal do material recebido.

Antes do fim anunciado, a Team precisa iniciar AC Review, abandonar a proposta ou estender o refinement. A decisão deve ter a visibilidade prevista e, quando não houver AC Review, uma justificativa.

AC Review é outra fase. Cada organização Membro envia uma review por seu representante, e dissent deve aparecer como Formal Objection. Comentário público no refinement não é essa review. Uma mensagem reservada também não vira automaticamente objeção formal.

Um índice público não exige vazamento

O Process diferencia public, Member-only e Team-only. Quem tem acesso ao material restrito precisa protegê-lo. Copiar mensagem, identificar autor ou revelar um produto capaz de indicar a origem contrariaria o próprio controle.

A seção 7.3 reconhece, ao mesmo tempo, que processos com componente público relevante podem exigir informação pública sobre o que afeta decisões. Só a Team ou parte autorizada pode mudar o nível. Se o autor não preparar uma versão adequada, a Team pode divulgar uma versão não atribuída que comunique razoavelmente o necessário e respeite a confidencialidade original.

Uma linha poderia dizer “Classe Member-only M-03: fronteira de escopo de um deliverable”, apontar seção e commit, registrar eventual mudança pública e disposição. Não precisaria informar quem falou, quantos Membros participaram, qual produto estava em jogo ou repetir uma frase reservada.

Quando até a classe permite identificar a origem, o resumo deve recuar para o menor estado de processo publicável. Agregar não apaga risco de reidentificação.

As fontes não permitem afirmar que exista contribuição confidencial sobre esta Carta. O registro deve funcionar sem inventá-la. Disponibilidade de canal e uso de canal são fatos diferentes.

Participar não é receber autoridade sem limite

O Process manda considerar visões e objeções legítimas vindas dos participantes e também de terceiros, inclusive o público. Especialistas de acessibilidade, segurança, privacidade, internacionalização e arquitetura podem detectar lacunas reais. Implementadores podem contestar prazos com evidência operacional.

Mas conhecimento não transforma o colaborador em principal. A contribuição vale por razões e consequências, não por uma categoria abstrata de stakeholder.

No refinement, o Facilitator busca consenso entre os participantes. A Team executa decisões atribuídas e define o próximo estágio. O Advisory Committee conduz a revisão formal, seguida da W3C Decision. Essas camadas não devem ser colapsadas.

O registro comum mostra a origem quando isso é seguro, mas sempre deve identificar o papel que respondeu e a autoridade que encerrou o estado. Assim, a consulta pública não vira teatro nem soberania imaginária.

O mínimo que o registro deveria conter

Para cada issue ou classe segura, a camada comum deveria trazer:

  1. identificador estável;
  2. classe do canal, public ou Member-only, sem identidade ou contagem restrita;
  3. formulação pública segura;
  4. seção e commit exatos;
  5. papel e data da resposta;
  6. PR, diff, texto alternativo ou motivo de não mudança;
  7. disposição: aceito, parcial, sem mudança, substituído, retirado, adiado ou não resolvido;
  8. estado de consenso exigido pelo Process;
  9. próxima autoridade: mais refinement, Team Decision, AC Review, extensão ou abandono;
  10. encerramento, sucessão e correções.

O canal não atribui peso. Member-only não é superior a uma revisão técnica pública, e público não significa representativo. O canal explica custódia; razões e procedimento sustentam a decisão.

A versão congelada impede atalhos. PR aberto não é texto incorporado; merge não é Carta aprovada. A correção só satisfaz a condição quando chega à versão que avança.

Limites da apuração

Em 30 de agosto, o issue 564 e os PRs 862 e 865 estavam abertos, e a Carta 2026 continuava draft. A página do grupo mostrava a Carta ativa até 25 de setembro.

Isso não prova atraso indevido, descumprimento nem fraqueza técnica. Refinement é a fase feita para comentários e patches pendentes. A data de 7 de setembro era aproximada, e o Process prevê extensão anunciada.

O link de diretório para privacy é contextual: representa a fronteira de confidencialidade analisada. Não identifica W3C, Immersive Web Working Group ou WebXR e não implica endosso.

A recomendação é estreita: manter as duas portas, respeitar suas regras e publicar estado suficiente para inspecionar a linhagem de uma só Carta.

Fontes

  1. W3C — Início do refinement da Carta Immersive Web, 10 de agosto de 2026
  2. W3C — Proposta de Carta do Immersive Web Working Group
  3. w3c/strategy issue 564 — Immersive Web WG 2026 Group Charter
  4. w3c/charter-drafts PR 831 — proposta inicial de 2026
  5. w3c/charter-drafts PR 862 — alinhamento do texto de coordenação
  6. w3c/charter-drafts PR 865 — alinhamento das descrições
  7. W3C Process Document, 18 de agosto de 2025
  8. W3C — Immersive Web Working Group
  9. W3C — Carta ativa de setembro de 2024
  10. w3c/charter-drafts — histórico de commits da proposta 2026
  11. w3c/charter-drafts commit 488587ec141b — marca DRAFT
  12. W3C — Horizontal Review
  13. Heng Lu — On the Multi-Stakeholder Mirage
  14. Heng Lu — On the Reality Layers of Internet Governance