Skip to content

GOVERNANCE.md

Latest commit

 

History

History
160 lines (107 loc) · 5.86 KB

GOVERNANCE.md

File metadata and controls

160 lines (107 loc) · 5.86 KB

ThemisDB — Project Governance

Status: Active
Version: 1.0
Last Updated: 2026-04-13

This document describes how the ThemisDB project is governed: how decisions are made, who has authority over what, and how contributors can advance to positions of greater responsibility.

Table of Contents

  1. Guiding Principles
  2. Roles and Responsibilities
  3. Decision-Making Process
  4. Contribution Policy
  5. Code Review Standards
  6. Conflict Resolution
  7. Changes to Governance

1. Guiding Principles

ThemisDB is guided by the following principles:

  • Openness — All source code is public. Development discussions happen in the open on GitHub.
  • Correctness over speed — We prefer a well-reviewed, tested change over a fast one.
  • Backward compatibility — Breaking changes require a MAJOR version bump and a migration guide.
  • Security first — Security vulnerabilities are treated as P0 and handled with confidential disclosure. See SECURITY.md.
  • Documentation parity — Every API and module change must be reflected in the documentation.

2. Roles and Responsibilities

2.1 Users

Anyone using ThemisDB. Users contribute by filing issues, asking questions in Discussions, and providing feedback.

2.2 Contributors

Anyone who has submitted at least one merged pull request. Contributors are encouraged to review PRs, help triage issues, and mentor other contributors.

2.3 Module Maintainers

Maintainers are responsible for one or more source modules. They:

  • Review and merge PRs for their module (with Project Lead final approval for large changes)
  • Keep the module's ROADMAP.md and README.md up to date
  • Ensure the module's tests remain green on develop

See MAINTAINERS.md for the current list.

2.4 Project Lead

The Project Lead has final decision authority on:

  • Architecture and API design
  • Release timing and versioning
  • Adding or removing maintainers
  • Changes to governance

The current Project Lead is @makr-code.

3. Decision-Making Process

Ordinary decisions (bug fixes, documentation, minor features)

  1. Open a pull request.
  2. Receive at least 1 approval from a maintainer or the Project Lead.
  3. CI must be green.
  4. Merge.

Significant decisions (new modules, API changes, architecture changes)

  1. Open a GitHub Issue or Discussion describing the proposal.
  2. Allow at least 5 business days for community feedback.
  3. Achieve consensus among active maintainers, or final approval from the Project Lead if consensus is not reached.
  4. Document the decision in docs/research/architecture_decisions/adr_NNN.md.

Breaking changes (require MAJOR version bump)

  1. Follow the significant-decision process above.
  2. Write a migration guide in docs/migration/.
  3. Announce in GitHub Discussions at least 2 weeks before the release.
  4. Follow the process defined in VERSIONING.md §9.

Security-sensitive decisions

Handled privately per SECURITY.md and SOP.md §SOP-05.

4. Contribution Policy

What we accept

  • Bug fixes (all sizes)
  • Documentation improvements
  • New features aligned with the roadmap or previously discussed in an Issue
  • Performance improvements with benchmark evidence
  • New client SDKs or plugins (reviewed for security and quality)

What we do not accept (without prior discussion)

  • Large architectural refactors without an approved ADR
  • New mandatory third-party dependencies without a security review
  • Changes that break backward compatibility without a MAJOR version plan
  • Features that conflict with the edition model (see RELEASE_STRATEGY.md)

Licensing

All contributions must be compatible with the MIT License. By submitting a pull request, you agree that your contribution is licensed under the MIT License.

5. Code Review Standards

Requirement Rule
CI All CI checks must pass before merging
Tests New functionality must include tests; coverage must not drop
Documentation Public API changes must update the relevant documentation
Style Code must pass the project's clang-format / clang-tidy checks
Security Changes touching security-sensitive paths require review by the security-responsible maintainer
Review SLA PRs should be reviewed within 5 business days; stale PRs may be closed after 30 days of inactivity

6. Conflict Resolution

  1. Between contributors: Discuss respectfully in the PR or issue. Reference the Code of Conduct.
  2. Between contributor and maintainer: Escalate to the Project Lead via a GitHub Discussion.
  3. Final authority: The Project Lead's decision is final.

All participants must comply with the Code of Conduct.

7. Changes to Governance

This document can be changed by:

  1. Opening a pull request targeting develop.
  2. Allowing at least 7 days for community comment.
  3. Final approval by the Project Lead.

Every change must be recorded in the document's version header and noted in CHANGELOG.md.

Related Documents