O novo voto comunitário do CPC da OpenJS precisa de um registro de transição

Resumo

• A Carta do CPC estabelece que, a partir do ciclo eleitoral do outono de 2026, representantes votantes de projetos não-Impact e de Regular Members dão lugar a até cinco Community Voting Members.
• Observar uma reunião, ser Regular Member, integrar o eleitorado e deter uma cadeira votante são posições distintas. Para concorrer à nova classe, a pessoa deve ser Regular Member e não pode estar servindo como representante votante de um projeto Impact.
• Um registro de transição deve separar ciclo, cadeira anterior, elegibilidade, denominador eleitoral, resultado, limite de afiliação por empregador e competências de Board, CPC e projetos — sem converter previsão em resultado ou participação interna em mandato universal.

Uma regra para o outono não é uma composição já formada

Em organizações de código aberto, uma norma pode ficar pública antes de produzir o fato que ela organiza. Uma Carta pode trazer uma nova categoria, o calendário pode ser acessível e uma reunião pode aceitar observadores. Esses elementos são evidência relevante. Não demonstram que as candidaturas abriram, que a lista de eleitores foi validada, que os votos foram contados ou que determinada pessoa assumiu uma cadeira.

A arquitetura da OpenJS permite ver essa diferença. A Carta chama o Cross Project Council, ou CPC, de liderança técnica da Fundação e trata o Board como sua liderança empresarial. O Board define a política geral do CPC; o CPC atua como órgão técnico delegado dentro desse limite. A mesma Carta anuncia que as duas rotas separadas de voto não-Impact serão substituídas, no ciclo do outono de 2026, por uma classe unificada de Community Voting Members.

Isso comprova uma mudança programada. Não comprova uma eleição já realizada. As fontes públicas consultadas não estabelecem data efetiva de votação, candidatos aprovados, quantidade de cadeiras preenchidas, total de votos ou posse de uma pessoa específica. Narrar a regra futura como se fosse uma lista final é trocar o que está documentado por uma conclusão confortável.

Depois da transição, um colaborador deveria conseguir responder a perguntas básicas sem depender de quem acompanhou a reunião. O representante anterior concluiu o mandato, renunciou, foi substituído, voltou a ser apenas Regular Member ou concorreu à nova classe? Das cinco cadeiras possíveis, quantas foram preenchidas? Quantos Impact Project Voting Members e Regular Members podiam votar naquela data? O teto de um quarto de Voting Members ligados ao mesmo empregador foi aferido sobre qual total? A decisão relevante pertence ao Board, ao CPC ou ao processo autônomo de um projeto?

Não são perguntas que imputam falha. São campos necessários para impedir que uma alteração posterior no README seja tratada como transferência tácita de autoridade.

Quatro posições escondidas na palavra “comunidade”

A Carta diferencia Observers, Regular Members e Voting Members. O repositório público informa que não membros podem participar das reuniões como observadores. A governança descreve o caminho pelo qual um colaborador com atividade recente e sustentada na OpenJS pode solicitar o status de Regular Member. Para a eleição da nova classe, o eleitorado é ainda mais delimitado: Impact Project Voting Members e Regular Members.

Um Observer pode acompanhar a parte pública do trabalho e contribuir para a busca de consenso. Trata-se de participação real, mas não de direito automático de voto nem de ocupação de cadeira.

Um Regular Member tem um vínculo institucional mais específico. A governança exige atividade recente e contínua em projeto, comunidade, espaço de colaboração ou no próprio CPC, e prevê exame do pedido. Essa condição é requisito para candidatura e integra o eleitorado da nova classe. Ela não é certificado de eleição.

Um Impact Project Voting Member chega por outra fonte. Cada projeto Impact pode indicar até duas pessoas segundo seu próprio processo. Essa classe continua no novo arranjo. A participação de seus integrantes na eleição comunitária não converte sua cadeira de origem em cadeira comunitária.

O Community Voting Member é a categoria eleitoral a vigorar no ciclo anunciado, com no máximo cinco assentos. O candidato precisa ser Regular Member e não representar votantemente um projeto Impact. A frase “a comunidade escolheu” pode encobrir quatro afirmações diferentes: quem acompanhou o processo, quem se tornou Regular Member, quem efetivamente podia votar e quem obteve cadeira. A Carta define as fronteiras iniciais; o registro eleitoral deve provar as últimas.

É aqui que a disciplina de Lu Heng é útil. Participação produz experiência, alerta e objeção. Não cria, por si só, autoridade principal sobre todos os atingidos por uma decisão. Uma reunião pública do CPC e uma eleição interna são evidência de um processo definido dentro da Fundação. Não são mandato de representação para todo o ecossistema JavaScript.

