Resumen

  • La Carta del CPC sustituye, desde el ciclo electoral de otoño de 2026, las representaciones votantes no-Impact y de Regular Members por hasta cinco Community Voting Members.
  • Ser observador, ser Regular Member, formar parte del electorado y ocupar un puesto de voto son hechos distintos. Para la nueva clase, la candidatura exige ser Regular Member y no representar a un proyecto Impact; votan los Impact Project Voting Members y los Regular Members.
  • El cambio necesita un registro que una estado del ciclo, asiento anterior, elegibilidad, denominador del electorado, resultado, afiliación empresarial y competencia de Board, CPC y proyectos, sin inventar un mandato general ni un resultado aún no publicado.

La reforma anunciada no equivale a una elección realizada

Los documentos de gobernanza pueden describir con precisión el futuro y, aun así, no acreditar el presente. Que una Carta se modifique, que una reunión se abra a observadores o que una lista anuncie una clase próxima son hechos importantes. Ninguno demuestra que se emitieron votos, que el padrón se cerró o que una persona obtuvo un derecho de decisión en una fecha concreta.

La estructura de OpenJS permite separar esas cosas. Su Carta sitúa al Cross Project Council, el CPC, como liderazgo técnico de la Fundación y al Board como liderazgo empresarial. El Board fija la política general del CPC; el CPC actúa como órgano técnico delegado dentro de ese marco. A partir del ciclo de otoño de 2026, las dos vías no-Impact —representantes de proyectos no-Impact y representantes de Regular Members— pasan a una clase única de Community Voting Members.

La fuente es explícita sobre el diseño futuro. No dice que las candidaturas ya se hayan abierto, que exista un recuento, que los cinco puestos estén cubiertos ni que una persona determinada esté sentada. Presentar el cambio como elección ya consumada sustituiría evidencia por anticipación.

La diferencia importa porque, una vez iniciado el ciclo, un colaborador debería poder reconstruir el estado de cada asiento sin depender de relatos internos. ¿El representante anterior concluyó el mandato, renunció, fue reemplazado, se convirtió en Regular Member o se postuló para la nueva clase? ¿Cuántos de los cinco puestos posibles se ocuparon? ¿Cuál fue el total de votantes admisibles? ¿Se verificó el límite de afiliación de un mismo empleador sobre el conjunto correcto de Voting Members? ¿La decisión examinada correspondía al Board, al CPC o al órgano de un proyecto?

No son preguntas acusatorias. Son las columnas mínimas que evitan que una página de nombres parezca, retrospectivamente, una delegación de poder sin fuente.

Cuatro capas que la palabra “comunidad” puede ocultar

La Carta diferencia Observers, Regular Members y Voting Members. El repositorio del CPC permite que personas ajenas asistan como observadores. La gobernanza del CPC establece cómo una persona con actividad sostenida como OpenJS Collaborator puede solicitar ser Regular Member. Para la nueva elección, el electorado es aún más específico: Impact Project Voting Members y Regular Members.

Un Observer puede presenciar trabajo público y participar en la búsqueda de consenso. Esa participación es valiosa, pero no convierte a la persona en votante ni en titular de un asiento.

Un Regular Member tiene una condición institucional más definida. Debe acreditar actividad reciente y sostenida en un proyecto, comunidad, espacio de colaboración o trabajo del CPC, y pasa por un proceso de revisión. Esa condición permite postularse a la nueva clase y forma parte de su electorado. No constituye por sí misma una elección.

Un Impact Project Voting Member llega por otra ruta: cada proyecto Impact puede nominar hasta dos representantes con su propio procedimiento. La nueva arquitectura conserva esa clase. Que esos miembros participen en la elección comunitaria no borra la fuente de sus propios puestos.

El Community Voting Member será una clase de voto delimitada, de hasta cinco asientos. La candidatura requiere ser Regular Member y no estar sirviendo como representante votante de un proyecto Impact. Por eso, decir que “la comunidad eligió” puede confundir cuatro proposiciones: quién asistió, quién logró membresía regular, quién integró el electorado y quién resultó elegido. La Carta fija las categorías; un expediente de resultado debe probar el hecho electoral.

La regla de Lu Heng resulta particularmente útil: participar aporta experiencia, advertencias y objeciones; no crea automáticamente autoridad principal sobre todo afectado. Una reunión abierta o una elección interna de OpenJS prueban un procedimiento interno definido. No prueban que el CPC represente por mandato a todo el ecosistema de JavaScript.

El asiento nuevo no absorbe los demás poderes

