Gobernanza, hoja de ruta y cómo contribuir

Un estándar sirve de poco si no sabes quién decide qué entra en él. Los nueve capítulos anteriores cubrieron el contrato portable. Este cubre lo otro: quién manda sobre ese contrato, con qué licencia puedes reutilizarlo, qué se dejó deliberadamente fuera de la 1.0.0 y qué hay que hacer para que una idea tuya llegue a la siguiente versión. La propia especificación delega el tema en un documento aparte: su §1.1 dice que la gobernanza del proyecto se define por separado del formato portable de paquete, en el Technical Charter alojado en GOVERNANCE.md. Formato y gobierno son superficies distintas a propósito.

Qué documento manda sobre qué

El mapa de autoridad del repositorio: confundir estas capas es el error más común al leer un estándar joven.

Documento	Carácter	Sobre qué manda
spec/1.0.0.md	Normativo	El contrato portable. Es la autoridad final
schemas/1.0.0/plugin.schema.json	Normativo, legible por máquina	Estructura del manifiesto
schemas/1.0.0/mcp.schema.json	Normativo, legible por máquina	Estructura de mcp.json
README.md	No normativo	Introducción. Lo dice él mismo en su línea 5
FUTURE_CONSIDERATIONS.md	No normativo	Ideas para versiones futuras. No compromete nada
GOVERNANCE.md	Gobierno del proyecto	Roles, votaciones, licencias, marcas
MAINTAINERS.md	Registro	Quiénes son hoy los Core Maintainers
CONTRIBUTING.md	Proceso	Cómo se proponen y revisan cambios
AGENTS.md	Criterio editorial	Cómo debe pensarse un cambio propuesto

Hay dos reglas de precedencia explícitas que conviene memorizar, y las dos están en la propia especificación. La primera la enuncian §5.2 y §7.2.1 con la misma frase —“The specification text is authoritative if it conflicts with the schema”—, y AGENTS.md la repite como criterio editorial del repositorio: si tu validador y la prosa discrepan gana la prosa, y la discrepancia es un bug del schema que merece un Issue. La segunda está en el Anexo A: la checklist de conformidad es solo por conveniencia y, cuando choca con el texto, gobierna el texto.

El Technical Charter

GOVERNANCE.md no es un README de comunidad: es un Technical Charter formal de 158 líneas con once secciones numeradas, que fija responsabilidades y procedimientos para contribuir técnicamente al proyecto y supervisarlo. Define además un término paraguas: Collaborators abarca a todos los participantes, incluidos Maintainers, Core Maintainers, el Lead Core Maintainer y cualquier otro rol técnico. Todos deben cumplir el Charter.

Misión y alcance

La misión declarada es definir, mantener y promover una especificación abierta y neutral respecto de proveedores para empaquetar componentes reutilizables que extienden agentes de IA en plugins distribuibles. El alcance no se agota en el texto: incluye la especificación, implementaciones de referencia, tests de conformidad, documentación, y herramientas y otros artefactos que sostengan clientes, paquetes de plugin y ecosistemas interoperables.

Y la frase que explica el porqué de todo: el proyecto existe para habilitar portabilidad, competencia y estabilidad de largo plazo de los paquetes de plugin entre proveedores y plataformas. Ese trío es la vara con la que se mide cualquier propuesta.

Roles y estructura

La estructura es jerárquica y tiene cuatro niveles:

Rol	Definición del Charter
Contributor	Cualquiera que envía código, documentación, especificación, issues u otros artefactos técnicos
Maintainer	Contributor con acceso de commit a uno o más repositorios del proyecto
Core Maintainer	Maintainer responsable de la dirección técnica general y de la integridad de la especificación
Lead Core Maintainer	Un Core Maintainer designado como decisor técnico final cuando no se alcanza consenso

Dos cláusulas antimonopolio marcan el carácter del proyecto: todos los roles de gobernanza los ostentan individuos, no organizaciones, sin asientos reservados para empresas concretas; y ningún proveedor puede controlar la mayoría de los asientos de Core Maintainer.

El Technical Steering Committee (TSC) está formado por todos los Core Maintainers junto con el Lead, y es responsable de toda la supervisión técnica del proyecto. Sus reuniones son abiertas y pueden ser electrónicas o presenciales. La lista vigente se registra en el archivo MAINTAINERS, y el TSC puede definir métodos alternativos de selección o rotación siempre que los documente públicamente.

