Request for Comments (RFC)
Phase 1: Problem Statement
Define the problem clearly and concisely.
- What is the current state?
- What is the problem or opportunity?
- Who is affected?
- What is the cost of inaction?
- What are the success criteria for a solution?
Metadata:
| Field | Value |
|---|---|
| RFC Number | |
| Title | |
| Author | |
| Status | Draft / Open for Comment / Final Comment Period / Accepted / Rejected |
| Created | |
| Comment Deadline | |
| Reviewers |
Phase 2: Proposed Solution
Describe the proposed approach in detail.
- High-level overview (1-2 paragraphs)
- Detailed technical design
- Architecture diagrams
- API changes or new APIs
- Data model changes
- User experience changes
Scope:
- What is in scope for this RFC
- What is explicitly out of scope
- What are the dependencies
Phase 3: Alternatives Considered
| Alternative | Description | Why Not Chosen |
|---|---|---|
For each alternative:
- Describe the approach
- List advantages over the proposed solution
- List disadvantages compared to the proposed solution
Phase 4: Impact Analysis
Compatibility:
- Backward compatible: Y/N
- Migration required: Y/N
- Breaking changes: list
Performance:
- Expected performance impact
- Benchmarks or estimates
Security:
- Security implications
- New attack surfaces
Cost:
- Infrastructure cost changes
- Engineering effort estimate
- Ongoing maintenance cost
Risk Assessment:
| Risk | Likelihood | Impact | Mitigation |
|---|---|---|---|
Phase 5: Rollout Plan
- Phase 1: ___ (description, timeline, success criteria)
- Phase 2: ___ (description, timeline, success criteria)
- Phase 3: ___ (description, timeline, success criteria)
- Rollback plan
- Feature flag strategy
- Monitoring and validation approach
Phase 6: Open Questions
| Question | Raised By | Status | Resolution |
|---|---|---|---|
Counter-Rationalizations
| Shortcut | Counter | Why |
|---|---|---|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |
Output Format
RFC Summary
- RFC: ___
- Title: ___
- Status: ___
- Decision: Accepted / Rejected / Deferred
- Decision Date: ___
- Decision Rationale: ___
Action Items
- Address all open questions
- Incorporate reviewer feedback
- Create implementation plan and tickets
- Schedule kickoff for implementation
- Archive RFC in decision log