El cambio de clase no altera toda la distribución de autoridad. Los Voting Members tienen las responsabilidades finales que la Carta asigna al CPC. El CPC procura consenso y utiliza un procedimiento de voto cuando la objeción no puede resolverse. El Board conserva la política general, competencias especialmente legales y la aprobación de cambios de Carta. Los proyectos siguen siendo entidades autogobernadas en sus decisiones técnicas documentadas.

Hay enlaces reales entre las capas sin que se conviertan en una sola. Un CPC Director representa proyectos y comunidades ante el Board. Un cambio de carta de proyecto puede requerir aprobación del CPC. Un asunto técnico puede tener que escalarse. Pero un Community Voting Member no pasa, por ello, a ser director del Board, representante de todos los mantenedores o decisor interno de un proyecto. El registro debe mostrar la capacidad que realmente tiene cada persona.

La gobernanza existente ofrece superficies de prueba: una issue pública al inicio de las nominaciones, una pull request para actualizar el README después de la elección, una nota privada de resultados, agendas y materiales de reunión. También reconoce información legítimamente privada en asuntos personales, legales y algunas comunicaciones del Board. La transparencia no exige publicar expedientes privados; exige que los hechos públicos decisivos se puedan conectar.

Una lista de README por sí sola no da fecha de mandato, resultado del asiento anterior ni denominador electoral. La política prevé que quien termina como Voting Member se convierta normalmente en Regular Member, salvo indicación contraria. Es una disposición predeterminada útil, no un comprobante individual de salida. Y “hasta cinco” no dice cuántos puestos se llenaron. El límite de un cuarto de miembros votantes afiliados a un mismo empleador tampoco es comprobable sin un total fechado y una base de afiliación.

El recibo de transición de Community Voting Members

Daniel Kade propone un registro de transición de Community Voting Members. No sustituye a la Carta ni solicita divulgar evaluaciones privadas. Reúne datos que, de otro modo, permanecerían repartidos entre issues, agendas, listas y cambios de repositorio.

Primero debe constar el estado del ciclo: transición prevista, nominaciones abiertas, votación en curso, resultado certificado o corrección. Ha de enlazar la redacción vigente de la Carta y llamar por su nombre a las clases antigua y nueva. Así una regla futura no se vuelve, por simple lectura, una designación realizada.

Segundo, una cartografía de asientos debe registrar para cada ruta afectada la fuente del asiento, titular público, final ordinario de mandato y estado de salida: concluido, renunciado, reemplazado, convertido sólo en Regular Member, candidato a la nueva clase o no publicado. Para la nueva clase debe indicar cuáles de los cinco asientos posibles están cubiertos, vacantes o sin estado público. La falta de un nombre no puede convertirse automáticamente en una vacante afirmada.

Tercero, el bloque de elegibilidad y electorado debe repetir los requisitos de candidatura y las categorías electorales de la Carta, con un total fechado del electorado o una metodología de auditoría retenida. No necesita exponer el motivo privado de cada elegibilidad. Sí necesita hacer inteligible el denominador que da sentido a un resultado.

Cuarto, el registro debe enlazar procedimiento y resultado: issue de nominación, método electoral realmente usado si se divulga, aviso de resultado, pull request del README, fecha de eficacia y composición resultante. La Carta ofrece métodos posibles, como Condorcet o voto único transferible; no autoriza a presumir cuál se aplicó en un ciclo concreto.

Quinto, debe incluirse el control de composición: número total de Voting Members en la fecha eficaz, base pública de afiliación cuando exista, techo de un cuarto y estado de la revisión. Verificar una condición de la Carta no equivale a alegar un conflicto.

Por último, una frontera de autoridad y bitácora de correcciones distingue las competencias de Board, CPC, Directors y proyectos, y conserva lo que los materiales no acreditan: una razón privada de elegibilidad, un conteo no publicado, una dimisión posterior o una decisión del Board. Corregir el expediente será entonces añadir un hecho fechado, no sobrescribir silenciosamente un listado.

La gobernanza abierta no significa que cada participante posea todos los poderes. Significa que cada poder real tiene fuente, alcance y estado final visibles. La transición de otoño ofrece a OpenJS la oportunidad de dejar ese rastro mientras se produce.

Fuentes

  1. Carta del Cross Project Council de OpenJS
  2. Gobernanza del Cross Project Council de OpenJS
  3. Repositorio y lista actual del Cross Project Council
  4. Archivo de Governance de OpenJS Foundation
  5. Lu Heng — El espejismo de las múltiples partes interesadas