Resumo

  • A issue 566 da Strategy foi aberta em 4 de agosto para renovar um grupo existente, prevê o fim do refinamento em 15 de outubro e declara nenhuma mudança substantiva.
  • O próprio registro chama a primeira carta de agressivamente otimista e espera CR no fim de 2026 ou início de 2027, depois manutenção. Ele reconhece que essa intenção ainda precisa entrar no texto.
  • A carta ativa previa CR em março, Proposed Recommendation em junho e Recommendation em setembro de 2026. As publicações permanecem em Working Draft, um dado de maturidade que não mede qualidade técnica.
  • O commit f00f3b8 mantém cinco prazos [Q1–4 YYYY], uma escolha de maturidade, um item Web [spec name], cronograma FooML/BarML e instruções operacionais pendentes.
  • Antes da revisão pelo Advisory Committee, o W3C deveria publicar um recibo preso ao commit submetido, com destino, data, responsável pela manutenção e disposição de cada token remanescente.

O assunto pode continuar enquanto o compromisso muda

“Sem mudanças substantivas” pode se referir ao escopo. A missão continua sendo desacoplar aplicações, identidade e armazenamento por meio do protocolo LWS. As cinco especificações permanecem nomeadas. Nada no dossiê anuncia uma tecnologia inteiramente nova.

Uma carta, porém, também organiza tempo e autoridade. A carta vigente, de 9 de setembro de 2024 a 8 de setembro de 2026, projetou o protocolo central em CR em 10 de março de 2026, Proposed Recommendation em 9 de junho e Recommendation em 8 de setembro. Para avançar, esperava duas implementações independentes e interoperáveis de cada recurso, verificadas por testes abertos.

A página de cartas do grupo conserva esse instrumento datado. Já a página de publicações ainda reúne os textos sob Working Drafts; o protocolo 1.0 também aparece assim. A diferença entre plano e estado é pública. Não é possível extrair dela a causa, o número de implementações ou a chance de transição futura.

Por isso o destino CR-manutenção precisa ser escrito como escolha própria. Ele não altera necessariamente a matéria do trabalho, mas altera o ponto no qual o mandato de desenvolvimento se converte em manutenção.

Um arquivo que ainda conversa com seu editor

O repositório começa com o commit de 3 de agosto, vindo do charter assistant. Em 5 de agosto, um segundo commit retirou LDP Next da coordenação. A pequena edição mostra atividade específica; não revela todas as decisões em andamento.

O estado auditável é o arquivo fixo desse segundo commit, não apenas a renderização mutável. Nele, as datas de início e fim continuam como instruções. O 0,1 FTE está marcado como TODO. A frequência de teleconferências oferece alternativas. O canal de trabalho manda escolher lista pública, GitHub issues ou ambos.

A introdução das entregas diz Choose one. Uma opção define a conclusão como chegada a Recommendation ou a outro estado estável; outra afirma que o grupo pretende publicar Candidate Recommendation Snapshots e não avançar seus documentos a Recommendation.

Cada uma das cinco especificações contém [Q1–4 YYYY]. A seção de entregas tentativas ainda tem Web [spec name] e descrição genérica. A linha do tempo usa FooML e BarML. Nos critérios de sucesso, uma instrução manda remover a cláusula de interoperabilidade se o grupo não for a REC; outra sugere adicionar interesse de implementadores se não for.

Essas marcas não provam que nenhuma escolha foi feita em privado. Elas provam apenas que o arquivo público congelado ainda não registra uma escolha única e completa.

O refinamento ainda tinha tempo

Segundo o Processo do W3C, antes do fim da fase a Team deve iniciar a revisão do Advisory Committee, abandonar a proposta ou estender o refinamento. A carta apresenta entregas, marcos disponíveis, reuniões e comunicação. A adoção posterior é uma W3C Decision, seguida de Call for Participation se aprovada.

Em 2 de setembro, 15 de outubro ainda estava no futuro. O arquivo de 5 de agosto pode nunca ser o texto submetido. Tampouco sabemos quais decisões já existiam fora da página pública. O limite correto é falar de prontidão, sem acusar infração ou tratar a minuta como mandato.

Um recibo de prontidão orientado às cinco entregas

O recibo deve fixar commit, estado do refinamento e vigência proposta. Em seguida, cinco linhas — uma por documento — registrariam maturidade atual, destino escolhido, trimestre esperado ou razão atribuída para não estimar, e critério de sucesso aplicável.

Caso se escolha CR seguida de manutenção, o registro deve dizer se haverá Snapshots, quais mudanças são permitidas e quem controla novas publicações. “Manutenção” vira assim uma superfície de decisão verificável.

Outro bloco daria destino ao entregável fictício, ao cronograma FooML/BarML, ao TODO de FTE, às opções de reunião e ao canal público. Resolvido em commit, mantido de propósito, não aplicável ou adiado com responsável são estados aceitáveis.

Uma nota final distinguiria escopo técnico constante de cronograma, maturidade e operação modificados. O recibo não escolhe Recommendation pelo grupo. Ele apenas permite que o Advisory Committee saiba qual proposição está revisando.

Fontes