Rfc Template

---
name: rfc-template
enabled: true
description: |
  Use when performing rfc template — structures a Request for Comments (RFC)
  document for proposing significant technical changes that require cross-team
  input and approval. This template guides authors through problem definition,
  proposed solution, alternatives analysis, and rollout planning, ensuring
  proposals are comprehensive enough for informed review.
required_connections:
  - prefix: wiki
    label: "Documentation Platform"
config_fields:
  - key: rfc_number
    label: "RFC Number"
    required: true
    placeholder: "e.g., RFC-2026-015"
  - key: title
    label: "RFC Title"
    required: true
    placeholder: "e.g., Migrate to event-driven architecture"
  - key: author
    label: "Author"
    required: true
    placeholder: "e.g., Jane Smith"
features:
  - RFC
  - DOCUMENTATION
  - ARCHITECTURE
---

# Request for Comments (RFC)

## Phase 1: Problem Statement

Define the problem clearly and concisely.

1. - [ ] What is the current state?
2. - [ ] What is the problem or opportunity?
3. - [ ] Who is affected?
4. - [ ] What is the cost of inaction?
5. - [ ] 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.

1. - [ ] High-level overview (1-2 paragraphs)
2. - [ ] Detailed technical design
3. - [ ] Architecture diagrams
4. - [ ] API changes or new APIs
5. - [ ] Data model changes
6. - [ ] 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

1. - [ ] Phase 1: ___ (description, timeline, success criteria)
2. - [ ] Phase 2: ___ (description, timeline, success criteria)
3. - [ ] 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