flowchart LR
    CT[Contributors<br/>envian artefactos tecnicos]
    MT[Maintainers<br/>acceso de commit]
    CM[Core Maintainers<br/>direccion e integridad]
    LD[Lead Core Maintainer<br/>decisor final]
    CT -->|mayoria del TSC| MT
    MT -->|mayoria del TSC| CM
    CM -->|designacion| LD
    subgraph TSC[Technical Steering Committee]
        CM
        LD
    end

Promoción y remoción

Salvo que se documente otra cosa, las reglas son simétricas menos en la cúspide:

Movimiento	Requisito
Contributor a Maintainer	Aprobación por mayoría del TSC
Maintainer a Core Maintainer	Aprobación por mayoría del TSC
Remoción de un Maintainer	Aprobación por mayoría del TSC
Remoción de un Core Maintainer	Decisión del Lead Core Maintainer tras consultar al TSC
Remoción del Lead Core Maintainer	Súper-mayoría del 75 % de todos los Core Maintainers, excluido el titular

El Lead ejerce además como presidente del TSC salvo que se designe a otro Core Maintainer. Para nominar a un Core Maintainer basta con que lo proponga cualquier Maintainer o Core Maintainer. El Lead evalúa la nominación según cuatro criterios explícitos —contribución técnica, alineación con los principios del proyecto, conducta en la comunidad y neutralidad multi-proveedor— y después confirma o rechaza públicamente la nominación con razones declaradas. En sentido inverso, cualquier Collaborator puede proponer remover a un Core Maintainer; los restantes, excluidas las partes en conflicto de interés, revisan y publican una decisión.

Si el puesto de Lead queda vacante por remoción, renuncia o indisponibilidad permanente, los Core Maintainers eligen uno nuevo mediante un método de consenso o de voto por orden de preferencia documentado en CONTRIBUTING. Dato comprobable hoy: el CONTRIBUTING.md publicado tiene 24 líneas y cubre solo propuestas, issues y pull requests; ese método de selección todavía no está escrito ahí.

Qué decide el TSC

La §6 lista nueve responsabilidades: custodiar la especificación; aprobar cambios, extensiones y deprecaciones; gestionar implementaciones de referencia y suites de tests; establecer políticas de release, compatibilidad y versionado; crear grupos de trabajo; nombrar enlaces con otros cuerpos de estándares o proyectos open source; definir los flujos de contribución y revisión; resolver disputas técnicas; y coordinar las comunicaciones. La cuarta conecta con el capítulo 7: que cada release publique ambos schemas con la misma versión no es una casualidad de implementación, es una decisión de gobierno.

Cómo se vota

El proyecto busca consenso. Solo cuando hace falta votar aplican estas reglas:

Regla	Valor
Voto por miembro del TSC	Uno
Quórum	50 % de los miembros del TSC
Decisión ordinaria	Mayoría de los presentes, salvo que se especifique otra cosa
Voto electrónico	Mayoría de todos los miembros del TSC
Licencias alternativas para materiales concretos	Dos tercios
Enmienda del Charter	Dos tercios del TSC completo

El voto electrónico exige mayoría del total, no de los presentes: es una salvaguarda contra decisiones tomadas por un puñado de personas en un hilo asincrónico. Si el TSC no logra resolver una disputa, el Lead actúa como voto de desempate; y si aun así queda sin resolver, el TSC puede convocar un subcomité especial formado por miembros del TSC para elaborar una recomendación que el propio TSC considerará finalmente.

flowchart TD
    P[Propuesta tecnica] --> CS{Hay consenso}
    CS -->|si| OK[Se adopta]
    CS -->|no| V[Votacion del TSC con quorum del 50 por ciento]
    V -->|mayoria| OK
    V -->|empate o bloqueo| LD[Desempate del Lead Core Maintainer]
    LD -->|sigue sin resolverse| SC[Subcomite especial elabora recomendacion]
    SC --> V

Principios de comunidad, activos y marcas

Tres compromisos cortos con consecuencias: el proyecto opera de forma abierta, transparente y colaborativa; nadie, persona u organización, puede ser excluido salvo por incumplir reglas documentadas aplicadas de forma equitativa a todos; y todas las propuestas, decisiones y discusiones técnicas deben ser públicamente accesibles.

Sobre identidad: el nombre Agent Plugins, los logos asociados, los dominios y las organizaciones de GitHub se mantienen en fideicomiso para el proyecto por una entidad neutral designada por el TSC, y ningún proveedor puede reclamar propiedad o control exclusivo de la identidad o la infraestructura. Esto es lo que evita que el estándar quede secuestrado si una de las empresas participantes cambia de estrategia.

