REP: 2001
Title: REP Process Definition
Author: Radiant Core Contributors <[email protected]>
Status: Active
Type: Process
Created: 2024-12-31
License: MIT
This document defines the Radiant Enhancement Proposal (REP) process, providing guidelines for creating, submitting, and managing REPs. The REP process is inspired by Bitcoin Improvement Proposals (BIPs) and adapted for the Radiant ecosystem's unique needs and architecture.
- Standard Track (REP-1 to REP-999): Protocol changes affecting most Radiant implementations
- Informational (REP-1001 to REP-1999): Design issues, guidelines, informational content
- Process (REP-2000 to REP-2999): Process changes and governance
Each REP must include:
REP: Title: <title> Author: <author(s)> Status: <Draft|Active|Final|Rejected|Withdrawn> Type: <Standard|Informational|Process> Created: <ISO 8601 date> License: MIT
### Required Sections
- **Abstract** (~200 words)
- **Specification** (technical details)
- **Motivation** (why this is needed)
- **Rationale** (design decisions)
- **Backwards Compatibility** (migration path)
- **Reference Implementation** (for Standard Track)
- **Security Considerations** (attack vectors, mitigations)
### REP Lifecycle
1. **Draft**: Initial proposal, editable by author
2. **Active**: Under consideration, implementation may begin
3. **Final**: Accepted and implemented, specification stable
4. **Rejected**: Considered and rejected by community
5. **Withdrawn**: Author withdrew the proposal
## Motivation
The Radiant ecosystem needs a structured process for proposing and discussing major changes. A formal REP process ensures:
- Clear communication of technical proposals
- Community input and consensus building
- Documentation of design decisions
- Structured review process
- Historical record of changes
## Rationale
The REP process balances several competing needs:
### Simplicity vs. Thoroughness
- Simple enough for casual contributors
- Thorough enough for major protocol changes
- Clear guidelines reduce ambiguity
### Flexibility vs. Consistency
- Flexible enough for different types of proposals
- Consistent format for easy review
- Adaptable to future needs
### Speed vs. Quality
- Fast enough for iterative development
- Quality gates for critical changes
- Security-focused review process
### Inspiration from Other Projects
- Bitcoin BIPs: Proven track record for protocol changes
- Ethereum EIPs: Modern governance practices
- Python PEPs: Community-driven process
## Backwards Compatibility
This REP process itself is backwards compatible with existing development practices. Existing GitHub issues and pull requests will continue to work alongside the formal REP process.
## Reference Implementation
This REP process is implemented through:
1. Repository structure and templates
2. GitHub issue and PR templates
3. Review guidelines for maintainers
4. Community documentation
## Security Considerations
### Protocol Security
- Standard Track REPs require security analysis
- Reference implementation must be audited
- Test coverage requirements
- Network upgrade considerations
### Process Security
- Clear escalation paths for security REPs
- Private disclosure process for vulnerabilities
- Coordination with multiple implementations
- Timeline management for security fixes
### Social Considerations
- Prevent REP spam and low-quality proposals
- Ensure diverse community representation
- Balance speed with thorough review
- Handle controversial proposals gracefully
## Repository Structure
REP/ ├── README.md # Overview and quick links ├── REP-2001.md # This document ├── rep-template.md # Template for new REPs ├── active/ # Active REPs under consideration ├── final/ # Accepted and implemented REPs ├── rejected/ # Rejected REPs ├── withdrawn/ # Withdrawn REPs └── draft/ # Draft REPs (in PRs)
### Directory Management
- **draft/**: Temporary for PRs, cleared after merge
- **active/**: REPs being actively considered
- **final/**: Accepted REPs, immutable
- **rejected/**: Rejected REPs, with rejection rationale
- **withdrawn/**: Withdrawn REPs, with withdrawal reason
## Submission Process
### 1. Pre-Submission Discussion
- Discuss idea on community channels
- Gauge interest and gather feedback
- Identify potential concerns early
### 2. Draft Creation
- Use [rep-template.md](rep-template.md)
- Follow format requirements exactly
- Include all required sections
- Be thorough and precise
### 3. Pull Request
- Submit REP as PR to this repository
- Use appropriate PR template
- Link to related discussions
- Request reviews from relevant experts
### 4. Community Review
- Active review period (minimum 2 weeks)
- Address feedback promptly
- Update REP based on input
- Maintain professional discourse
### 5. Status Changes
- **Draft → Active**: Initial review passed
- **Active → Final**: Implementation complete and tested
- **Any → Rejected**: Consensus against adoption
- **Any → Withdrawn**: Author choice
## Review Guidelines
### For Reviewers
- Focus on technical merit and clarity
- Consider backwards compatibility
- Evaluate security implications
- Provide constructive feedback
- Check format compliance
### For Authors
- Respond to all feedback
- Update REP promptly
- Explain design decisions
- Consider alternative approaches
- Maintain professional tone
### For Maintainers
- Facilitate constructive discussion
- Ensure process compliance
- Manage status transitions
- Document decisions
- Coordinate with other implementations
## Quality Standards
### Technical Requirements
- Clear, unambiguous specification
- Complete implementation details
- Comprehensive security analysis
- Backwards compatibility plan
- Test coverage strategy
### Documentation Requirements
- Well-structured and readable
- Examples where helpful
- References to related work
- Clear rationale for decisions
- Proper formatting and style
### Community Requirements
- Prior discussion evidence
- Responsive to feedback
- Collaborative approach
- Respect for alternative views
- Commitment to completion
## Special Cases
### Security REPs
- Private disclosure option available
- Coordinated disclosure timeline
- Security expert review required
- Implementation coordination
### Emergency REPs
- Fast-track process for critical issues
- Shorter review periods
- Immediate implementation consideration
- Post-implementation documentation
### Controversial REPs
- Extended review periods
- Community polling mechanisms
- Multiple implementation requirements
- Clear consensus criteria
## Future Improvements
Potential enhancements to consider:
- Automated REP validation tools
- Integration with development workflows
- REP status tracking and notifications
- Multi-language support
- Formal voting mechanisms
## References
- [Bitcoin Improvement Proposals](https://github.com/bitcoin/bips)
- [Ethereum Improvement Proposals](https://eips.ethereum.org/)
- [Python Enhancement Proposals](https://peps.python.org/)
- [RFC Process](https://www.ietf.org/standards/process/)
## Copyright
This document is licensed under the MIT License.