# Governance

This document describes how decisions are made in the agentmemory project.

The model here is a near-copy of the [Linux Foundation Minimum Viable Governance (MVG)](https://github.com/todogroup/ospolog/blob/main/governance/minimum-viable-governance.md) pattern, scoped to the project's current single-maintainer reality with a concrete plan to diversify maintainership over the next two release cycles.

## Mission

Ship a persistent, local-first memory runtime for AI coding agents that:

- Requires zero external databases.
- Runs under any MCP-compatible client.
- Stays compatible with the open [Model Context Protocol](https://modelcontextprotocol.io).
- Keeps every user's data on the user's machine by default.

## Roles

### Users

Anyone who runs agentmemory. No process obligation beyond the license. Feedback via [GitHub issues](https://github.com/rohitg00/agentmemory/issues) and [discussions](https://github.com/rohitg00/agentmemory/discussions) is the input channel.

### Contributors

Anyone who opens an issue, comments on an issue, opens a pull request, or otherwise helps the project. See [CONTRIBUTING.md](./CONTRIBUTING.md) for the how-to.

### Maintainers

A Maintainer has commit access to the repository, responsibility for reviewing PRs, and a vote on project-level decisions. The current list is tracked in [MAINTAINERS.md](./MAINTAINERS.md).

A Maintainer is expected to:

- Respond to PRs they are review-owner for within a reasonable window (goal: 3 working days for first comment).
- Uphold the [CODE_OF_CONDUCT.md](./CODE_OF_CONDUCT.md).
- Avoid merging their own non-trivial PRs without a second reviewer once the maintainer count is greater than one.
- Disclose conflicts of interest (employer, paid relationships to users).

### Maintainer acceptance process

A Contributor becomes a Maintainer by:

1. Sustained, high-signal contributions over the prior 6 months (multiple merged PRs across more than one subsystem, plus review comments on others' PRs).
2. A Maintainer nominates the Contributor in a public PR editing `MAINTAINERS.md`.
3. The PR stays open for 7 calendar days to collect objections.
4. If no standing objection from an existing Maintainer, the PR merges and the new Maintainer is added.

A Maintainer steps down by opening a PR that moves their entry to the `Emeritus` section. This is always accepted.

## Decision-making

### Default: lazy consensus on PRs

Most decisions happen inside pull requests. A PR merges when any Maintainer approves it and no other Maintainer blocks it. Silence is assent after 72 hours of no objection.

### Non-PR decisions

Anything that is not a normal code change — charter changes, governance edits, maintainer additions/removals, project scope, breaking API changes, relicensing — happens in a GitHub Issue labeled `governance` with a proposal in the first comment.

- Minor scope decisions: rough consensus in the issue thread, captured by a Maintainer in a summary comment.
- Formal votes: Maintainers react `+1` / `-1` / `0` to the summary comment. Simple majority of Maintainers with a minimum of two distinct voters carries. If only one Maintainer exists, a 7-day public comment window substitutes for a vote.

### Breaking changes

A breaking change to the REST / MCP surface requires:

1. A tracking issue labeled `breaking` opened at least one minor release cycle ahead of the change.
2. A deprecation path in the codebase (warning log, feature flag, or adapter) for at least one minor release.
3. The change landing in the CHANGELOG under a clearly marked `Breaking` sub-section.

## Release process

Releases follow [Semantic Versioning](https://semver.org). See the [release process](./CONTRIBUTING.md#release-process) in `CONTRIBUTING.md` and the automated `.github/workflows/publish.yml` pipeline for the mechanics.

## Conflicts of interest

Maintainers employed by a company that sells a product competing with agentmemory, or by a company whose business depends on agentmemory's roadmap, should disclose that relationship in `MAINTAINERS.md` next to their name. Nothing prohibits such maintainership; transparency is the requirement.

## Amending this document

This document changes by PR. Edits follow the Non-PR decisions path above: open a `governance` issue, collect feedback, then open the PR citing the issue.

## Related documents

- [LICENSE](./LICENSE) — Apache-2.0
- [CONTRIBUTING.md](./CONTRIBUTING.md) — how to contribute
- [CODE_OF_CONDUCT.md](./CODE_OF_CONDUCT.md) — community behavior
- [SECURITY.md](./SECURITY.md) — how to report a vulnerability
- [MAINTAINERS.md](./MAINTAINERS.md) — who has commit access
- [ROADMAP.md](./ROADMAP.md) — where the project is heading