Los mantenedores actuales

MAINTAINERS.md es el registro vivo al que apunta la §2 del Charter. Aclara que las afiliaciones identifican a las organizaciones que esas personas representan en las discusiones de especificación, pero que los roles de gobernanza los ostentan los individuos listados.

Core Maintainer	Afiliación
Clare Liguori	Amazon
Roshan Sadanani	Cursor
Harald Kirschner	Microsoft
Gav Verma	OpenAI
Jonathan Hefner	Vercel

Lead Core Maintainer: Jonathan Hefner.

Cinco asientos, cinco organizaciones distintas: con esa composición, la regla de que ningún proveedor controle la mayoría se cumple con margen. Ninguna de esas cinco organizaciones puede imponer por sí sola una forma nativa de configurar MCP sin convencer a las otras cuatro; en el capítulo 5 viste el resultado: una unión cerrada de tres variantes de transporte cuyo significado es independiente de cualquier formato nativo.

Licenciamiento: dos licencias, un repositorio

La §9 del Charter fija la propiedad intelectual y LICENSE.md la detalla. Lo primero: los contribuyentes conservan el copyright de sus contribuciones, no hay cesión de derechos. Salvo que el TSC apruebe otra cosa, y salvo que un archivo lleve su propio aviso de licencia:

Material	Licencia	Archivo
Texto de la especificación, documentación, ejemplos, imágenes y diagramas de autoría propia	Creative Commons Attribution 4.0	LICENSES/CC-BY-4.0.txt
Schemas, código fuente, scripts y demás material de software	Apache License 2.0	LICENSES/Apache-2.0.txt

El directorio LICENSES/ contiene ambos textos completos, no referencias: CC-BY-4.0.txt con 395 líneas y Apache-2.0.txt con 202.

Dos cláusulas más de LICENSE.md que suelen pasarse por alto: el material de terceros sigue sujeto a su licencia original y a sus requisitos de atribución; y las contribuciones enviadas intencionalmente para su inclusión se entregan bajo la licencia aplicable al material que modifican o añaden, así que editar prosa entra como CC-BY-4.0 y editar un schema como Apache 2.0. El TSC puede aprobar licencias alternativas para materiales concretos por dos tercios.

Qué significa esto para tu proyecto

• Copias plugin.schema.json a tu repositorio para validar en CI, como en el capítulo 8: es software, aplica Apache 2.0 y conservas su aviso de copyright y licencia.
• Citas párrafos de la spec en documentación interna o la traduces: es texto, aplica CC-BY-4.0 y debes atribuir la fuente, aclarando además que una traducción tuya no es oficial.
• Escribes tu propio plugin: es tuyo. Nada del licenciamiento del estándar se propaga a los paquetes que lo cumplen; conformar no es derivar.

Lo que quedó fuera de la 1.0.0 a propósito

FUTURE_CONSIDERATIONS.md es un documento de 64 líneas que abre con una advertencia que hay que citar entera antes de leer nada más: registra posibles áreas para versiones futuras de la especificación, es no normativo, y ninguno de sus ítems es requerido para conformidad ni está comprometido para inclusión en un release futuro. Es decir: una lista de problemas reconocidos, no una hoja de ruta con fechas. Trátalo como inventario de riesgos que hoy debes mitigar tú. Hay siete áreas; una sola dice que una versión futura debería abordarla y las otras seis que podría definirla, diferencia editorial —no normativa— que indica dónde está la presión.

1. Permisos y UX de aprobación

La 1.0.0 no define modelo de confianza, sistema de permisos ni requisitos de sandboxing. Lo que se apunta para el futuro: declaraciones de permisos en el manifiesto —por ejemplo acceso a sistema de archivos, a red o a herramientas—, restricciones de capacidad por plugin impuestas por el cliente, flujos de consentimiento del usuario para instalar y otorgar capacidades, UX de aprobación para servidores MCP que ejecutan comandos arbitrarios o acceden a servicios externos, y niveles graduados de confianza del estilo sandboxed, aprobado por el usuario y aprobado por la organización.

Es la única área redactada con “debería abordar”.

2. Verificación de procedencia

La 1.0.0 no especifica cómo clientes o usuarios pueden verificar el origen o la integridad de un plugin. En el futuro podría definirse verificación de firmas criptográficas, cadenas de atestación que enlacen el plugin publicado con su repositorio y su build, y políticas de cliente para exigir firmas de publicadores de confianza. Es el hueco que más pesa sobre el capítulo 9: hoy la confianza descansa en el canal por el que obtuviste el plugin, no en el paquete.

