Differences between full and provisional core committers

Last updated on

20 November 2022

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	"Maintain issues" permission Possibly "Write to VCS" permission (see below about commit access) Normal members of 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.
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
May grant discretionary exceptions to core policies Inform other committers of the exception Consult another committer if the exception is significant Propose policy updates if necessary	Should not grant exceptions to documented policies without signoff from a full committer
Revert any commit at their discretion	Revert: In case of emergency (e.g. broken HEAD) Their own commits Otherwise, consult with a full committer before doing a revert.