71 lines
2.4 KiB
Markdown
71 lines
2.4 KiB
Markdown
# Governance
|
|
|
|
## Governance model
|
|
|
|
Xget currently follows a maintainer-led governance model. The project is still
|
|
small enough that a lightweight process works best, but decisions should remain
|
|
transparent and open to community input.
|
|
|
|
## Current maintainer
|
|
|
|
- [Xi Xu](https://xi-xu.com)
|
|
|
|
The primary maintainer is responsible for project direction, releases, final
|
|
review decisions, security response coordination, and enforcement of the
|
|
[Code of Conduct](CODE_OF_CONDUCT.md).
|
|
|
|
## Roles
|
|
|
|
### Users
|
|
|
|
Users rely on the project, report issues, request features, and help validate
|
|
behavior across environments.
|
|
|
|
### Contributors
|
|
|
|
Contributors improve the project through code, documentation, issue triage,
|
|
testing, design feedback, translations, operational guidance, or community
|
|
support.
|
|
|
|
### Maintainers
|
|
|
|
Maintainers are trusted contributors with additional responsibility for the
|
|
health of the project. Maintainers may review and merge changes, shape project
|
|
direction, manage releases, and coordinate responses to sensitive issues.
|
|
|
|
## Decision-making
|
|
|
|
- Day-to-day decisions are made through issues, pull requests, and maintainer
|
|
review
|
|
- Community input is encouraged for significant behavioral, API, governance, or
|
|
deployment changes
|
|
- Consensus is preferred when practical
|
|
- When consensus is unclear, the primary maintainer has final decision-making
|
|
authority
|
|
|
|
## Becoming a maintainer
|
|
|
|
Additional maintainers may be added as the project grows. The usual path is:
|
|
|
|
1. Make sustained, high-quality contributions over time
|
|
2. Demonstrate good judgment, respectful collaboration, and project context
|
|
3. Help with review, issue triage, documentation, or support beyond code alone
|
|
4. Receive an invitation from the current maintainer
|
|
|
|
There is no automatic threshold for maintainer access. Trust, consistency, and
|
|
care for the project matter more than contribution count alone.
|
|
|
|
## Project direction and releases
|
|
|
|
- The roadmap may evolve based on user needs, maintainer capacity, and platform
|
|
changes
|
|
- Maintainers may decline features that add long-term maintenance burden, reduce
|
|
security, or broaden the scope beyond the core mission of Xget
|
|
- Releases, backports, and support windows are managed on a best-effort basis
|
|
|
|
## Transparency
|
|
|
|
Important technical and product decisions should, whenever possible, be
|
|
documented in public issues, pull requests, or repository documentation so the
|
|
community can understand how the project is evolving.
|