3. Manejo de secretos y valores sensibles

Los servidores MCP suelen necesitar credenciales o claves de API en tiempo de ejecución, y la 1.0.0 no especifica cómo deben proveerse, almacenarse ni acotarse. Se considera un campo secrets en el manifiesto o una configuración separada, inyección mediada por el cliente que evite texto plano en archivos de configuración, reglas de alcance que impidan que un plugin acceda a los secretos de otro, y semántica de rotación y revocación. Recuerda del capítulo 5 que la 1.0.0 sí resuelve una parte adyacente: los valores de headers en transportes HTTP deben ser literales y la expansión de variables se limita a ${PLUGIN_ROOT} y ${PLUGIN_DATA} en args, env y cwd. Lo que falta es de dónde sale el secreto, no cómo se escribe.

4. Controles empresariales

Las organizaciones que despliegan plugins a escala necesitan aplicación de políticas que la 1.0.0 no aborda: listas de permitidos y bloqueados por nombre, publicador o firma; registros de plugins con alcance de organización y flujos de aprobación; overrides centralizados de configuración con precedencia sobre los ajustes del usuario; y reporte de cumplimiento de instalación y uso.

5. Estandarización del rastro de auditoría

La 1.0.0 define requisitos de reporte de fallos, pero no estandariza esquemas de eventos de diagnóstico ni de ciclo de vida. Se considera un esquema estándar para instalar, habilitar, deshabilitar, actualizar y desinstalar, con campos recomendados de marca de tiempo, actor —usuario o automatización—, nombre del plugin, versión, acción y resultado; puntos de integración para reenviar eventos a logging externo o SIEM; y políticas de retención y acceso.

6. Resolución de dependencias

Hoy los plugins no pueden declarar dependencias de otros plugins. Se considera un campo dependencies con restricciones de versión, orden de resolución y manejo de conflictos transitivos, y semántica de peer dependencies.

7. Testing y validación

No hay harness de test ni herramienta de validación especificada. Se considera un campo o convención test, un linter o validador estándar invocable por comando, y suites de tests de conformidad para implementaciones de cliente.

Tabla de mitigación

Área abierta	Cómo mitigarla hoy
Permisos y confianza	Revisar mcp.json a mano antes de instalar; preferir streamable-http a stdio para plugins de terceros
Procedencia	Fijar el plugin a un tag o commit y verificarlo en el pin; publicar checksums junto al release
Secretos	Mantener credenciales fuera del paquete; el cliente decide el entorno base del subproceso
Controles de organización	Espejo interno del repositorio y política de instalación fuera del estándar
Auditoría	Registrar instalaciones en tu propio pipeline
Dependencias	Empaquetar lo necesario dentro del plugin o instalarlo en PLUGIN_DATA
Testing	Validar con los dos JSON Schema en CI, como en el capítulo 8

El otro “fuera de alcance”, este sí en la spec

Además de FUTURE_CONSIDERATIONS.md, la sección de Design Decisions de la propia especificación explica por qué v1 se limita a Agent Skills y MCP: ambos tienen especificaciones establecidas fuera de este proyecto y adopción significativa entre clientes. Otros tipos de componente propuestos —commands, hooks, agents, rules y servidores LSP— siguen siendo demasiado específicos de cada cliente para un contrato portable estable, y quedan fuera del formato v1 hasta que sus formatos converjan. Esa es la puerta que deja abierta el mecanismo de extensiones del capítulo 3: mientras no converjan, cada cliente los coloca bajo su namespace de dominio inverso.

Cómo contribuir

La premisa de CONTRIBUTING.md: Agent Plugins define un contrato de interoperabilidad pequeño y portable para autores de plugins e implementadores de clientes, y los cambios a ese contrato solo tienen éxito cuando los implementadores relevantes pueden adoptarlos de forma consistente.

Propuestas de especificación

Para una funcionalidad nueva o un cambio material de comportamiento, empieza por una GitHub Discussion antes de abrir un pull request. La propuesta debe explicar cuatro cosas:

1. El problema concreto de implementación o interoperabilidad.
2. Qué autores de plugins o implementadores de clientes lo encuentran.
3. Por qué el problema pertenece a la especificación portable y no a la política de un cliente o a una extensión específica de cliente.
4. Qué implementadores están preparados para adoptar el comportamiento propuesto.

