RFC Process Skill
When to Use This Skill
Use this skill when:
- Rfc Process tasks - Working on request for comments (rfc) process for technical proposals
- Planning or design - Need guidance on Rfc Process approaches
- Best practices - Want to follow established patterns and standards
Overview
Facilitate the Request for Comments (RFC) process for technical proposals and design decisions.
MANDATORY: Documentation-First Approach
Before creating RFCs:
- Invoke
docs-managementskill for RFC patterns - Verify RFC best practices via MCP servers (perplexity)
- Base guidance on IETF RFC style adapted for software teams
RFC vs ADR
RFC vs ADR Comparison:
RFC (Request for Comments):
• For proposals BEFORE decision is made
• Invites discussion and feedback
• May be accepted, rejected, or revised
• Typically larger scope than ADRs
• Used for significant changes requiring consensus
ADR (Architecture Decision Record):
• Documents decisions AFTER they are made
• Records the decision and rationale
• Immutable once accepted
• Focused on single decisions
• Used for all significant architecture decisions
Relationship:
RFC (Proposal) → Discussion → Decision → ADR (Record)RFC Template
# RFC-[NUMBER]: [TITLE]
| Property | Value |
|----------|-------|
| **RFC Number** | RFC-[NUMBER] |
| **Title** | [Short, descriptive title] |
| **Author(s)** | [Name(s)] |
| **Status** | [Draft \| Open for Comment \| Final Comment \| Accepted \| Rejected \| Withdrawn] |
| **Created** | [YYYY-MM-DD] |
| **Updated** | [YYYY-MM-DD] |
| **Target Decision Date** | [YYYY-MM-DD] |
| **Stakeholders** | [Teams/Individuals] |
---
## Summary
[One paragraph executive summary. What is being proposed and why?]
---
## Motivation
### Problem Statement
[What problem does this RFC solve? Why is the current situation inadequate?]
### Goals
- [Goal 1]
- [Goal 2]
- [Goal 3]
### Non-Goals
- [Non-goal 1: What this RFC explicitly does NOT address]
- [Non-goal 2]
---
## Proposal
### Overview
[High-level description of the proposed solution]
### Detailed Design
[In-depth technical description. Include:
- Architecture changes
- API changes
- Data model changes
- Algorithm descriptions
- Integration points]
### Example Usage
// Code example showing how the proposal would be used public class ExampleUsage { public async Task Example() { // Demonstrate the proposed API or pattern } }
### Migration Plan
[How will existing systems/data be migrated?]
1. Phase 1: [Description]
2. Phase 2: [Description]
3. Phase 3: [Description]
---
## Alternatives Considered
### Alternative 1: [Name]
**Description:** [What this alternative entails]
**Pros:**
- [Pro 1]
- [Pro 2]
**Cons:**
- [Con 1]
- [Con 2]
**Why Not Chosen:** [Reason for rejecting this alternative]
### Alternative 2: [Name]
[Same structure...]
### Status Quo (Do Nothing)
**Description:** Continue with current approach
**Pros:**
- No migration effort
- No learning curve
**Cons:**
- [Problems that motivated this RFC remain]
---
## Trade-offs
| Trade-off | Chosen Path | Alternative Path |
| --- | --- | --- |
| [Trade-off 1] | [What we accept] | [What we give up] |
| [Trade-off 2] | [What we accept] | [What we give up] |
---
## Risks and Mitigations
| Risk | Likelihood | Impact | Mitigation |
| --- | --- | --- | --- |
| [Risk 1] | Low/Medium/High | Low/Medium/High | [Mitigation strategy] |
| [Risk 2] | Low/Medium/High | Low/Medium/High | [Mitigation strategy] |
---
## Implementation Plan
### Timeline
| Phase | Description | Duration | Dependencies |
| --- | --- | --- | --- |
| Phase 1 | [Description] | [Duration] | [Dependencies] |
| Phase 2 | [Description] | [Duration] | [Dependencies] |
### Resource Requirements
- [Resource 1: e.g., "2 senior engineers for 4 weeks"]
- [Resource 2: e.g., "Infrastructure team support"]
### Success Criteria
- [Criterion 1: Measurable success indicator]
- [Criterion 2: Measurable success indicator]
### Rollback Plan
[How to revert if the implementation fails]
---
## Security Considerations
[Security implications of this proposal]
- [Consideration 1]
- [Consideration 2]
---
## Privacy Considerations
[Privacy implications of this proposal]
- [Consideration 1]
- [Consideration 2]
---
## Testing Strategy
[How will this be tested?]
- Unit tests: [Approach]
- Integration tests: [Approach]
- Performance tests: [Approach]
- Rollout plan: [Canary, percentage rollout, etc.]
---
## Documentation Updates
[What documentation needs to be created or updated?]
- [Doc 1: e.g., "API reference"]
- [Doc 2: e.g., "Developer guide"]
- [Doc 3: e.g., "Operations runbook"]
---
## Open Questions
[Questions that need to be resolved during the comment period]
1. [Question 1]
2. [Question 2]
---
## Feedback
### Comments
[Space for discussion - may link to external discussion thread]
| Date | Author | Comment | Resolution |
| --- | --- | --- | --- |
| [Date] | [Name] | [Comment] | [Resolution] |
### Revision History
| Version | Date | Author | Changes |
| --- | --- | --- | --- |
| 0.1 | [Date] | [Name] | Initial draft |
| 0.2 | [Date] | [Name] | [Changes made] |
---
## References
- [Reference 1]
- [Reference 2]
- [Related RFC/ADR]
## RFC Lifecycle
RFC Status Flow:
┌─────────────────────────────────────────────────────────────────────────────┐ │ │ │ ┌──────────┐ ┌─────────────────┐ ┌──────────────────┐ │ │ │ Draft │────▶│ Open for Comment │────▶│ Final Comment │ │ │ └──────────┘ └─────────────────┘ └──────────────────┘ │ │ │ │ │ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ Withdrawn│ │ Withdrawn│ │ Accepted │ │ │ └──────────┘ └──────────┘ └──────────┘ │ │ │ │ │ ┌──────────┐ │ │ │ │ Rejected │◀───────────┤ │ │ └──────────┘ │ │ │ ▼ │ │ ┌──────────────┐ │ │ │ Implemented │ │ │ └──────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────────────────┘
Timeline: • Draft: Author preparing, not ready for review • Open for Comment: 2 weeks minimum for feedback • Final Comment: 1 week for last objections • Accepted/Rejected: Decision made • Implemented: Work completed
## When to Write an RFC
| Situation | RFC Needed? |
| --- | --- |
| New microservice | Yes |
| Change in data model | Yes |
| New public API | Yes |
| Internal refactoring | Maybe |
| Bug fix | No |
| Minor enhancement | No |
| Breaking change | Yes |
| New technology adoption | Yes |
| Deprecation | Yes |
## RFC Roles
| Role | Responsibility |
| --- | --- |
| **Author** | Writes RFC, addresses feedback, drives to decision |
| **Reviewer** | Provides technical feedback |
| **Stakeholder** | Represents affected team or system |
| **Approver** | Makes final accept/reject decision |
| **Editor** | Ensures RFC meets standards (optional) |
## Lightweight RFC (Design Doc)
For smaller proposals, use this abbreviated format:
Design Doc: [TITLE]
Author: [Name] Date: [Date] Status: [Draft/Review/Approved]
Context
[What problem are we solving?]
Proposal
[What are we going to do?]
Alternatives
[What else did we consider?]
Decision
[What did we decide and why?]
## RFC Registry
RFC Registry
Active RFCs
| RFC | Title | Author | Status | Target Date |
|---|---|---|---|---|
| RFC-012 | [Title] | [Author] | Open for Comment | 2025-02-15 |
| RFC-013 | [Title] | [Author] | Draft | - |
Accepted RFCs
| RFC | Title | Accepted | ADR |
|---|---|---|---|
| RFC-010 | [Title] | 2025-01-10 | ADR-025 |
| RFC-011 | [Title] | 2025-01-15 | ADR-026 |
Rejected/Withdrawn RFCs
| RFC | Title | Status | Reason |
|---|---|---|---|
| RFC-008 | [Title] | Rejected | [Brief reason] |
| RFC-009 | [Title] | Withdrawn | [Brief reason] |
## Best Practices
### For Authors
1. **Start discussions early**: Share drafts before formal RFC
2. **Be thorough**: Address obvious concerns preemptively
3. **Stay objective**: Present alternatives fairly
4. **Respond promptly**: Engage with feedback quickly
5. **Know when to pivot**: Be willing to change or withdraw
### For Reviewers
1. **Be constructive**: Suggest improvements, not just problems
2. **Be timely**: Respect deadlines
3. **Focus on substance**: Don't bikeshed
4. **Ask questions**: Clarify before criticizing
5. **Propose alternatives**: If you disagree, suggest alternatives
## Workflow
When creating RFCs:
1. **Identify Need**: Recognize significant change requiring consensus
2. **Draft RFC**: Use template, focus on clarity
3. **Pre-Review**: Share informally for early feedback
4. **Publish**: Move to "Open for Comment"
5. **Discuss**: Engage with feedback, revise as needed
6. **Finalize**: Move to "Final Comment"
7. **Decide**: Accept, reject, or withdraw
8. **Record**: Create ADR if accepted
## Further Reading
For detailed guidance:
---
**Last Updated:** 2025-12-26