Uma nova cadeira não absorve as autoridades existentes

A alteração de classe não reorganiza automaticamente todos os poderes em torno do CPC. Os Voting Members exercem as responsabilidades finais que a Carta atribui ao órgão. O CPC busca lazy consensus e dispõe de uma via de voto quando objeções não se resolvem. O Board preserva a política geral, poderes especialmente jurídicos e participação na aprovação de mudanças da Carta. Projetos seguem autogovernados em seus processos técnicos documentados, dentro das diretrizes do CPC.

Há conexões entre esses níveis, mas conexão não é identidade. Um CPC Director pode representar projetos e comunidades perante o Board. Uma alteração de carta de projeto pode precisar de aprovação do CPC. Uma matéria técnica pode ter de ser elevada ao Board. Nenhuma dessas relações transforma automaticamente um Community Voting Member em diretor do Board, representante de todos os mantenedores ou decisor técnico interno de um projeto. O registro deve indicar a capacidade que a pessoa realmente exerce.

O processo atual já deixa rastros: uma issue pública no começo das candidaturas, uma pull request para atualizar o README após a eleição, uma nota de resultado em lista privada, agendas e registros de reuniões. Há também limites legítimos para assuntos pessoais, jurídicos e parte das informações do Board. Transparência não exige publicar dossiês privados; exige que os fatos públicos decisivos possam ser ligados entre si.

Um nome novo no README não informa, sozinho, o fim de uma cadeira anterior, a duração do novo mandato ou o denominador eleitoral. A governança afirma que Voting Members cujo mandato terminou passam automaticamente a Regular Members, salvo manifestação em contrário. É uma regra útil de destino padrão, não uma certidão individual de saída. “Até cinco” também não diz quantas cadeiras foram ocupadas. E o limite de um quarto por empregador não pode ser reproduzido sem total datado de Voting Members e critério de afiliação.

O registro de transição para Community Voting Members

Daniel Kade propõe um registro de transição de Community Voting Members. Ele não altera a Carta e não exige expor materiais privados de candidatos. Sua função é juntar fatos que, de outro modo, ficam dispersos entre issues, agendas, listas e atualizações de repositório.

O primeiro campo é o estado do ciclo: transição planejada, candidaturas abertas, votação em curso, resultado certificado ou correção. Deve apontar para o texto controlador da Carta, nomear as categorias antiga e nova e impedir que uma regra no futuro pareça uma nomeação já consumada.

O segundo é o mapa de cadeiras. Para cada rota antiga afetada, ele registra fonte da cadeira, titular quando público, limite normal de mandato e estado de saída: concluído, renunciado, substituído, retorno somente a Regular Member, candidatura à nova classe ou não publicado. Para as novas cadeiras, registra quais das cinco possíveis estão preenchidas, vagas ou sem estado público. Ausência de nome não deve ser tratada automaticamente como prova de vacância.

O terceiro bloco trata de elegibilidade e eleitorado. Reproduz o requisito de candidatura e as categorias eleitorais da Carta, com total datado de eleitores ou método de auditoria preservado. Não precisa expor a justificativa privada de cada pessoa; precisa tornar inteligível o denominador usado no resultado.

O quarto conecta procedimento e resultado: issue de indicação, método efetivamente usado quando divulgado, aviso de resultado, pull request do README, data de vigência e lista resultante de Voting Members. A Carta cita métodos possíveis, como Condorcet e voto único transferível. Ela não autoriza presumir qual foi empregado em determinado ciclo.

O quinto é a verificação de composição: total de Voting Members na data de efeito, base pública de afiliação quando disponível, teto de um quarto e situação — conforme, corrigido, pendente ou não publicado. Conferir uma condição da Carta não é alegar conflito.

Por fim, o registro deve ter limite de autoridade e log de correções. Ele separa Board, CPC, CPC Directors e autonomia dos projetos, e nomeia o que os materiais públicos não provam: motivo privado de elegibilidade, total de votos não divulgado, renúncia posterior ou decisão do Board. Uma correção passa a ser acréscimo datado, e não uma alteração silenciosa de roster.

Governança aberta não significa que toda pessoa participante detenha todo poder. Significa que cada poder efetivo tem origem, alcance e estado final visíveis. A transição de outono dá à OpenJS a oportunidade de registrar essa diferença no momento em que ela passa a importar.

Fontes

1. OpenJS Cross Project Council Charter
2. OpenJS Cross Project Council Governance
3. OpenJS Cross Project Council repository and current roster
4. OpenJS Foundation Governance archive
5. Lu Heng — The Multi-Stakeholder Mirage