Y la advertencia que ahorra trabajo perdido: un pull request técnicamente completo no es, por sí solo, evidencia de consenso o adopción por parte de los implementadores, y los mantenedores pueden cerrar propuestas que no hayan establecido una necesidad concreta de portabilidad o suficiente apoyo. Ante la duda, Discussion antes que parche.

Bugs, correcciones editoriales y pull requests

Los GitHub Issues son para defectos concretos: contradicciones, referencias rotas, desajustes entre schema y prosa, o requisitos poco claros que puedan llevar a implementaciones incompatibles. Las correcciones editoriales pequeñas y autocontenidas sí pueden enviarse directamente como pull request. Sobre los PR, tres reglas:

• Mantén cada uno enfocado en un cambio revisable de forma independiente.
• Cuando el cambio afecta al contrato portable, actualiza todas las superficies relevantes a la vez: prosa normativa, schemas, ejemplos, identificadores canónicos, referencias y la checklist de conformidad.
• Describe el problema de interoperabilidad y el contrato resultante, incluye la validación realizada y enlaza la Discussion o el Issue previos si existen.

flowchart TD
    I[Idea o problema] --> T{Que tipo es}
    T -->|Funcionalidad o cambio de comportamiento| D[GitHub Discussion<br/>con las cuatro preguntas]
    T -->|Defecto concreto| IS[GitHub Issue]
    T -->|Correccion editorial pequena| PR2[Pull request directo]
    D --> SUP{Hay necesidad de portabilidad<br/>y apoyo de implementadores}
    SUP -->|no| CL[Los mantenedores pueden cerrarla]
    SUP -->|si| PR[Pull request enfocado]
    IS --> PR
    PR --> SUR[Actualizar todas las superficies<br/>prosa schemas ejemplos referencias checklist]
    SUR --> RV[Revision del TSC]
    PR2 --> RV

AGENTS.md: el criterio con el que te van a evaluar

AGENTS.md está escrito para agentes que proponen cambios, pero es la mejor guía disponible para cualquier humano que quiera que su propuesta prospere: declara la autoridad de los archivos y describe los instintos de diseño que deben dar forma a los cambios propuestos. Su postura de diseño es lo que más peso tiene en una revisión:

• Definir el piso mínimo genuinamente portable, no un sistema universal de plugins ni la unión de los comportamientos existentes de los clientes, y estandarizar algo solo cuando pueda implementarse de forma consistente entre clientes y sirva a una necesidad de portabilidad demostrada.
• Optimizar para implementaciones de cliente simples y robustas: evitar opcionalidad innecesaria, reglas de precedencia, indirección configurable, rutas de compatibilidad y abstracciones especulativas.
• Preferir convenciones fijas, layouts planos y semántica determinista. La configuración debe aportar información, no meramente activar contenido que el cliente ya puede descubrir.
• Preferir resolver problemas eliminando o simplificando texto antes que añadiendo salvedades o maquinaria, y mantener fuera del núcleo portable la política del cliente, su UX y su presentación.
• Usar lenguaje normativo solo cuando un contrato de interoperabilidad o de seguridad lo exija, y considerar la implementabilidad multiplataforma antes de imponer requisitos.

Esos puntos explican de golpe muchas decisiones que viste en el curso: por qué skills/ y mcp.json están en ubicaciones fijas en vez de configurables, y por qué el manifiesto raíz es cerrado. Sobre fronteras de portabilidad añade dos ideas: los namespaces propiedad del cliente siguen siendo del cliente, y no se estandariza su validación interna, dependencias ni comportamiento ante fallos sin una necesidad de interoperabilidad demostrada; y el comportamiento definido por la implementación se usa intencionalmente en fronteras genuinas de portabilidad, no para evitar especificar algo necesario para interoperar.

Su disciplina editorial incluye una pregunta aplicable a cada frase que propongas: qué error concreto o qué fallo de interoperabilidad previene esta oración. Si no hay respuesta convincente, mejor borrarla. Y sobre schemas: se usan para hacer cumplir hechos estructurales que expresan con claridad, sin contorsionarlos para aproximar requisitos de comportamiento, mientras que prosa, schemas, ejemplos, identificadores canónicos, referencias y checklist de conformidad se tratan como una sola superficie conceptual.

Autoevaluación antes de abrir la Discussion

Checklist derivado de CONTRIBUTING.md y AGENTS.md. No es un formulario oficial del proyecto, es una destilación para tu uso:

## Problema
- Fallo concreto de implementación o interoperabilidad:
- Quién lo sufre: autores de plugins / implementadores de clientes

