Maintainers

/.gitlab/CODEOWNERS is the source of truth for review and approval. The list is huge — what follows are the broad strokes.

Compliance gate

The [Maintainers] section requires at least one approval from a maintainer group on every MR. The * line catches everything that doesn't match a more specific rule:

• @gitlab-org/maintainers/frontend
• @gitlab-org/maintainers/database
• @gl-dx/maintainers, @gl-dx/tooling-maintainers (developer experience)
• @gitlab-org/delivery
• @gitlab-org/maintainers/cicd-templates
• @gitlab-org/tw-leadership (technical writing)
• @gitlab-org/maintainers/kas-version-maintainers

Top-level ownership

Path	Group
/scripts/, /.gitlab/	All maintainer groups
/workhorse/	@gitlab-org/maintainers/gitlab-workhorse
*.rb, *.rake, *.builder, *.erb, Gemfile*, Rakefile, /app/, /bin/, /config/, /ee/, /gems/, /lib/, /qa/, /spec/, /sidekiq_cluster/, /vendor/, ...	@gitlab-org/maintainers/rails-backend
/spec/, /qa/	+ @gl-dx/maintainers
/locale/	+ @gitlab-org/maintainers/frontend
*.haml, /app/views/**/*.erb, /ee/app/views/**/*.erb, /public/	Backend + Frontend maintainers
*.scss, *.js, *.mjs, *.vue, *.graphql, package.json, yarn.lock, /storybook/, /spec/frontend/, /app/assets/, /ee/app/assets/, /ee/frontend_islands/	@gitlab-org/maintainers/frontend

Section-specific ownership

CODEOWNERS uses sections — named groups of rules — to scope ownership by feature. Feature teams own their slices; cross-cutting concerns (DB, performance, security) attach as additional reviewers via Danger.

Notable sections (incomplete):

• Database — for schema changes, queries on hot tables.
• Backend — Rails domain code.
• Frontend — Vue components, GraphQL operations, SCSS.
• DX — tooling under tooling/, scripts/, the GDK.
• Delivery — release machinery and .gitlab-ci.yml.
• Workhorse — the Go service.
• Gitaly — the cross-repo Gitaly version pin.
• KAS / Pages / Container Registry — version pins for external services.
• CI/CD templates — lib/gitlab/ci/templates/.
• Technical Writing — docs.

Per-feature ownership via Danger

danger/ contains many rules that compute additional reviewers based on changed files. For example:

• A change touching app/models/issue.rb pings the ~"work items" group.
• A change adding a new feature flag pings the rollout reviewer rotations.
• A change to db/migrate/ requires a database review.

These rules are how reviewer rotation actually happens day-to-day.

Reviewer roulette

Reviewer Roulette (in Danger) picks a random reviewer + maintainer for the changes. The pools come from the team page and feature-category metadata.

Where to find owners for a path

1. cat /.gitlab/CODEOWNERS | grep <path> — the file is alphabetized within sections.
2. The MR's "Reviewers" panel — Danger fills in suggested reviewers automatically.
3. The team handbook — public listing of who is in each maintainer group.