methodatlas
Session Builder

Plan my session

Plan a concrete work block with agenda, roles, preparation, and a copyable result artifact.

Async work run24 to 72 hasynchronousRFC document

Session: Request for Comments

The plan distributes preparation, review, and outcome work across an asynchronous work run. Your inputs flow directly into the session brief and work artifact.

Derived automatically

Async work run with 3-20 Reviewer. The plan uses the existing method logic and the runsheet.

Runsheet
Participation logic
Team round, shared work and alignment

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome logic
Finish artifact

The session works directly toward RFC document. After the session, the artifact should be shareable, reviewable, or reusable.

  1. 1

    Prepare brief

    15-30 min

    Prepare the working question, input, target artifact, and review deadline for Request for Comments. Link relevant data, sources, and existing artifacts.

    OwnerSession brief
  2. 2

    Work asynchronously

    24 to 72 h

    Participants work through the method along the template. Focus: add contributions directly to the artifact, mark assumptions, and link evidence.

    ParticipantsRFC document
  3. 3

    Consolidate review

    20-30 min

    Cluster comments, contradictions, and open questions. Sort unclear points into decisions, risks, or follow-ups.

    FacilitatorReview notes
  4. 4

    Finalize artifact

    15-30 min

    Create the integrated version, set status, and schedule the next review or decision point.

    OwnerReviewer comments
  5. 5

    Publish artifact

    10 min

    Check the artifact for completeness, define location, set version or status, and name review recipients.

    OwnerRFC document
Usable artifact

Session Brief

For invitations, boards, tickets, PR descriptions, or workshop notes.

session-brief.md

Session Brief: Request for Comments

Goal

Artifact: RFC document

Working Question

Which change does the team propose, with which rationale, alternatives and tradeoffs, and who decides by when?

Context

Problem description; known alternatives from pre-discussions; affected teams and components; architecture constraints; desired decision date; status values (Draft, In Review, Accepted, Rejected, Withdrawn).

Setup

  • Format: Async work run
  • Duration: 24 to 72 h
  • Mode: asynchronous
  • Participants: One author (senior engineer, architect, PM or TL); 3-20 reviewers from affected teams; named decision instance (Tech Lead, Architecture Review Board or clearly selected Decider); sponsor for disputed RFCs.
  • Owner: One author (senior engineer, architect, PM or TL)
  • Participation mode: Team round, shared work and alignment
  • Outcome logic: Finish artifact

Participation Logic

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome Logic

The session works directly toward RFC document. After the session, the artifact should be shareable, reviewable, or reusable.

Input

RFC template in repo (Context, Motivation, Solution, Alternatives, Drawbacks, Unresolved Questions, Migration); repository or wiki for RFCs with numbering; review tool with comments (GitHub PR, GitLab MR, Notion Comments); decision log.

Preparation

RFC number and file created in repo. Reviewers and Decider named. Review window with clear end date communicated. Template sections filled at least as skeleton.

Agenda

  1. Prepare brief (15-30 min) Owner: Owner Action: Prepare the working question, input, target artifact, and review deadline for Request for Comments. Link relevant data, sources, and existing artifacts. Output: Session brief

  2. Work asynchronously (24 to 72 h) Owner: Participants Action: Participants work through the method along the template. Focus: add contributions directly to the artifact, mark assumptions, and link evidence. Output: RFC document

  3. Consolidate review (20-30 min) Owner: Facilitator Action: Cluster comments, contradictions, and open questions. Sort unclear points into decisions, risks, or follow-ups. Output: Review notes

  4. Finalize artifact (15-30 min) Owner: Owner Action: Create the integrated version, set status, and schedule the next review or decision point. Output: Reviewer comments

  5. Publish artifact (10 min) Owner: Owner Action: Check the artifact for completeness, define location, set version or status, and name review recipients. Output: RFC document

Closeout

  • Update result artifact: RFC document
  • Define location, version, and review recipients.
  • Define owner, next step, and review date.
Usable artifact

Work artifact

Pre-filled starting point based on the matching template.

work-artifact.md

RFC document: Request for Comments

Working Question

Which change does the team propose, with which rationale, alternatives and tradeoffs, and who decides by when?

Context

Problem description; known alternatives from pre-discussions; affected teams and components; architecture constraints; desired decision date; status values (Draft, In Review, Accepted, Rejected, Withdrawn).

Participants

  • Owner: One author (senior engineer, architect, PM or TL)
  • Participants: One author (senior engineer, architect, PM or TL); 3-20 reviewers from affected teams; named decision instance (Tech Lead, Architecture Review Board or clearly selected Decider); sponsor for disputed RFCs.

Input

RFC template in repo (Context, Motivation, Solution, Alternatives, Drawbacks, Unresolved Questions, Migration); repository or wiki for RFCs with numbering; review tool with comments (GitHub PR, GitLab MR, Notion Comments); decision log.

Template

Request for Comments Working Template

Goal

Structured proposal document that describes a non-trivial change and intentionally collects feedback.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

  • RFC document:
  • Reviewer comments:
  • Decision with rationale:
  • Follow-up ADR or tickets:

Assumptions and open questions

  • ...

Decision / next step

Owner, date, and success signal.

Completion Check

  • RFC document is complete enough for review:
  • Location:
  • Version / status:
  • Review by:
  • Next step:

Next Step

  • Review result
  • Mark open questions
  • Schedule review or decision
Template base

Request for Comments Working Template

View templateCompact working template for Request for Comments with context, input, output artifacts, and next step.
markdown

rfc-working-template.md

Compact working template for Request for Comments with context, input, output artifacts, and next step.

Request for Comments Working Template

Goal

Structured proposal document that describes a non-trivial change and intentionally collects feedback.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

  • RFC document:
  • Reviewer comments:
  • Decision with rationale:
  • Follow-up ADR or tickets:

Assumptions and open questions

  • ...

Decision / next step

Owner, date, and success signal.

Ready to use when
  • Working question, owner, and target artifact are visible.
  • The result fits RFC document.
  • RFC number sequential. Status transitions logged. Status Accepted leads to ADR. Withdrawn RFCs are not deleted, but archived with status. New RFC for major change request, do not inflate old one.
  • Open questions are noted as follow-ups.
  • The next review or decision point is scheduled.
ProfileRunsheet