Meine Session planen

# Session Brief: Request for Comments

## Ziel
Artefakt: RFC-Dokument

## Arbeitsfrage
Welche Änderung schlägt das Team vor, mit welcher Begründung, welchen Alternativen und welchen Tradeoffs, und wer entscheidet bis wann?

## Kontext
Problem-Beschreibung; bekannte Alternativen aus Vor-Diskussionen; betroffene Teams und Komponenten; Architektur-Constraints; gewünschter Entscheidungstermin; Status-Werte (Draft, In Review, Accepted, Rejected, Withdrawn).

## Setup
- Format: Async-Arbeitslauf
- Dauer: 24 bis 72 h
- Modus: asynchron
- Teilnehmende: Ein Autor (Senior-Engineer, Architekt, PM oder TL); 3-20 Reviewer aus betroffenen Teams; eine benannte Entscheidungsinstanz (Tech Lead, Architecture Review Board, oder klar gewählter Decider); ein Sponsor für umstrittene RFCs.
- Owner: Ein Autor (Senior-Engineer, Architekt, PM oder TL)
- Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
- Ergebnislogik: Artefakt fertigstellen

## Beteiligungslogik
Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

## Ergebnislogik
Die Session arbeitet direkt auf RFC-Dokument hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
RFC-Template im Repo (Kontext, Motivation, Solution, Alternatives, Drawbacks, Unresolved Questions, Migration); Repository oder Wiki für RFCs mit Nummerierung; Review-Tool mit Kommentaren (GitHub PR, GitLab MR, Notion Comments); Entscheidungs-Log.

## Vorbereitung
RFC-Nummer und Datei im Repo angelegt. Reviewer und Decider benannt. Review-Fenster mit klarem Enddatum kommuniziert. Template-Sektionen befüllt mindestens als Skeleton.

## Agenda
1. Brief vorbereiten (15-30 min)
   Owner: Owner
   Aktion: Arbeitsfrage, Input, Zielartefakt und Reviewfrist für Request for Comments vorbereiten. Verlinke relevante Daten, Quellen und bestehende Artefakte. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Session Brief

2. Asynchron bearbeiten (24 bis 72 h)
   Owner: Teilnehmende
   Aktion: Teilnehmende arbeiten die Methode entlang der Vorlage durch. Fokus: Beiträge direkt am Artefakt ergänzen, Annahmen markieren und Belege verlinken. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: RFC-Dokument

3. Review bündeln (20-30 min)
   Owner: Facilitator
   Aktion: Kommentare, Widersprüche und offene Fragen clustern. Unklare Punkte als Entscheidungen, Risiken oder Follow-ups einsortieren. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Review Notes

4. Artefakt finalisieren (15-30 min)
   Owner: Owner
   Aktion: Eingearbeitete Version erstellen, Status setzen und nächsten Review oder Entscheidungspunkt terminieren. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Reviewer-Kommentare

5. Artefakt veröffentlichen (10 min)
   Owner: Owner
   Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
   Output: RFC-Dokument

## Abschluss
- Ergebnisartefakt aktualisieren: RFC-Dokument
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# RFC-Dokument: Request for Comments

## Arbeitsfrage
Welche Änderung schlägt das Team vor, mit welcher Begründung, welchen Alternativen und welchen Tradeoffs, und wer entscheidet bis wann?

## Kontext
Problem-Beschreibung; bekannte Alternativen aus Vor-Diskussionen; betroffene Teams und Komponenten; Architektur-Constraints; gewünschter Entscheidungstermin; Status-Werte (Draft, In Review, Accepted, Rejected, Withdrawn).

## Beteiligte
- Owner: Ein Autor (Senior-Engineer, Architekt, PM oder TL)
- Teilnehmende: Ein Autor (Senior-Engineer, Architekt, PM oder TL); 3-20 Reviewer aus betroffenen Teams; eine benannte Entscheidungsinstanz (Tech Lead, Architecture Review Board, oder klar gewählter Decider); ein Sponsor für umstrittene RFCs.

## Input
RFC-Template im Repo (Kontext, Motivation, Solution, Alternatives, Drawbacks, Unresolved Questions, Migration); Repository oder Wiki für RFCs mit Nummerierung; Review-Tool mit Kommentaren (GitHub PR, GitLab MR, Notion Comments); Entscheidungs-Log.

## Vorlage
# 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.

## Fertigstellungscheck
- RFC-Dokument ist vollständig genug für Review:
- Ablageort:
- Version / Status:
- Review durch:
- Nächster Schritt:

## Nächster Schritt
- Ergebnis prüfen
- offene Fragen markieren
- Review oder Entscheidung terminieren