Request for Comments (RFC) Standard für den D-Stack

Ein RFC ist ein formalisiertes Dokumentations- und Governance-Instrument, das für weitreichende Design-, Architektur- und Spezifikationsentscheidungen innerhalb des Deutschland Stacks (D-Stack) eingesetzt wird. Es dient dazu, Konsens in der Community und unter den föderalen Stakeholdern zu erzielen, bevor signifikante Ressourcen in die Implementierung investiert werden.

1. Grundprinzipien und Ziele

Da der D-Stack auf offenen Standards und Open Source basiert, fördert der RFC-Prozess:

Transparenz: Alle Entscheidungen sind öffentlich und nachvollziehbar auf openCode dokumentiert
Kooperation: Erforderliche Beteiligung von IT-Experten, Verwaltungsexperten und der Community (Bund, Länder, Kommunen, Industrie)
Historische Dokumentation: Schaffung einer unveränderlichen, zentralen Aufzeichnung wichtiger Designentscheidungen und deren Begründung
Qualität und Konsistenz: Sicherstellung, dass neue Komponenten oder Änderungen mit den strategischen Zielen, den Sicherheitsanforderungen und der Gesamtarchitektur des D-Stacks übereinstimmen

2. Der Lebenszyklus: Stufen und Stati

Der RFC-Prozess auf openCode wird durch klare Stufen und die entsprechenden Stati definiert, die den Reifegrad des Vorschlags anzeigen.

Stufe	Status	Beschreibung	Aktionen und Erfordernisse
I. Einreichung	Entwurf (Drafting)	Der Autor identifiziert ein Problem und schlägt eine initiale Lösung vor. Das Dokument ist noch nicht finalisiert.	Erstellung des RFC-Dokuments basierend auf einer festen Vorlage (Markdown). Einreichung als Pull/Merge Request (PR/MR) im dedizierten Repository auf openCode mit dem Präfix `[RFC-XXXX]`.
II. Diskussion	Zur Diskussion (In Review)	Die breite Community, Fachexperten und das Governance-Gremium prüfen den Vorschlag. Fokus liegt auf der technischen Machbarkeit, Sicherheit, Kosten und strategischer Passung.	Verpflichtende Diskussion von Alternativen (siehe Abschnitt 4). Die Dauer dieser Phase kann begrenzt werden (z.B. 4–6 Wochen). Der Autor muss aktiv auf Feedback eingehen.
III. Entscheidung	Angenommen (Accepted)	Das zuständige Governance-Gremium (z.B. ein Architekturbeirat des D-Stacks) stimmt dem Vorschlag zu.	Zuweisung einer finalen, unveränderlichen Nummer. Der RFC wird in den Implementierungs-Backlog überführt.
	Abgelehnt (Rejected)	Der Vorschlag wird nicht zur Umsetzung freigegeben, oft wegen fehlendem Konsens oder strategischer Bedenken.	Klare, öffentliche Begründung der Ablehnung. Der RFC wird im Archiv mit dem Status `Rejected` gespeichert.
IV. Umsetzung	Im Gange (In Progress)	Das Entwicklungsteam implementiert die Spezifikation gemäß dem Angenommenen RFC	Technische Implementierung, Erstellung von Code und Testfällen. Die Spezifikation des RFC ist hierbei die verbindliche Vorgabe.
V. Abschluss	Final (Finalized)	Die Implementierung ist abgeschlossen, getestet und in Produktion genommen. Der RFC ist nun eine verbindliche Spezifikation für den D-Stack.	Der RFC wird im finalen Archiv abgelegt
	Veraltet (Superseded)	Ein neuer, angenommener RFC löst diesen RFC ab, weil er verbesserte oder geänderte Spezifikationen enthält	Dient der Versionskontrolle. Der Status zeigt an, dass die ursprüngliche Spezifikation nicht mehr gültig ist und durch den ablösenden RFC ersetzt wurde.

3. Vorgehensweise und Prozesse auf openCode

Die technische Umsetzung des Prozesses erfolgt vollständig über die PR/MR-Funktionalität von openCode:

Repository: Ein dediziertes dstack-rfcs Repository wird auf openCode eingerichtet, das nur die RFC-Dokumente enthält
Einreichung: Ein Beitragender forkt das RFC-Repository und erstellt ein neues Dokument auf Basis der offiziellen Vorlage
PR/MR-Erstellung: Der Entwurf wird als Pull/Merge Request im Status Draft/WIP (Work in Progress) eingereicht. Die PR/MR-Nummer dient als temporäre Identifikationsnummer
Kommentar und Diskussion: Die Diskussion und das Feedback finden zentral in den Kommentaren des PR/MR statt. Dies ermöglicht eine direkte Verknüpfung von Feedback und vorgeschlagenen Code-Änderungen am Dokument.
Status-Wechsel: Status-Wechsel (z.B. von In Review zu Accepted) werden durch das Setzen von Labels oder das Hinzufügen spezifischer Kommentare durch das Governance-Gremium gesteuert
Archivierung: Ein akzeptierter RFC wird nach der Genehmigung in das Haupt-Repository gemergt und erhält seine finale Kennung. Abgelehnte RFCs werden mit dem Label Rejected geschlossen, aber die Diskussion bleibt erhalten.

4. Best Practice: Alternative Lösungsansätze

Der Umgang mit Alternativen ist ein Kernstück des RFC-Prozesses, um sicherzustellen, dass die beste Lösung gefunden wird.

Verpflichtung: Im Status Zur Diskussion (In Review) ist der RFC-Autor verpflichtet, einen dedizierten Abschnitt über Alternativen in das Dokument aufzunehmen
Inhalt: Es müssen mindestens zwei realisierbare Alternativen zur vorgeschlagenen Hauptlösung identifiziert und detailliert beschrieben werden
Vergleich: Für jede Alternative sind die Vor- und Nachteile in Bezug auf den D-Stack zu bewerten, insbesondere hinsichtlich:
- Kosten und Aufwand (Implementierung und Betrieb)
- Sicherheit und Datenschutz (IT-Grundschutz, DSGVO)
- Skalierbarkeit und Performance
- Kompatibilität mit bestehenden Komponenten
Entscheidungsbegründung: Der Autor muss klar darlegen, warum der ursprünglich vorgeschlagene Weg - auch im Vergleich zu den dokumentierten Alternativen - die strategisch beste Wahl für den D-Stack ist

5. Best Practice: Ablösen alter Spezifikationen (Superseded)

Um die Architektur des D-Stacks aktuell und konsistent zu halten, ist die Möglichkeit zum Ablösen (Superseding) alter RFCs unerlässlich.

Mechanismus: Nur ein neuer RFC im Status Accepted darf einen oder mehrere ältere RFCs für ungültig erklären
Nachweis: Der neue RFC muss in seinen Metadaten klar den/die abzulösenden RFC(s) referenzieren
Dokumentation: Der alte RFC erhält den Status Veraltet (Superseded) und einen Verweis auf den ablösenden RFC. Das Originaldokument bleibt erhalten (historische Aufzeichnung), aber Entwickler wissen, dass es nicht mehr die gültige Spezifikation ist.

Siehe auch #379