Skip to content

GOVERNANCE.md

Latest commit

 

History

History
185 lines (126 loc) · 5.96 KB

GOVERNANCE.md

File metadata and controls

185 lines (126 loc) · 5.96 KB

Project Governance — Unit09

This document describes how the Unit09 project is governed, how decisions are made, and how contributors can take on more responsibility over time.

The goal is to keep governance lightweight, transparent, and focused on maintaining a healthy technical and social ecosystem.

1. Roles and responsibilities

1.1. Users

Users are anyone who interacts with Unit09:

  • Running Unit09 deployments or using hosted instances
  • Building on top of the SDK and modules
  • Reading documentation and filing bug reports

Users are encouraged to:

  • Report bugs and usability issues
  • Suggest features and improvements
  • Participate in discussions constructively

1.2. Contributors

Contributors are community members who make changes to the project, including:

  • Code contributions (features, fixes, refactors)
  • Documentation and examples
  • Testing, tooling, or infrastructure improvements
  • Design, UX, or content contributions

Contributors:

  • Submit pull requests
  • Participate in code review
  • Help triage issues and support other users

1.3. Maintainers

Maintainers are contributors who have been granted additional responsibilities, typically including:

  • Write access to the repository
  • Authority to review and merge pull requests
  • Responsibility for releases and tagging
  • Stewardship of technical direction within specific areas

Maintainers are expected to:

  • Lead by example in tone, code quality, and collaboration
  • Review contributions promptly and fairly
  • Coordinate on larger architectural or roadmap decisions
  • Enforce the Code of Conduct when necessary

2. Decision-making

2.1. Day-to-day decisions

Most day-to-day decisions are made through:

  • Pull request review and discussion
  • Issue comments and design discussions
  • Informal chats in community channels

Any maintainer can approve and merge changes that fall within their area of expertise, as long as:

  • The change is in scope for the project
  • Tests and CI checks pass
  • Concerns from other reviewers are addressed

2.2. Larger changes

Larger or potentially controversial changes may require a more structured proposal. Examples include:

  • Major architectural changes in the core engine or on-chain program
  • Significant new features that expand the scope of Unit09
  • Backward-incompatible API changes
  • Changes to security-sensitive components

For these changes, the typical process is:

  1. Open an issue or proposal document describing the motivation, design, and alternatives.
  2. Gather feedback from maintainers and interested contributors.
  3. Iterate until there is rough consensus.
  4. Implement the change in one or more pull requests, with clear migration notes.

2.3. Consensus and disagreement

The project aims for consensus-driven decision-making. When disagreement arises, participants should:

  • Focus on the technical trade-offs and user impact
  • Provide concrete examples and data when possible
  • Be willing to compromise or explore alternatives

If consensus cannot be reached in a reasonable time frame, the maintainers responsible for the affected area may make a final decision, taking into account the discussion and long-term project health.

3. Becoming a maintainer

There is no formal election process for maintainers. Instead, maintainers are typically invited based on:

  • Consistent, high-quality contributions over time
  • Demonstrated understanding of the codebase and project goals
  • Willingness to participate in code reviews and community support
  • Alignment with the Code of Conduct and community values

If you are interested in becoming a maintainer:

  1. Contribute regularly in your area of interest.
  2. Help review pull requests and triage issues.
  3. Make your interest known to existing maintainers, for example by opening an issue or reaching out in community channels.

Maintainership is not a lifetime status; it may be adjusted as people’s availability and focus change.

4. Releases

Releases are handled by maintainers with release responsibilities.

Typical release responsibilities include:

  • Determining the scope of the release.
  • Ensuring tests and CI pipelines are passing.
  • Updating version numbers and changelog entries.
  • Tagging the release in version control.
  • Publishing artifacts (containers, SDK packages, etc.).
  • Communicating changes to the community.

Release frequency depends on project activity and stability needs. Patch releases may be made for important bug fixes or security issues.

5. Security and risk-sensitive changes

Security-sensitive changes follow the process described in SECURITY.md. In general:

  • Discussions about unpatched vulnerabilities are kept private.
  • Fixes are reviewed by multiple maintainers when possible.
  • Public disclosure is coordinated to give operators time to upgrade.

6. Governance changes

This governance document itself may evolve as the project grows.

Proposed changes to governance should be made via pull request and should:

  • Explain the motivation for the change.
  • Describe how it will affect contributors and maintainers.
  • Provide a clear and concise updated policy text.

Major governance changes should be discussed openly and given sufficient time for community feedback before being merged.

7. Relationship to tokens and economics

If the Unit09 ecosystem involves tokens or economic mechanisms, those are governed by their own documents, such as:

  • Token economics or whitepapers
  • Protocol governance frameworks
  • DAO or multisig charters

This document focuses on the open source software project itself. Any overlap between protocol governance and software governance should be made explicit in separate documents.

8. Contact

For questions about governance, you can:

  • Open a discussion or issue in the repository (for non-sensitive topics).
  • Reach out to maintainers via the contact channels listed in README.md, SECURITY.md, or the project website.

The goal is to keep the project open, predictable, and welcoming to new contributors while maintaining a coherent technical direction.