Gouvernance

OSIRIS JSON est un Open Standard conçu pour être révisable publiquement et piloté par la communauté.
Cette page explique comment les changements sont proposés, révisés et publiés.

[!Info] Modèle de maintenance actuel OSIRIS JSON est actuellement maintenu par une seule lead maintainer. Les contributions sont bienvenues dès le départ, mais le processus reste volontairement léger afin de garder v1.0 gérable et cohérent.

Rôles

Maintainer

Responsable de la qualité et de la cohérence du texte de la spécification, des schemas, des producers, des exemples et des notes de release. Veille à ce que les changements préservent la vendor-neutrality, la clarté et les attentes de compatibilité.

Contributor

Propose des améliorations via des issues et des pull requests : corrections, clarifications, nouveaux exemples, nouveaux producers et guide d'implémentation.

Reviewer

Membres de la communauté qui apportent une expertise technique, de la revue et du feedback. La revue est particulièrement précieuse pour les changements normatifs et les impacts de versioning.

Où les décisions sont prises

GitHub discussions : discussions de conception, questions et premiers retours.
GitHub issues : bugs, incohérences et propositions de modification de la spécification.
Pull requests : l’endroit de référence où le texte, les schemas et les exemples sont modifiés et révisés.

Principes de prise de décision

OSIRIS JSON suit les principes de conception de la spécification avec un accent sur :

Simplicité
Neutralité vis-à-vis des vendors
Extensibilité sans fragmentation
Explicite plutôt qu’implicite
Stabilité et compatibilité

Le modèle de décision par défaut repose sur le rough consensus au travers de discussions publiques et de revues. Lorsqu’un consensus ne peut pas être atteint, la lead maintainer prend une décision et documente sa justification dans la PR ou l’issue.

Processus de changement

Discuter

Ouvrir une issue (ou discussion) décrivant le problème et le changement envisagé

Implémenter

Soumettre une PR mettant à jour le texte de la spec et, si applicable, schemas/examples

Réviser

Réviser l'exactitude, la cohérence et l'impact sur la compatibilité

Merge & release

Les changements fusionnés sont publiés conformément à SemVer et aux règles de dépréciation

Types de changements

Éditorial (non normatif)

Corriger des typos, améliorer la clarté, restructurer des sections, améliorer des exemples sans modifier les exigences.

Normatif

Changements qui modifient les exigences ou leur interprétation (règles MUST/SHOULD/MAY), le comportement de validation ou les attentes de compatibilité. OSIRIS JSON utilise le format JSON largement supporté et s’aligne sur des conventions établies, notamment JSON Schema pour la validation structurelle et les mots-clés de RFC 2119 pour les exigences normatives.

Taxonomie / registry / guide des extensions

Mises à jour affectant l’interprétation des types standards, les namespaces recommandés ou les bonnes pratiques d’extension.

Versioning, compatibilité et releases

OSIRIS JSON utilise Semantic versioning 2.0.0 pour les releases de la spécification.
Le champ version d’un document OSIRIS JSON déclare à quelle version de la spécification il se conforme, et les producers/consumers sont censés suivre le comportement de compatibilité décrit dans la spec.

Versions draft et pre-release

Pendant le développement, les versions MAY utiliser la notation SemVer de pre-release (par exemple, 1.0.0-DRAFT). Les versions draft/pre-release ne sont pas considérées comme stables et peuvent changer de manière incompatible jusqu’à la publication d’une release stable.

Politique de dépréciation

Les fonctionnalités deprecated suivent un cycle de vie défini : annonce, documentation + guide de migration, période de transition (au moins un cycle MINOR), puis suppression uniquement dans la prochaine release MAJOR.

Gouvernance des extensions

OSIRIS JSON définit les namespace rules et, lorsque cela s’applique, la politique de registry pour les préfixes de extension namespace bien connus, mais ne gouverne pas la sémantique interne des extensions vendor/organization. Les consumers doivent traiter les valeurs contenues dans les extensions comme opaques, sauf s’ils prennent explicitement en charge ce namespace.

Enregistrement des namespaces (v1.0)

Pour OSIRIS JSON v1.0, l’enregistrement des namespaces est informel et piloté par la communauté :

Documenter publiquement l’utilisation du namespace
Publier des extension schemas à titre de référence pour les consumers (si applicable)
Coordonner avec la communauté OSIRIS JSON afin d’éviter les collisions

Namespaces recommandés

Organization namespaces devraient utiliser des motifs reverse-domain (par exemple, osiris.com.<org>) afin de réduire les collisions.
osiris.custom.* peut être utilisé pour des expérimentations de courte durée et des drafts communautaires, mais n’est pas résistant aux collisions. Les producers devraient migrer vers des organization namespaces pour un usage persistant/en production.

Code de conduite

La participation à la communauté OSIRIS JSON est régie par le Code of Conduct.
Read the Code of Conduct