Architecture

Request for Comments

Strukturiertes Vorschlagsdokument, das eine nicht-triviale Änderung beschreibt und gezielt Feedback einsammelt.

ArchitectureMediumAsync1-3 Wochen vom Draft bis zur Entscheidung

Run Sheet öffnen Session planenVergleich starten

Zweck

Wichtige technische oder produktbezogene Entscheidungen asynchron, nachvollziehbar und mit breitem Input vorbereiten.

Funktionsweise

Ein Vorschlag wird als Dokument mit Kontext, Motivation, Lösung, Alternativen und offenen Fragen geschrieben, kommentiert und am Ende angenommen oder abgelehnt.

Visuelle Orientierung

Methodenskizze für ein schnelles Grundgefühl.

Visuelle MethodenskizzeSysteme, Grenzen und Beziehungen sichtbar machen

Kern

Nutzer

System

Team

Kontext

Ablauf

1Problem und Kontext beschreiben
2Motivation und Ziele schärfen
3Lösungsvorschlag detaillieren
4Alternativen und Tradeoffs ausführen
5Offene Fragen und Risiken markieren
6Review-Runde mit Stakeholdern starten
7Kommentare einarbeiten und Status setzen
8Entscheidung dokumentieren und in ADR übersetzen

Ideal für

Größere Architektur- oder Produktänderungen
Verteilte Teams mit hohem Async-Anteil
Technische Standards und Plattform-Entscheidungen
Cross-Team-Initiativen mit vielen Stakeholdern

Nicht gut für

Triviale Refactorings
Sehr kleine, lokale Entscheidungen
Themen ohne klaren Entscheidungsbedarf
Zeitkritische Hotfixes

Vertiefung

Im Detail

Ein Request for Comments (RFC) ist ein strukturiertes Vorschlagsdokument, das ursprünglich aus dem IETF-Prozess stammt und heute in Engineering-Organisationen wie Rust, Python (als PEP), Squarespace, GitHub und Oxide (als RFD) für nicht-triviale Änderungen genutzt wird. Das Dokument folgt einem festen Aufbau: Kontext, Motivation, Solution, Alternatives, Drawbacks, Unresolved Questions. Es wird in einem Review-Fenster offen kommentiert, der Autor arbeitet Feedback ein, und am Ende setzt eine benannte Entscheidungsinstanz den Status auf Accepted, Rejected oder Withdrawn. Der Prozess macht Annahmen, Tradeoffs und abgelehnte Optionen dauerhaft sichtbar.

Einordnung

RFCs eignen sich besonders, wenn eine Entscheidung mehrere Teams betrifft, schwer rückgängig zu machen ist oder grundsätzliche Annahmen verändert. Für kleine Refactorings, lokale Bugfixes oder eindeutig fachliche Detailfragen ist der Prozess zu schwer. Ein guter Indikator: wenn du sonst ein langes Alignment-Meeting mit acht Personen einberufen würdest, ist ein RFC oft schneller und nachhaltiger.

Durchführung

Halte das Template kurz und konsistent (idealerweise als Repo-Vorlage). Setze ein klares Review-Fenster mit Enddatum, eine benannte Entscheidungsinstanz und Standardstatuswerte. Trenne Diskussion (Kommentare) sauber von der Endentscheidung und übersetze angenommene RFCs in ADRs und konkrete Tickets, damit Umsetzung nicht im Dokument hängen bleibt.

Output-Artefakte

RFC-DokumentReviewer-KommentareEntscheidung mit BegründungFolge-ADR oder Tickets

Quellen

EN: Request FOR Comments Oxide: RFD 1

Artefakt-Vorlagen

Request for Comments ArbeitsvorlageKompakte Arbeitsvorlage für Request for Comments mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

markdown

# Request for Comments Arbeitsvorlage

## Ziel

Strukturiertes Vorschlagsdokument, das eine nicht-triviale Änderung beschreibt und gezielt Feedback einsammelt.

## Kontext

Wann und wofür nutzen wir diese Methode?

## Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

## Durchführung

Kurze Notizen entlang des Run Sheets.

## Ergebnisartefakte
- RFC-Dokument:
- Reviewer-Kommentare:
- Entscheidung mit Begründung:
- Folge-ADR oder Tickets:

## Annahmen und offene Fragen

- ...

## Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.