Governance

OSIRIS JSON es un Open Standard pensado para ser revisable abiertamente y guiado por la comunidad.
Esta página explica cómo se proponen, revisan y publican los cambios.

[!Info] Modelo de mantenimiento actual OSIRIS JSON está mantenido actualmente por una sola persona. Las contribuciones son bienvenidas desde el principio, pero el proceso es intencionadamente ligero para mantener v1.0 manejable y coherente.

Roles

Maintainer

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

Contribuidor

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

Revisor

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

Dónde se toman las decisiones

GitHub discussions: debates de diseño, preguntas y feedback inicial.
GitHub issues: bugs, incoherencias y propuestas para cambiar la especificación.
Pull requests: el lugar autoritativo donde se cambian y revisan el texto, los esquemas y los ejemplos.

Principios de toma de decisiones

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

Simplicity
Vendor neutrality
Extensibility without fragmentation
Explicit over implicit
Stability and compatibility

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

Proceso de cambio

Debate

Abre una issue (o discussion) describiendo el problema y el cambio previsto

Implementa

Envía una PR actualizando el texto de la spec y, cuando aplique, los schemas/ejemplos

Revisa

Revisión de corrección, coherencia e impacto en la compatibilidad

Merge & release

Los cambios fusionados se publican según SemVer y las reglas de deprecación

Tipos de cambios

Editoriales (no normativos)

Corregir erratas, mejorar la claridad, reestructurar secciones, mejorar ejemplos sin cambiar requisitos.

Normativos

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 las palabras clave de RFC 2119 para requisitos normativos.

Guía de taxonomy / registry / extension

Actualizaciones que afectan a la interpretación de tipos estándar, namespaces recomendados o buenas prácticas de extension.

Versioning, compatibilidad y releases

OSIRIS JSON usa Semantic versioning 2.0.0 para las releases de la especificación.
El campo version en un documento OSIRIS JSON declara a qué versión de la especificación se ajusta 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 la notación pre-release de SemVer (por ejemplo, 1.0.0-DRAFT). Las versiones draft/pre-release no se consideran estables y pueden cambiar de forma incompatible hasta que se publique una release estable.

Política de deprecación

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

Gobernanza de las extension

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

Registro de namespace (v1.0)

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

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

Namespaces recomendados

Los organization namespaces deberían 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 deberían migrar a organization namespaces para uso persistente/de producción.

Código de conducta

La participación en la comunidad de OSIRIS JSON se rige por el Código de conducta.
Lee el Código de conducta