|
| 1 | +# Empathy Framework - Project Governance |
| 2 | + |
| 3 | +This document describes the governance structure and decision-making processes for the Empathy Framework. |
| 4 | + |
| 5 | +## Project Status |
| 6 | + |
| 7 | +**Current Phase**: Beta (Development Status :: 4) |
| 8 | +**Organization**: Deep Study AI, LLC |
| 9 | +**Primary Maintainer**: Patrick Roebuck |
| 10 | + |
| 11 | +## Governance Model |
| 12 | + |
| 13 | +The Empathy Framework follows a **Benevolent Dictator** governance model during the Beta phase, with a planned transition to **Meritocratic Contribution** model as the community grows. |
| 14 | + |
| 15 | +### Core Team |
| 16 | + |
| 17 | +**Primary Maintainer** (Current): |
| 18 | +- Patrick Roebuck ( [email protected]) |
| 19 | + - Final decision authority on feature acceptance |
| 20 | + - Architecture and design direction |
| 21 | + - Release management and versioning |
| 22 | + - Security response coordination |
| 23 | + |
| 24 | +**Future Core Team** (As community grows): |
| 25 | +- Additional maintainers will be added based on sustained, high-quality contributions |
| 26 | +- Core team members will have commit access and review authority |
| 27 | +- Decisions will be made by consensus when possible |
| 28 | + |
| 29 | +## Decision-Making Process |
| 30 | + |
| 31 | +### For Small Changes |
| 32 | +- Bug fixes, documentation improvements, minor refactoring |
| 33 | +- **Process**: Submit PR → Review by maintainer → Merge if passing tests |
| 34 | +- **Timeline**: Typically 1-3 days |
| 35 | + |
| 36 | +### For Medium Changes |
| 37 | +- New features, significant refactoring, API changes |
| 38 | +- **Process**: |
| 39 | + 1. Open GitHub Issue to discuss approach |
| 40 | + 2. Get feedback from maintainer |
| 41 | + 3. Submit PR with implementation |
| 42 | + 4. Review and iterate |
| 43 | + 5. Merge when approved |
| 44 | +- **Timeline**: Typically 1-2 weeks |
| 45 | + |
| 46 | +### For Major Changes |
| 47 | +- Architecture changes, breaking API changes, new plugins |
| 48 | +- **Process**: |
| 49 | + 1. Create detailed RFC (Request for Comments) in GitHub Discussions |
| 50 | + 2. Community discussion period (minimum 1 week) |
| 51 | + 3. Maintainer decision based on: |
| 52 | + - Alignment with project vision |
| 53 | + - Technical merit |
| 54 | + - Community support |
| 55 | + - Resource availability |
| 56 | + 4. Implementation via PR |
| 57 | +- **Timeline**: 2-4 weeks minimum |
| 58 | + |
| 59 | +### Security Issues |
| 60 | +- **Process**: Follow SECURITY.md |
| 61 | +- Private disclosure → Maintainer assessment → Fix → Disclosure |
| 62 | +- **Timeline**: 48-hour acknowledgment, 5-day initial assessment |
| 63 | + |
| 64 | +## Contributor Roles |
| 65 | + |
| 66 | +### Contributor |
| 67 | +- Anyone who submits a PR, issue, or participates in discussions |
| 68 | +- No special permissions required |
| 69 | +- All contributions welcome |
| 70 | + |
| 71 | +### Regular Contributor |
| 72 | +- Contributed 3+ merged PRs of high quality |
| 73 | +- Recognized in CONTRIBUTORS.md |
| 74 | +- May be consulted on relevant technical decisions |
| 75 | + |
| 76 | +### Core Contributor |
| 77 | +- Sustained high-quality contributions over 6+ months |
| 78 | +- Deep domain expertise in specific areas |
| 79 | +- Given triage permissions on GitHub |
| 80 | +- Can review PRs (but not merge without maintainer approval) |
| 81 | + |
| 82 | +### Maintainer |
| 83 | +- Granted by primary maintainer based on: |
| 84 | + - 12+ months of regular, high-quality contributions |
| 85 | + - Demonstrated technical judgment |
| 86 | + - Alignment with project vision |
| 87 | + - Community trust |
| 88 | +- Commit access and merge authority |
| 89 | +- Participate in architectural decisions |
| 90 | + |
| 91 | +## Release Process |
| 92 | + |
| 93 | +**Version Numbers**: Semantic Versioning (MAJOR.MINOR.PATCH) |
| 94 | + |
| 95 | +**Release Authority**: |
| 96 | +- PATCH releases: Any maintainer |
| 97 | +- MINOR releases: Core maintainers (consensus) |
| 98 | +- MAJOR releases: Primary maintainer decision after community input |
| 99 | + |
| 100 | +**Release Criteria**: |
| 101 | +- All tests passing (100%) |
| 102 | +- No critical security vulnerabilities |
| 103 | +- Updated CHANGELOG.md |
| 104 | +- Documentation updated |
| 105 | +- Version bumped in pyproject.toml |
| 106 | + |
| 107 | +**Release Schedule**: |
| 108 | +- PATCH: As needed for bug fixes (1-2 weeks) |
| 109 | +- MINOR: Quarterly for new features (every 3 months) |
| 110 | +- MAJOR: Annually or as needed for breaking changes |
| 111 | + |
| 112 | +## Conflict Resolution |
| 113 | + |
| 114 | +1. **Technical Disagreements**: |
| 115 | + - Discuss in GitHub issue or PR comments |
| 116 | + - If unresolved, maintainer makes final decision |
| 117 | + - Document reasoning for transparency |
| 118 | + |
| 119 | +2. **Code of Conduct Violations**: |
| 120 | + |
| 121 | + - Maintainer investigates |
| 122 | + - Actions: warning → temporary ban → permanent ban |
| 123 | + - Appeals allowed within 30 days |
| 124 | + |
| 125 | +3. **Maintainer Disputes** (Future): |
| 126 | + - When multiple maintainers exist |
| 127 | + - Majority vote among core maintainers |
| 128 | + - Primary maintainer breaks ties |
| 129 | + |
| 130 | +## Roadmap and Priorities |
| 131 | + |
| 132 | +**Short-term (Q1 2025)**: |
| 133 | +- Reach 70% test coverage |
| 134 | +- OpenSSF Best Practices preparation |
| 135 | +- Security hardening |
| 136 | +- Documentation improvements |
| 137 | + |
| 138 | +**Medium-term (Q2 2025)**: |
| 139 | +- Reach 90% test coverage |
| 140 | +- Achieve OpenSSF Passing Badge |
| 141 | +- Transition to Production/Stable (Development Status :: 5) |
| 142 | +- First commercial customers |
| 143 | + |
| 144 | +**Long-term (2025-2026)**: |
| 145 | +- Expand plugin ecosystem |
| 146 | +- Community-driven wizard contributions |
| 147 | +- OpenSSF Silver Badge |
| 148 | +- Enterprise features |
| 149 | + |
| 150 | +## License and Commercial Model |
| 151 | + |
| 152 | +**Dual Licensing**: |
| 153 | +- Fair Source 0.9 (LICENSE): Free for ≤5 employees, students, educators |
| 154 | +- Commercial License (LICENSE-COMMERCIAL.md): $99/developer/year for 6+ employees |
| 155 | + |
| 156 | +**Commercial Decision Authority**: Deep Study AI, LLC |
| 157 | + |
| 158 | +**License Changes**: Require community notice (30 days minimum) and only affect future versions |
| 159 | + |
| 160 | +## Amendment Process |
| 161 | + |
| 162 | +This governance document can be amended by: |
| 163 | +1. Proposal via GitHub Issue or Discussion |
| 164 | +2. Community feedback period (minimum 2 weeks) |
| 165 | +3. Final decision by primary maintainer |
| 166 | +4. Document updated with version history |
| 167 | + |
| 168 | +## Version History |
| 169 | + |
| 170 | +- **v1.0** (January 2025): Initial governance document created |
| 171 | + - Established Benevolent Dictator model for Beta phase |
| 172 | + - Defined contributor roles and decision processes |
| 173 | + - Outlined path to meritocratic model |
| 174 | + |
| 175 | +--- |
| 176 | + |
| 177 | +## Contact |
| 178 | + |
| 179 | +**Questions about governance?** |
| 180 | + |
| 181 | +- GitHub Discussions: https://github.com/Deep-Study-AI/Empathy/discussions |
| 182 | + |
| 183 | +**Want to contribute?** |
| 184 | +- See CONTRIBUTING.md for technical guidelines |
| 185 | +- See CODE_OF_CONDUCT.md for community standards |
0 commit comments