methodatlas
Session Builder

Meine Session planen

Plane einen konkreten Arbeitsblock mit Agenda, Rollen, Vorbereitung und kopierbarem Ergebnisartefakt.

Async-Arbeitslauf24 bis 72 hasynchronRFC-Dokument

Session: Request for Comments

Der Plan verteilt Vorbereitung, Review und Ergebnisarbeit über einen asynchronen Arbeitslauf. Die Eingaben fließen direkt in Session Brief und Arbeitsartefakt.

Automatisch abgeleitet

Async-Arbeitslauf mit 3-20 Reviewer. Der Plan nutzt die vorhandene Methodenlogik und das Runsheet.

Runsheet
Beteiligungslogik
Teamrunde, gemeinsames Arbeiten und Alignment

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

Ergebnislogik
Artefakt fertigstellen

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

  1. 1

    Brief vorbereiten

    15-30 min

    Arbeitsfrage, Input, Zielartefakt und Reviewfrist für Request for Comments vorbereiten. Verlinke relevante Daten, Quellen und bestehende Artefakte.

    OwnerSession Brief
  2. 2

    Asynchron bearbeiten

    24 bis 72 h

    Teilnehmende arbeiten die Methode entlang der Vorlage durch. Fokus: Beiträge direkt am Artefakt ergänzen, Annahmen markieren und Belege verlinken.

    TeilnehmendeRFC-Dokument
  3. 3

    Review bündeln

    20-30 min

    Kommentare, Widersprüche und offene Fragen clustern. Unklare Punkte als Entscheidungen, Risiken oder Follow-ups einsortieren.

    FacilitatorReview Notes
  4. 4

    Artefakt finalisieren

    15-30 min

    Eingearbeitete Version erstellen, Status setzen und nächsten Review oder Entscheidungspunkt terminieren.

    OwnerReviewer-Kommentare
  5. 5

    Artefakt veröffentlichen

    10 min

    Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.

    OwnerRFC-Dokument
Nutzbares Artefakt

Session Brief

Für Einladung, Board, Ticket, PR-Beschreibung oder Workshop-Notiz.

session-brief.md

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. 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. 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. Output: Review Notes

  4. Artefakt finalisieren (15-30 min) Owner: Owner Aktion: Eingearbeitete Version erstellen, Status setzen und nächsten Review oder Entscheidungspunkt terminieren. 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.
Nutzbares Artefakt

Arbeitsartefakt

Vorgefüllter Startpunkt auf Basis der passenden Vorlage.

arbeitsartefakt.md

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 Runsheets.

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
Vorlagenbasis

Request for Comments Arbeitsvorlage

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

rfc-working-template.md

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

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 Runsheets.

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.

Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu RFC-Dokument.
  • RFC-Nummer fortlaufend. Status-Übergänge protokolliert. Status Accepted führt zu ADR. Withdrawn-RFCs nicht löschen, sondern mit Status archivieren. Pro Major-Change-Request neuer RFC, nicht alter aufbohren.
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.
SteckbriefRunsheet