Differences between full and provisional core committers
Last updated on
13 April 2026
The Drupal core governance policy outlines the role of a provisional maintainer. This document outlines specifics particular to the provisional committer role.
| Full committer | Provisional committer |
|---|---|
| Act as proxies for the BDFL when the BDFL has signed off on a decision | Do not act as proxies for the BDFL |
| Full permissions on the core project node and the g.d.o/core group |
|
| Commit access (can sign off on any non-significant core change by committing the patch) | Commit access depends on specific role |
| Commit to both the development and stable minor branches according to the Allowed changes policy. | Commit non-significant changes to the development branch (depending on role). Confirm backports to the stable branch with a full committer. Read the general advice for provisional committers for more details. |
| Approve or refuse "Needs product/framework/release manager review" issues for their role in the decision-making process | Consult with a full maintainer for the role before giving a signoff and document the joint signoff on the issue |
| Commit the addition of subsystem maintainers according to the governance policy (along with the permissions to get other maintainers set up with the correct access) |
Should not commit additions to MAINTAINERS.txt. An exception is made for a provisional committer to add themselves once the issue has all the required sign-offs. |
May grant discretionary exceptions to core policies
|
Should not grant exceptions to documented policies without signoff from a full committer |
| Revert any commit at their discretion | Revert:
Otherwise, consult with a full committer before doing a revert. |
Help improve this page
Page status: No known problems
You can:
You can:
- Log in, click Edit, and edit this page
- Log in, click Discuss, update the Page status value, and suggest an improvement
- Log in and create a Documentation issue with your suggestion
