Governance und Mitwirkung

Eine kurze, ehrliche Klärung vorweg, weil sie über alles andere entscheidet: Der Standard gehört nicht dieser Seite. Das Open Knowledge Format wird als offener, herstellerneutraler Draft im Repository von Google Cloud Platform gepflegt. Dort liegt die maßgebliche Fassung, dort werden Änderungen entschieden.

Der OKF Knowledge Hub auf dieser Seite ist ein Konsument und Produzent dieses Formats, keine Governance-Instanz. Er zeigt, dass sich OKF am Verbraucherende sinnvoll bedienen lässt, und er liefert Praxis-Rückmeldung an den Standard. Diese Seite dokumentiert den Weg dorthin.

Warum OKF überhaupt „regiert" wird

Der ganze Sinn eines Formats ist Interoperabilität. Ein Produzent schreibt ein Bundle, ein völlig anderer Konsument liest es Jahre später. Das funktioniert nur, wenn die wenigen verbindlichen Regeln stabil bleiben und Änderungen nachvollziehbar sind. Deshalb hat OKF ein explizites Versionierungsmodell und einen offenen Beitragsweg statt stiller Anpassungen.

Das Modell ist bewusst konservativ. Ein Minor-Sprung (0.1 → 0.2) fügt nur rückwärtskompatibel hinzu: neue optionale Felder, neue konventionelle Abschnittsüberschriften. Bestehende Bundles bleiben gültig. Ein Major-Sprung darf brechen – ein Pflichtfeld umbenennen, einen reservierten Dateinamen ändern – und wird entsprechend selten und mit Vorlauf kommen.

Der Beitragsweg

OKF nutzt den Weg, den Software-Standards seit Jahren nutzen: einen offenen RFC-Prozess über die Versionsverwaltung. Wer etwas ändern oder ergänzen will, geht in vier Schritten vor.

1. Problem benennen. Ein Issue im Repository beschreibt den konkreten Fall: Welches reale Bundle lässt sich mit der heutigen Spec nicht sauber ausdrücken? Ein Vorschlag ohne Problem hat keinen Hebel. / State the problem. An issue in the repository describes the concrete case: which real bundle cannot be expressed cleanly under today's spec? A proposal without a problem has no leverage.
2. Lösung skizzieren. Ein Vorschlag zeigt die vorgeschlagene Regel, ein Vorher-nachher-Beispiel und die Auswirkung auf Konformanz und Kompatibilität. / Sketch the solution. A proposal shows the proposed rule, a before-and-after example, and the effect on conformance and compatibility.
3. Diskutieren und anpassen. Öffentliche Diskussion am Issue oder Pull Request. Gegenargumente, Grenzfälle, Formulierung. / Discuss and revise. Public discussion on the issue or pull request. Counterarguments, edge cases, wording.
4. Einarbeiten und versionieren. Angenommene Änderungen landen in SPEC.md und erhalten die passende Versionsnummer nach dem Minor/Major-Schema. / Merge and version. Accepted changes land in SPEC.md and receive the appropriate version number under the minor/major scheme.

Was einen guten Vorschlag ausmacht

Die Spec hat eine klare Haltung: minimal opinionated. Sie standardisiert nur die wenigen strukturellen Konventionen, die einen Wissenskorpus selbstbeschreibend machen. Alles darüber hinaus bleibt beim Produzenten. Ein Vorschlag, der ein neues Pflichtfeld fordert, trägt deshalb eine hohe Beweislast: Er muss zeigen, dass jeder Konsument das Feld braucht, nicht nur einer.

Zwei Fragen trennen tragfähige Vorschläge von den anderen. Löst die Änderung ein Problem, das mehrere unabhängige Produzenten oder Konsumenten teilen? Und lässt sie sich als optionale, rückwärtskompatible Ergänzung fassen, statt bestehende Bundles zu entwerten? Zweimal Ja ist der Regelfall für eine Aufnahme.

Erweitern, ohne die Spec zu ändern

Oft braucht ein Vorschlag gar keinen Spec-Änderung. Die Erweiterungsregel erlaubt Produzenten beliebige zusätzliche Frontmatter-Schlüssel; Konsumenten sollen sie erhalten und nicht ablehnen. Wer ein neues Feld braucht, kann es also schlicht setzen und im eigenen Bundle nutzen. Erst wenn mehrere Parteien dasselbe Feld unabhängig einführen, lohnt der Weg in die Spec, damit alle es gleich benennen.

Genau so entsteht das v0.2-Profil dieses Projekts: die Einordnungsfelder category, domain, word_count und die Vertrauensschicht generated, verified, status, stale_after, sources. Alles Erweiterungen über die offene Basis, keine Spec-Änderung. Ein Bundle mit diesen Feldern bleibt für jeden anderen Konsumenten voll konform.

Wie diese Seite mitwirkt

Die Rolle hier ist die eines lauten Anwenders. Der Hub verarbeitet reale Bundles – importiert aus Notion, Obsidian, Logseq und Confluence, angereichert, gelesen, abgefragt. Wo dabei eine Grenze der Spec sichtbar wird, wird sie als Issue im Upstream-Repository dokumentiert, mit dem konkreten Bundle als Beleg. Praxis schlägt Meinung: Ein Vorschlag mit einem echten, gescheiterten Fall wiegt mehr als eine theoretische Verbesserung.

Weiter im Thema

Das Versionierungsmodell im Detail steht in der OKF-Spezifikation, Abschnitt Versionierung. Änderungen an dieser Seite und am Hub führt der Changelog. Das Upstream-Repository mit Issues und Pull Requests liegt auf GitHub.