Governance

OSIRIS JSON è un Open Standard pensato per essere apertamente riesaminabile e guidato dalla community.
Questa pagina spiega come le modifiche vengono proposte, revisionate e rilasciate.

[!Info] Modello di manutenzione attuale OSIRIS JSON è attualmente mantenuto da una sola persona. I contributi sono benvenuti fin dall’inizio, ma il processo è intenzionalmente leggero per mantenere v1.0 gestibile e coerente.

Ruoli

Maintainer

È responsabile della qualità e della coerenza del testo della specifica, degli schemi, dei producer, degli esempi e delle note di rilascio. Garantisce che le modifiche preservino vendor-neutrality, chiarezza e aspettative di compatibilità.

Contributore

Propone miglioramenti tramite issue e pull request: correzioni, chiarimenti, nuovi esempi, nuovi producer e linee guida di implementazione.

Revisore

Membri della community che forniscono competenza tecnica, revisioni e feedback. La review è particolarmente preziosa per le modifiche normative e per gli impatti sul versioning.

Dove vengono prese le decisioni

GitHub discussions: discussioni di progettazione, domande e feedback iniziale.
GitHub issues: bug, incoerenze e proposte di modifica della specifica.
Pull requests: il luogo autorevole in cui testo, schemi ed esempi vengono modificati e revisionati.

Principi decisionali

OSIRIS JSON segue i principi di progettazione della specifica, con particolare attenzione a:

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

Il modello decisionale predefinito è il rough consensus attraverso discussione pubblica e review. Quando non è possibile raggiungere un consenso, la persona con il ruolo di lead maintainer prende una decisione e ne documenta la motivazione nella PR o nella issue.

Processo di modifica

Discuti

Apri una issue (o una discussion) descrivendo il problema e la modifica prevista

Implementa

Invia una PR che aggiorni il testo della specifica e, quando applicabile, schemi/esempi

Revisiona

Revisiona per correttezza, coerenza e impatto sulla compatibilità

Merge & release

Le modifiche unite vengono rilasciate secondo SemVer e le regole di deprecazione

Tipi di modifiche

Editoriali (non normative)

Correzione di refusi, miglioramento della chiarezza, ristrutturazione delle sezioni, miglioramento degli esempi senza modificare i requisiti.

Normative

Modifiche che alterano requisiti o interpretazione (regole MUST/SHOULD/MAY), comportamento di validazione o aspettative di compatibilità. OSIRIS JSON usa il formato JSON, ampiamente supportato, e si allinea a convenzioni consolidate, incluso JSON Schema per la validazione strutturale e le keyword di RFC 2119 per i requisiti normativi.

Linee guida su taxonomy / registry / extension

Aggiornamenti che influenzano l’interpretazione dei type standard, dei namespace raccomandati o delle best practice per le extension.

Versioning, compatibilità e release

OSIRIS JSON usa Semantic versioning 2.0.0 per le release della specifica.
Il campo version in un documento OSIRIS JSON dichiara a quale versione della specifica esso è conforme e ci si aspetta che producer/consumer seguano il comportamento di compatibilità descritto nella specifica.

Versioni draft e pre-release

Durante lo sviluppo, le versioni MAY usare la notazione pre-release di SemVer (ad es. 1.0.0-DRAFT). Le versioni draft/pre-release non sono considerate stabili e possono cambiare in modo incompatibile fino alla pubblicazione di una release stabile.

Politica di deprecazione

Le feature deprecate seguono un ciclo di vita definito: annuncio, documentazione + guida alla migrazione, periodo di transizione (almeno un ciclo MINOR) e rimozione solo nella release MAJOR successiva.

Governance delle extension

OSIRIS JSON definisce le regole dei namespace e, quando applicabile, la policy di registry per i prefissi di extension namespace ben noti, ma non governa la semantica interna delle extension di vendor/organizzazione. I consumer devono trattare i valori all’interno delle extension come opachi, a meno che non supportino esplicitamente quel namespace.

Registrazione dei namespace (v1.0)

Per OSIRIS JSON v1.0, la registrazione dei namespace è informale e guidata dalla community:

Documentare pubblicamente l’utilizzo del namespace
Pubblicare schemi di extension come riferimento per i consumer (quando applicabile)
Coordinarsi con la community di OSIRIS JSON per evitare collisioni

Namespace raccomandati

I namespace di organizzazione dovrebbero usare pattern reverse-domain (ad es. osiris.com.<org>) per ridurre le collisioni.
osiris.custom.* può essere usato per esperimenti di breve durata e draft della community, ma non è resistente alle collisioni. I producer dovrebbero migrare ai namespace di organizzazione per usi persistenti/in produzione.

Codice di condotta

La partecipazione alla community di OSIRIS JSON è regolata dal Codice di condotta.
Leggi il Codice di condotta