Maintainers

Ownership in this repository is encoded in OWNERS.yml files placed in the root and inside many subdirectories. They map glob patterns to GitHub teams under the 10gen/ organization (the private MongoDB org backing this open-source repo). The repository does not use a top-level CODEOWNERS file; the OWNERS.yml files plus the Evergreen configuration drive review assignment.

How ownership is structured

Each OWNERS.yml looks like:

version: 1.0.0
filters:
  - '*':
      approvers:
        - 10gen/mongo-default-approvers
  - '<glob>':
      approvers:
        - 10gen/<team>

When a PR touches files under that directory, the most-specific glob's team is auto-assigned. The team membership lives in the GitHub org and is not visible from the public repo.

Top-level ownership

The root OWNERS.yml carries:

Pattern	Team
* (default)	10gen/mongo-default-approvers
OWNERS.yml	10gen/server-root-ownership
BUILD.bazel, .bazelrc*, .bazelversion, MODULE.bazel*, WORKSPACE.bazel	10gen/devprod-build
.clang-format, .clang-tidy.in, AGENTS.md, CLAUDE.md	10gen/server-programmability
eslint.config.mjs, pyproject.toml, poetry.lock, package.json, .prettierrc, .mypy.ini	10gen/devprod-test-infrastructure
README.third_party.md, sbom.*	10gen/code-review-team-ssdlc
.bazelrc.fuzztest	10gen/platsec-server
.bazelrc.target_mongo_version	10gen/server-release

Subsystem ownership (illustrative)

Each subsystem directory has its own OWNERS.yml. The full list is best discovered by:

find . -name OWNERS.yml | head -50

A representative slice:

Subsystem	Where	Owning team(s)
Database server core	src/mongo/db/OWNERS.yml	10gen/server-storage-execution, plus per-subdirectory teams.
Replication	src/mongo/db/repl/OWNERS.yml	10gen/server-repl.
Sharding (data side)	src/mongo/db/s/OWNERS.yml	10gen/server-sharding.
Sharding router	src/mongo/s/OWNERS.yml	10gen/server-sharding.
Query engine	src/mongo/db/query/OWNERS.yml	10gen/server-query, 10gen/server-query-execution.
Aggregation pipeline	src/mongo/db/pipeline/OWNERS.yml	10gen/server-query-pipeline.
Storage	src/mongo/db/storage/OWNERS.yml	10gen/server-storage-engines.
Index builds	src/mongo/db/index_builds/OWNERS.yml	10gen/server-storage-execution.
Auth	src/mongo/db/auth/OWNERS.yml	10gen/platsec-server.
Transport	src/mongo/transport/OWNERS.yml	10gen/server-networking.
Build / CI	bazel/, evergreen/, buildscripts/	10gen/devprod-build, 10gen/devprod-test-infrastructure.
Documentation	docs/OWNERS.yml	The team that owns each individual document.

The exact mapping for any directory is in its own OWNERS.yml — these are the most current. Team responsibilities shift over time; the file in the repo is authoritative.

Bot accounts

The repo's commit history contains bot-attributed commits via Co-authored-by trailers (factory-droid[bot], dependabot[bot], github-actions[bot]). Bots are excluded from per-page contributor bylines and from this maintainers map — they are not people you'd ask questions of.

How review is requested

When a PR is opened, GitHub auto-assigns reviewers based on the matching teams. The Evergreen patch_aliases may also schedule additional CI tasks based on which paths changed. For internal MongoDB engineers, JIRA's SERVER project is the canonical place to file a ticket against a subsystem; the JIRA components map roughly to the team prefixes in this table.

External contributors

Outside contributors do not have access to internal team handles, but the auto-assignment still works on PRs because the GitHub teams have repo-level review permission. The MongoDB GitHub wiki linked from CONTRIBUTING.rst describes how external contributions are routed.