This RFC document is structured for use in Confluence, but can easily be adapted to any wiki system.
RFC Template
A structured format for technical proposals and design documents. Use what applies—skip sections that don’t.
Metadata
| Field | Description |
|---|---|
| Name | Descriptive title |
| Summary | 2-3 sentences on what this proposes |
| Status | Draft → In Progress → Feedback Requested → Accepted/Rejected |
| Author(s) | Who’s writing this |
| RFC Sponsor | Technical leadership representative supporting this |
| Proposed Date | When the RFC was created |
| Feedback Due By | Deadline for feedback |
| Feedback Requested From | Specific reviewers needed |
Core Sections
Context
What must be understood before thinking about this problem? Link relevant specs or prior art.
Don’t fill everything out. The template exists to prompt thinking, not create busywork. A focused RFC with Context, Goals, and Design is better than a comprehensive one nobody reads.
Write for your reviewers. They’re busy. Lead with what matters. Put details in appendices if needed.
Goals / Non-Goals
Goals
- What you’re trying to achieve.
Non-Goals
- What you’re explicitly not addressing
- This scopes the RFC and prevents scope creep during review.
Design
The actual solution. This is the meat of the document. Include enough detail that someone could implement it, but not so much that you’re writing the code.
Supporting Sections
Include these when relevant.
Terminology
Define terms that aren’t obvious. Skip if everything is well-known.
Current System Use-Case
If replacing something, explain what exists and why it’s insufficient.
Assumptions
What you’re assuming to be true. Multi-tenant? Data validity? User geography? Scale expectations?
Limitations
Where this might break. Be honest about trade-offs—reviewers will find them anyway.
Technology
New — Technologies being added and why.
Deprecated — Technologies being removed.
APIs
New or modified APIs. Include request/response examples if helpful.
Failure Scenarios
What happens when things go wrong? How does the system degrade?
Alternatives Considered
Other approaches you evaluated and why you didn’t pick them. Shows reviewers you’ve thought it through.
Development/Complexity Estimate
Rough timeline or effort. T-shirt sizes are fine.
Testing Strategy
How you’ll verify it works: E2E, load testing, integration, etc.
Monitoring
How you’ll know it’s working in production. KPIs, alerts, SLAs.
Security and Compliance
If any of these apply, loop in your security/compliance team:
- Modifies authentication or session management
- Changes user roles or access rights
- Could cause major system disruptions if it fails
- Adds critical external dependencies
- Changes how user data is collected, used, shared, or tracked
- Requires new infrastructure (data centers, cloud providers)
- Introduces new data exchange methods (webhooks, new API types)
- Is a new standalone product or requires deep architecture changes
Version History
Track significant changes to the RFC itself.
| Version | Date | Changes |
|---|---|---|
| 1.0 | [Date] | Initial draft |
