AIO logo
Public RFC Process

AIO Public RFC Process

The public process through which standards, specifications, policies, and process changes are proposed, reviewed, and adopted.

AIO Public RFC Prozess

1) Zweck und Umfang

Dieses Dokument legt das öffentliche Request For Comment (RFC)-Verfahren der AIO fest, das zur Einreichung von Standards, Spezifikationen und Verfahrensänderungen dient. Es umfasst RFC‑Typen, Lebenszyklusphasen, Einreichungs‑und Nummerierungskonventionen, Lizenzfragen, Review‑Rollen und verwandte Governance‑Praktiken.

Der RFC‑Prozess soll ein offenes, prüfbares Protokoll technischer und prozessualer Vorschläge schaffen, das von Stakeholdern im Ökosystem überprüft und implementiert werden kann.

2) Dokumenttypen

  • Standards Track: Normative Spezifikationen, Formate oder APIs (z. B. RBP JSON, BYOR API).
  • Informational: Leitfäden, Hintergrundinformationen, Anwendungsfälle.
  • Process: Vorschläge zur Änderung organisatorischer oder prozeduraler Regeln.

3) Statusfortschritt

RFCs durchlaufen folgenden Lebenszyklus: Idea → Draft → Candidate (CR) → Final (STD) → Deprecated.

  • Draft: Beginn der öffentlichen Review‑Phase (mindestens 14 Tage).
  • Candidate: Implementierungs‑und Interoperabilitätsprüfung; Readiness‑Review (mindestens 30 Tage).
  • Final: Nach Konsens und ggf. Governance‑Freigaben ratifiziert.
  • Deprecated: Als veraltet markiert, wenn ersetzt oder nicht mehr empfohlen.

4) Nummerierung und Metadaten

  • RFC‑Kennung: AIO‑RFC‑YYYY‑NNN (z. B. AIO‑RFC‑2025‑001).
  • Erforderliche Metadaten: Titel, Abstract, Motivation, Spezifikation, Begründung, Kompatibilitäts‑und Sicherheitsüberlegungen, Implementierungshinweise, IPR/Lizenzinfo, referenzierte Dokumente, Änderungsprotokoll und Autorenliste.
  • Lizenz: Dokumenttext unter CC BY 4.0; Codebeispiele unter Apache‑2.0 oder MIT.

5) Einreichung und Veröffentlichung

  • Einreichungswege: GitHub Issue/PR oder ein offizielles Einreichungsmechanismus der AIO (öffentlich bevorzugt).
  • Alle Artefakte (Text, Referenzimplementierungen, Testvektoren) sollten möglichst in einem öffentlichen Repository veröffentlicht werden, um Review und Reproduzierbarkeit zu unterstützen.

6) Review‑und Entscheidungsrollen

  • Reviewer: Fachexperten und Arbeitsgruppen liefern technische Reviews und Verifikation.
  • Working Group (WG): Verantwortlich für das Begleiten von Vorschlägen bis zur Candidate‑Stufe und für Implementierungsleitfäden.
  • Community: Öffentliche Diskussionskanäle und Issue‑Threads sind zentrale Räume für Review.

7) Review‑Dauern und Revisionen

  • Draft: mind. 14 Tage öffentliche Review.
  • Candidate: mind. 30 Tage für Implementierungs‑Verifikation (Ausnahmen möglich).
  • Revisionen werden mit Suffixen verfolgt (z. B. -rev1). Errata sind für kleinere Korrekturen vorgesehen.

8) IPR und Lizenzierung

  • Autoren gewähren AIO das Recht, den Dokumenttext unter CC BY 4.0 zu veröffentlichen und Referenzcode unter Apache‑2.0 oder MIT, sofern nicht anders vereinbart.
  • Beitragende müssen etwaige Patentvorbehalte offenlegen; Lizenzverpflichtungen sind im RFC klar anzugeben.

9) Redaktionelle und Stewardship‑Rollen

  • Editor‑in‑Chief: Übergreifende redaktionelle Verantwortung und Publikationsbefugnis für RFCs.
  • RFC Editor: Zuständig für Formatierung, Metadaten und Pflege des RFC‑Index.
  • Working Groups: Liefern technischen Review, Test‑Suiten und Referenzimplementierungen.

10) Zeitpläne und Change‑Management

  • Standardzeiten (Draft 14 Tage, Candidate 30 Tage) gelten als Default; Ausnahmen erfordern Begründung.
  • Wesentliche Änderungen werden versionsgeführt und mit Changelogs dokumentiert; Notfalländerungen können per Errata behandelt werden.

11) IPR & Offenlegung

  • Beitragende müssen Rechte und Lizenzen für beigetragenes Material deklarieren. Bei Dritt‑Rechten ist der Status und die Erlaubnis darzulegen.

12) Anhängung und WG‑Einreichungen

  • RFCs können von Arbeitsgruppen, Ausschüssen oder Einzelautoren verfasst oder gesponsert werden. Arbeitsgruppen sollten Review‑Artefakte und Referenzimplementierungen bereitstellen, wo notwendig.

13) Revisionen

  • Revisionen werden im Änderungsprotokoll festgehalten; größere Revisionen sollten eine Änderungsübersicht und Motivation enthalten.

14) Governance‑Integration

  • RFCs, die Organisationsregeln oder Statuten betreffen, können der Zustimmung durch zuständige Governance‑Organe (z. B. General Assembly, Board) unterliegen.

15) Interessenkonflikte und Enthaltung

  • Beitragende und Reviewer müssen Interessenkonflikte offenlegen. Bei Einflussnahme werden Enthaltungen oder andere Maßnahmen angewandt.

16) Datenschutz und Privatsphäre

  • Wenn RFCs personenbezogene Daten betreffen, sind Datenschutz‑Folgenabschätzungen zu erstellen und zu dokumentieren.

17) Publikationsnormen

  • RFCs werden offen veröffentlicht; Metadaten und Versionsgeschichte bleiben erhalten, um Nachvollziehbarkeit zu gewährleisten.

18) Lizenzierung

  • Dokumenttext: CC BY 4.0.
  • Quellcode und Testartefakte: Apache‑2.0 oder MIT.

19) Durchsetzung und Compliance

  • AIO‑Mitarbeitende und relevante Arbeitsgruppen sind verantwortlich für korrekte Publikations‑und Archivierungspraktiken.

20) Governance‑Entscheidungen

  • Governance‑Level Entscheidungen (z. B. Adoption als offizieller Standard) folgen den Abstimmungsregeln in den Statuten und können qualifizierte Mehrheiten erfordern.

21) Adoption und Implementierung

  • Die verantwortliche Arbeitsgruppe oder Sponsoring‑Instanz koordiniert Implementierung und Monitoring; wichtige Entscheidungen sind zu dokumentieren und zu veröffentlichen.

<sub>Final v1.0</sub>

AIO Public RFC Process | AIO