## Por qué es portable
- Por qué no basta con política de cliente o extensión de dominio inverso:
- Qué se rompe hoy entre dos clientes conformes:
- Implementadores dispuestos a adoptarlo:

## Forma del cambio
- ¿Añade opcionalidad, precedencia o indirección? ¿Se puede evitar?
- ¿Se puede resolver quitando texto en lugar de añadiéndolo?
- Superficies a tocar y validación realizada:

Cierre: la trilogía completa

Este curso es la pieza central de tres que encajan en capas.

flowchart TD
    A[Agent Skills<br/>formato SKILL.md<br/>que sabe hacer el agente] --> B[Agent Plugins<br/>plugin.json y mcp.json<br/>como se empaqueta y se mueve]
    B --> C[Catalogos reales<br/>como el repositorio de Google<br/>como se publica y se consume]
    C -.->|el uso real informa el estandar| B

• Agent Skills define el formato SKILL.md que un plugin empaqueta. Agent Plugins no lo redefine: su §7.1 delega en esa especificación externa y solo fija dónde viven los skills.
• Agent Plugins, este curso, define el contenedor portable: manifiesto, ubicaciones fijas, configuración MCP, variables de plugin, reglas de carga y conformidad de cliente.
• Google Skills muestra un catálogo real, con skills y plugins publicados, para ver qué aspecto tiene todo esto cuando lo mantiene una organización a escala.

En qué orden aplicarlos

1. Empieza por Agent Skills si todavía no tienes contenido: un plugin sin skills útiles es un envoltorio vacío.
2. Sigue con Agent Plugins cuando quieras que ese contenido viaje a otra máquina, a otro cliente o a otro equipo. Ahí empieza a pagar el manifiesto.
3. Termina con Google Skills cuando vayas a publicar: ver un catálogo mantenido de verdad ahorra decisiones sobre estructura de repositorio, granularidad y nomenclatura.

Los nueve capítulos previos siguen ese mismo recorrido: del problema de portabilidad y el primer plugin al manifiesto, los skills y los servidores MCP, y de ahí al descubrimiento, el versionado, la validación y la distribución.

Próximos pasos concretos

• Lee spec/1.0.0.md completo de una sentada: son 640 líneas y ya conoces todos sus conceptos.
• Recorre el Anexo A marcando qué cumple tu plugin y qué cumpliría un cliente que quisieras escribir.
• Añade la validación de plugin.json y mcp.json a tu CI, y fija por escrito qué versión targetean tus paquetes y quién decide cuándo se sube.
• Elige uno de los siete huecos de FUTURE_CONSIDERATIONS.md que te afecte de verdad y escribe cómo lo mitigas hoy, fuera del estándar.
• Suscríbete a las Discussions del repositorio: si tu caso de uso no está representado en el TSC, esa es tu vía de entrada.
• Si al implementar encuentras una contradicción real entre prosa y schema, abre un Issue. Es justo el tipo de contribución que CONTRIBUTING.md pide.

Resumen

• La especificación delega la gobernanza en el Technical Charter de GOVERNANCE.md, separado del formato portable. Su jerarquía es Contributors, Maintainers, Core Maintainers y un Lead Core Maintainer que decide en última instancia; el TSC son los Core Maintainers más el Lead.
• Los roles son de individuos, no de organizaciones, y ningún proveedor puede controlar la mayoría de asientos: hoy son cinco personas de cinco empresas distintas, con Jonathan Hefner como Lead.
• Se busca consenso; al votar, el quórum es del 50 %, las decisiones ordinarias por mayoría de presentes, los votos electrónicos por mayoría del total, y las enmiendas al Charter y las licencias alternativas requieren dos tercios.
• Licenciamiento dual: texto bajo CC-BY-4.0, schemas y código bajo Apache 2.0, con ambos textos en LICENSES/; los contribuyentes conservan su copyright.
• FUTURE_CONSIDERATIONS.md lista siete áreas abiertas —permisos, procedencia, secretos, controles empresariales, auditoría, dependencias y testing— y declara que es no normativo y que nada está comprometido.
• Para contribuir: Discussion antes que PR en cambios de comportamiento, Issues para defectos, PRs enfocados que actualicen todas las superficies a la vez. Un PR técnicamente completo no prueba consenso de implementadores, y AGENTS.md fija el criterio: el piso mínimo genuinamente portable, sin opcionalidad ni abstracciones especulativas, con la política y la UX del cliente fuera.