Governance

OSIRIS JSON ist ein Open Standard, der offen überprüfbar und community-getrieben sein soll.
Diese Seite erklärt, wie Änderungen vorgeschlagen, überprüft und veröffentlicht werden.

[!Info] Aktuelles Wartungsmodell OSIRIS JSON wird derzeit von einer einzelnen lead maintainer gepflegt. Beiträge sind von Anfang an willkommen, aber der Prozess ist bewusst leichtgewichtig gehalten, damit v1.0 handhabbar und konsistent bleibt.

Rollen

Maintainer

Verantwortlich für Qualität und Kohärenz des Spezifikationstexts, der schemas, producers, Beispiele und release notes. Stellt sicher, dass Änderungen vendor-neutrality, Klarheit und Kompatibilitätserwartungen bewahren.

Contributor

Schlägt Verbesserungen über issues und pull requests vor: Fixes, Klarstellungen, neue Beispiele, neue producers und Implementierungsleitlinien.

Reviewer

Community-Mitglieder, die technische Einblicke, Review und Feedback liefern. Review ist besonders wertvoll bei normativen Änderungen und Auswirkungen auf die Versionierung.

Wo Entscheidungen getroffen werden

GitHub discussions: Design-Diskussionen, Fragen und frühes Feedback.
GitHub issues: Bugs, Inkonsistenzen und Vorschläge zur Änderung der Spezifikation.
Pull requests: Der maßgebliche Ort, an dem Formulierungen, schemas und Beispiele geändert und überprüft werden.

Prinzipien der Entscheidungsfindung

OSIRIS JSON folgt den Designprinzipien der Spezifikation mit Fokus auf:

Einfachheit
Vendor-Neutralität
Erweiterbarkeit ohne Fragmentierung
Explizit statt implizit
Stabilität und Kompatibilität

Das Standard-Entscheidungsmodell ist rough consensus durch öffentliche Diskussion und Review. Wenn kein Konsens erreicht werden kann, trifft die lead maintainer eine Entscheidung und dokumentiert die Begründung in der PR oder im issue.

Änderungsprozess

Diskutieren

Ein issue (oder eine discussion) öffnen, das Problem und beabsichtigte Änderung beschreibt

Implementieren

Eine PR einreichen, die den spec-Text und, sofern anwendbar, schemas/examples aktualisiert

Überprüfen

Auf Korrektheit, Konsistenz und Kompatibilitätsauswirkungen prüfen

Merge & release

Gemergte Änderungen werden gemäß SemVer und Deprecation-Regeln veröffentlicht

Arten von Änderungen

Redaktionell (nicht normativ)

Tippfehler beheben, Klarheit verbessern, Abschnitte umstrukturieren, Beispiele verbessern, ohne Anforderungen zu ändern.

Normativ

Änderungen, die Anforderungen oder deren Interpretation (MUST/SHOULD/MAY-Regeln), Validierungsverhalten oder Kompatibilitätserwartungen verändern. OSIRIS JSON verwendet das breit unterstützte JSON-Format und orientiert sich an etablierten Konventionen, darunter JSON Schema für strukturelle Validierung und RFC 2119-Keywords für normative Anforderungen.

Taxonomy / registry / extension guidance

Aktualisierungen, die die Interpretation von Standardtypen, empfohlenen namespaces oder Best Practices für Erweiterungen betreffen.

Versionierung, Kompatibilität und Releases

OSIRIS JSON verwendet Semantic versioning 2.0.0 für Spezifikations-Releases.
Das Feld version in einem OSIRIS-JSON-Dokument deklariert, welcher Spezifikationsversion es entspricht, und von producers/consumers wird erwartet, dass sie das in der spec beschriebene Kompatibilitätsverhalten einhalten.

Draft- und pre-release-Versionen

Während der Entwicklung MAY Versionen die SemVer-pre-release-Notation verwenden (z. B. 1.0.0-DRAFT). Draft-/pre-release-Versionen gelten nicht als stabil und können sich inkompatibel ändern, bis ein stabiles Release veröffentlicht wird.

Deprecation-Richtlinie

Deprecated Features folgen einem definierten Lebenszyklus: Ankündigung, Dokumentation + Migrationsleitfaden, Übergangszeitraum (mindestens ein MINOR-Zyklus) und Entfernung erst im nächsten MAJOR-Release.

Extension-Governance

OSIRIS JSON definiert die namespace rules und, sofern anwendbar, die registry policy für bekannte extension-namespace-Präfixe, regelt aber nicht die interne Semantik von Vendor-/Organisations-Extensions. Consumers müssen Werte innerhalb von Extensions als opak behandeln, es sei denn, sie unterstützen diesen Namespace ausdrücklich.

Namespace-Registrierung (v1.0)

Für OSIRIS JSON v1.0 ist die Namespace-Registrierung informell und community-getrieben:

Namespace-Nutzung öffentlich dokumentieren
Extension schemas als Referenz für consumers veröffentlichen (sofern anwendbar)
Mit der OSIRIS-JSON-Community koordinieren, um Kollisionen zu vermeiden

Empfohlene Namespaces

Organization namespaces sollten reverse-domain-Muster verwenden (z. B. osiris.com.<org>), um Kollisionen zu reduzieren.
osiris.custom.* kann für kurzlebige Experimente und Community-Drafts verwendet werden, ist jedoch nicht kollisionsresistent. Producers sollten für persistente/produktive Nutzung auf organization namespaces migrieren.

Verhaltenskodex

Die Teilnahme an der OSIRIS-JSON-Community unterliegt dem Code of Conduct.
Read the Code of Conduct