Core committers
Core committers are the small group of people with commit access to Drupal core. They are the final reviewers who decide when a change is merged.
Core committers are the people who have commit access to Drupal core, the shared code that every Drupal site runs on. Contributors propose changes in the issue queue; a core committer performs the final review and decides when and whether to merge a change. They are a subset of the Drupal core Leadership Team.
How core committers work
A change to core starts as an issue on Drupal.org. Contributors write the change, test it and review each other's work. Once the community marks it reviewed and tested, a committer gives it a final review and commits it to the core repository. Issues marked RTBC (reviewed and tested by the community) wait in a queue for that last step.
The governance document lists the groups that count as committers:
- The Project Lead, who sets the vision and strategy of the project and breaks ties when an impasse blocks progress.
- Product managers, who guide the strategic direction of Drupal as a product and approve significant changes to feature scope and system requirements.
- Framework managers, who look after the technical architecture and approve public API and architectural changes.
- Release managers, who set the release schedule with the other committers and focus on release stability.
- General committers, who have commit access without one of the manager roles.
Subsystem maintainers, topic maintainers, facilitators and initiative coordinators are maintainers too, but they do not have commit access.
How someone becomes a committer
Anyone can nominate themselves publicly, and existing committers often recruit people privately. The Leadership Team must approve a new full or provisional committer. The governance document asks for significant prior experience across core issues, usually at least a year, plus reliability, openness to feedback and the ability to give constructive feedback. Provisional committers start with a trial period and fewer privileges.
Example
A developer fixes a bug in the Views module and attaches the change to an issue. Reviewers test it, and the issue is marked ready to commit. A core committer reads the change once more, commits it, and then reviews the credit suggestion on the issue. Everyone who moved the issue forward is credited, and the fix ships in a later release.
Common mistakes
- Treating committers as the whole core team. Maintainers without commit access and contributors review and test changes too.
- Expecting a committer to build your feature. Committers review and merge; the work itself comes from contributors, so a stalled issue needs someone to update the change or review it.
- Using an old article for the names. The roster changes. The authoritative list lives in
core/MAINTAINERS.txt. - Disputing credit in the issue thread. The committer who merged the change owns the decision. Read the credit guidelines, then contact that committer.
For marketing and content teams
Committers decide what is merged, so whatever reaches a core release has passed through them. You do not need to know their names to plan updates. If your team wants a core change, the way to move it is to back the issue: add a clear use case, test the proposed fix and say what you saw. A committer will see the result when the issue is ready. Your developers can also take the route described under core contributors.