Maintainers

Bevy is community-maintained. Day-to-day work happens through the Subject-Matter Experts (SMEs) model: each major area has one or more SMEs who provide technical guidance and review authority for that area. A small team of Maintainers has merge authority on every area and is responsible for releases and direction.

The canonical, up-to-date list lives at bevy.org/community/people/. The notes below describe the structure rather than naming names — the people behind those titles change over time.

The structure

graph TB
    Found[Bevy Foundation<br/>non-profit, holds trademark, accepts donations]
    Steering[Project Lead]
    Maint[Maintainers<br/>merge authority, release responsibility]
    SME[Subject-Matter Experts<br/>per-area technical guidance + review]
    Contrib[Contributors<br/>PRs, issues, code]
    Found --> Steering
    Steering --> Maint
    Maint --> SME
    SME --> Contrib
    Contrib -. PRs .-> SME
    Contrib -. issues .-> Maint

SME areas

The D- prefix labels on GitHub track the areas. Each area has one or more SMEs:

• Rendering — bevy_render, bevy_pbr, bevy_core_pipeline, render pipelines.
• ECS — bevy_ecs, schedule, change detection, performance.
• Reflection — bevy_reflect, type registry, scene serialization.
• Animation — bevy_animation, glTF curves, blend graphs.
• UI — bevy_ui, layout, widgets, theming.
• Assets — bevy_asset, format loaders, processing.
• Audio — bevy_audio.
• Build / Tooling — CI, docs site, release pipeline.

Find the current SMEs at bevy.org/community/people/ and on the governance page in the Bevy organization.

How merging works

A PR needs:

1. At least one SME approval in the relevant area.
2. At least one Maintainer approval.
3. Green CI.
4. No outstanding S-Needs-Review blockers.

Maintainers do the actual merge after both approvals are in. Trivial PRs (typo fixes, documentation tweaks) can be merged with a single maintainer approval.

Releases

A new minor version ships roughly every 3-4 months. The release process:

1. A maintainer cuts a release branch from main and tags 0.X.0-rc.1.
2. The community tests the release candidate on real games.
3. Issues found in the RC are fixed on main and cherry-picked to the release branch.
4. After the freeze, a maintainer tags the final 0.X.0 and publishes the release notes.
5. Patch releases (0.X.Y) ship as needed for critical fixes.

The release-notes process is itself collaborative: each notable PR adds a release-notes directory entry that gets compiled into the changelog by tools/build-release-notes.

Decision-making

Bevy uses lazy consensus: a proposal is approved if no one objects within a reasonable window. Larger changes get RFCs in the bevyengine/rfcs repo. Architectural disagreements escalate to the Project Lead, but in practice almost everything is resolved by discussion in the PR.

Funding

The Bevy Foundation accepts donations and uses them to fund maintainer time. Some maintainers are part-time funded; most contribute as volunteers.

Becoming a maintainer

There's no application form. The path is: contribute consistently, become a recognized SME in an area, then get nominated by existing maintainers when capacity is needed.

See also

• Lore for the cultural backstory.
• How to contribute for how PRs flow through review.
• The official people page for the current roster.