GOVERNANCE.md

Project Governance

This document outlines how the Semaphore project is governed.

Overview

Semaphore follows a governance model that balances commercial stewardship with community participation. The project is primarily maintained by Semaphore (the company) while encouraging active community involvement.

Roles and Responsibilities

Project Owner (Semaphore)

• Sets project vision and roadmap
• Makes final decisions on features
• Manages security response team
• Controls release process
• Manages maintainer appointments

Core Maintainers

• Review and merge pull requests
• Triage issues and pull requests
• Guide architectural decisions
• Mentor contributors
• Help enforce code of conduct

Community Contributors

• Submit pull requests
• Report bugs
• Suggest features
• Help other users
• Improve documentation

Decision Making Process

Technical Decisions

1. Discussion Phase

   • Open GitHub Discussion or Issue
   • Community feedback period
   • Technical design review

2. Implementation Phase

   • Pull Request submission
   • Code review
   • Testing and validation

3. Final Review

   • Maintainer approval
   • Company review for strategic alignment
   • Merge decision

Feature Decisions

1. Community Edition

   • Community proposals welcome
   • Discussed openly
   • Must align with project goals
   • Final decision by maintainers

2. Enterprise Edition

   • Company-driven roadmap
   • Customer feedback prioritized
   • Community input considered
   • Final decision by Semaphore

Becoming a Maintainer

Requirements

• Consistent contribution history
• Deep understanding of the project
• Good standing in community
• Commitment to project's success

Process

1. Nomination by existing maintainer
2. Review of contribution history
3. Discussion among current maintainers
4. Trial period (3 months)
5. Final approval by Project Owner

Communication

Official Channels

• GitHub Issues and Discussions
• Project Documentation
• Discord Server

Decision Visibility

• Technical decisions documented in issues/PRs
• Architecture decisions documented in RFCs
• Roadmap publicly available

Code of Conduct

All participants must follow our Code of Conduct.

Commercial and Community Balance

Open Source Commitment

• Core functionality remains open source
• Community features reviewed fairly
• Transparent decision making
• Open development process

Enterprise Considerations

• Enterprise features in ee/ directory
• Clear feature distinction
• Commercial viability maintained
• Customer needs balanced with community

Changes to Governance

1. Propose changes via GitHub Discussion
2. 2-week comment period
3. Maintainer review
4. Project Owner approval
5. Document update