Gobernanza

OSIRIS JSON es un Open Standard diseñado para poder revisarse abiertamente y ser impulsado por la comunidad.
Esta página explica cómo se proponen, revisan y publican los cambios.

[!Info] Modelo actual de mantenimiento OSIRIS JSON actualmente es mantenido por un único maintainer principal. Las contribuciones son bienvenidas desde el inicio, pero el proceso es intencionalmente ligero para mantener v1.0 manejable y consistente.

Roles

Maintainer

Es responsable de la calidad y coherencia del texto de la especificación, schemas, producers, ejemplos y notas de lanzamiento. Asegura que los cambios preserven la vendor-neutrality, la claridad y las expectativas de compatibilidad.

Contributor

Propone mejoras mediante issues y pull requests: correcciones, aclaraciones, ejemplos nuevos, producers nuevos y guías de implementación.

Reviewer

Miembros de la comunidad que aportan criterio técnico, revisión y retroalimentación. La revisión es especialmente valiosa para cambios normativos e impactos de versionado.

Dónde se toman las decisiones

GitHub discussions: discusiones de diseño, preguntas y retroalimentación temprana.
GitHub issues: bugs, inconsistencias y propuestas para cambiar la especificación.
Pull requests: el lugar autoritativo donde se cambian y revisan el texto, los schemas y los ejemplos.

Principios para la toma de decisiones

OSIRIS JSON sigue los principios de diseño de la especificación con enfoque en:

Simplicidad
Neutralidad frente a vendors
Extensibilidad sin fragmentación
Explícito sobre implícito
Estabilidad y compatibilidad

El modelo de decisión predeterminado es rough consensus mediante discusión pública y revisión. Cuando no se puede alcanzar consenso, el lead maintainer toma una decisión y documenta la justificación en el PR o issue.

Proceso de cambio

Discutir

Abrir un issue (o discussion) describiendo el problema y el cambio previsto

Implementar

Enviar un PR que actualice el texto de la spec y, cuando aplique, schemas/examples

Revisar

Revisar exactitud, consistencia e impacto en la compatibilidad

Merge & release

Los cambios fusionados se publican de acuerdo con SemVer y las reglas de deprecación

Tipos de cambios

Editorial (no normativo)

Corregir typos, mejorar claridad, reestructurar secciones, mejorar ejemplos sin cambiar requisitos.

Normativo

Cambios que alteran requisitos o interpretación (reglas MUST/SHOULD/MAY), comportamiento de validación o expectativas de compatibilidad. OSIRIS JSON usa el formato JSON ampliamente soportado y se alinea con convenciones establecidas, incluyendo JSON Schema para validación estructural y palabras clave de RFC 2119 para requisitos normativos.

Taxonomía / registry / guía de extensiones

Actualizaciones que afectan la interpretación de tipos estándar, namespaces recomendados o mejores prácticas de extensiones.

Versionado, compatibilidad y releases

OSIRIS JSON usa Semantic versioning 2.0.0 para los releases de la especificación.
El campo version en un documento OSIRIS JSON declara con qué versión de la especificación cumple y se espera que producers/consumers sigan el comportamiento de compatibilidad descrito en la spec.

Versiones draft y pre-release

Durante el desarrollo, las versiones MAY usar notación SemVer de pre-release (por ejemplo, 1.0.0-DRAFT). Las versiones draft/pre-release no se consideran estables y pueden cambiar de manera incompatible hasta que se publique un release estable.

Política de deprecación

Las features deprecated siguen un ciclo de vida definido: anuncio, documentación + guía de migración, periodo de transición (al menos un ciclo MINOR) y eliminación solo en el siguiente release MAJOR.

Gobernanza de extensiones

OSIRIS JSON define las namespace rules y, cuando aplica, la política de registry para prefijos de extension namespace bien conocidos, pero no gobierna la semántica interna de las extensiones de vendor/organización. Los consumers deben tratar los valores dentro de las extensiones como opacos, salvo que soporten explícitamente ese namespace.

Registro de namespaces (v1.0)

Para OSIRIS JSON v1.0, el registro de namespaces es informal y guiado por la comunidad:

Documentar públicamente el uso del namespace
Publicar extension schemas para referencia del consumer (cuando aplique)
Coordinarse con la comunidad de OSIRIS JSON para evitar colisiones

Namespaces recomendados

Organization namespaces deben usar patrones reverse-domain (por ejemplo, osiris.com.<org>) para reducir colisiones.
osiris.custom.* puede usarse para experimentos de corta duración y drafts de la comunidad, pero no es resistente a colisiones. Los producers deben migrar a organization namespaces para uso persistente/en producción.

Código de conducta

La participación en la comunidad de OSIRIS JSON se rige por el Code of Conduct.
Read the Code of Conduct