This document provides an overview of Drupal core's organizational structure, outlines what roles/responsibilities exist, and defines how decisions are made. The goal is to help the broader community understand the process, to ensure that both old and new maintainers understand their responsibilities, and to eliminate uncertainty about who has the ability to make decisions in various parts of the project.
This is a living document; if you see something out of date or missing, please file an issue in the "Drupal core" issue queue with the "Project governance" issue tag.
Anyone at all with a Drupal.org account can be a core contributor, simply by participating in the Drupal core issue queue. A core contributor is someone who:
In short, core contributors are empowered to drive changes within Drupal's code base, and to work with other core contributors to help get changes they care about in, using a variety of both technical and non-technical skills.
Most proposed changes follow a standard peer review process, with sign-off from one or more maintainers (who are themselves a subset of core contributors).
(Thanks to Docker for the inspiration.)
There are different types of maintainers, with different responsibilities, but all maintainers have three things in common:
Maintainers are essential, but the results of their work are not always immediate or obvious. It's easy to appreciate a really cool and technically advanced feature. It's harder to appreciate the absence of bugs, the slow but steady improvement in stability, or the reliability of a release process. But those things distinguish a good project from a great one.
Potential maintainers generally demonstrate expertise, consistency, and passion contributing in their area before they become maintainers.
Maintainers with commit access need additional skills. They are reliable, decisive when needed, open to feedback, and able to give others feedback constructively. They also need significant prior experience participating broadly in core issues (usually at least a year).
It's generally desired to have at least two people in any given maintainership role, in order to prevent burnout and to help ensure there are ample people available for unblocking a given decision; however, this is not a hard requirement. Maintainers are expected to give clear, objective reasons and actionable feedback in the event they push back on a given change.
The list below defines the different maintainer roles. (Detailed responsibilities for each role are outlined later.)
Anyone with a Drupal.org account can create or update a Drupal core issue to propose a change. Issues should be processed according to the following flow:
See the Frequently Asked Questions for explanations of what it means to sign off on a change and examples of what constitutes a "significant" change.
Also see the Responsibility Assignment Matrix version.
BDFL stands for "Benevolent Dictator for Life." All decisions are made, by default, by the BDFL. However, since the BDFL making every decision would be highly un-scalable, in practice decisions are spread across multiple maintainers. The BDFL appoints and replaces those maintainers, and spends time thinking about how to make the team function well. The BDFL also holds final say in any disagreements, and can be escalated to when decisions cannot be reached through the normal process. Finally, the BDFL also preserves the philosophy, culture, and principles of the project.
Core committers are the people in the project with commit access to Drupal core. Within the core committer team, the BDFL assigns people certain areas of focus (defined below) to help with decision-making. Nevertheless, core committers are a group of peers, and are expected to work closely together to achieve alignment, to consult each other freely when making difficult decisions, and to bring in the BDFL as needed.
In addition, note that the Documentation Topic Maintainer also has commit access for documentation patches only, across all major versions.
While core committers tend to stay focused on their particular versions, where needed they can step in to fill needs in other versions (for example, the Drupal 7 Release Manager rolling a security release for Drupal 6 at the same time). It's also possible that a non-technical Product Manager or Release Manager could be appointed at some point, who would only very rarely use their commit access. The distribution of committing work is something to be worked out among the core committer team.
Product managers are expected to talk extensively with different types of Drupal’s users, gather data about how Drupal is used in the “real world,” and present this information back to Drupal's various audiences.
The product managers are responsible for:
Significant changes to user-visible features, the user interface, and install profiles must be approved by the product managers.
The framework managers are responsible for the overall integrity of the technical architecture across all subsystems, the consistency of APIs, and the overall developer experience of Drupal.
Significant developer features, changes to public APIs, external libraries, and overall architecture must be approved by the framework managers.
The release schedule is set by the BDFL in consultation with the other core committers, and the release managers make sure that we manage towards it. This includes rolling the releases, tracking the release schedule, facilitating communication between all participants, measuring progress, and defining the processes that help contributors collaborate effectively and efficiently. Release managers also make the final call on issue "metadata", such as status and priority, unless overruled by the BDFL.
Some aspects of the project are system-wide and correspond to one of the core gates that all proposed changes must pass. Topic maintainers ensure that patches improve rather than cause regressions for these topics and help educate other contributors on how to do the same in their patches.
(*) While generally topic maintainers do not have core commit access, the Documentation Topic Maintainer is an exception and has commit access for documentation patches only, since they cannot functionally break the system. (Note that class annotations are not considered documentation.)
Subsystem maintainers oversee the development of parts of Drupal known as "subsystems". They can make a shorter-term commitment to maintaining a subsystem, or a longer-term commitment that spans several major Drupal versions.
The maintainers of each subsystem are responsible for:
Anyone can be a provisional maintainer to a subsystem by simply contributing to it. Most subsystem maintainers start out contributing to their component by triaging issues, supplying patches, and reviewing others' patches.
Subsystem maintainers also ensure that the issues in their queues are properly triaged, either through their own work or by organizing other contributors:
Initiatives are larger projects for the current development release that are intended to re-architect or otherwise improve large areas of the Drupal core code-base. The BDFL determines these initiatives. Each initiative has initiative coordinators who act as project and community managers with a strategic agenda, and help guide a team of people interested in helping the initiative to succeed. Initiative coordinators don't have direct decision making powers; rather, they work to build buy-in among those who do have decision-making powers (product managers, subsystem maintainers, topic coordinators, etc.).
Here are some examples:
Drupal core has existing objective criteria for what changes can be accepted, including:
Maintainers both evaluate changes in terms of these criteria and provide specific guidance for their area based on their domain-specific expertise and overall plan. (Also see the overall Drupal mission, values, and principles.)
Any contributor can suggest that a change needs a particular sign-off and add the appropriate "Needs $role review" tag. (Refer to the Responsibility Assignment Matrix for guidelines.)
Core committers are ultimately responsible for assessing which sign-offs are needed or missing for a given change in the RTBC queue. If one or more sign-offs are missing, the committer will add the appropriate "Needs $role review" tag(s) and set the issue back to "Needs review" or "Needs work". (Also see How are patches committed?)
In general, when an issue is tagged as needing a particular signoff, it is the responsibility of the maintainers for that role to provide feedback within one week. If the review is not done within that timeframe, the issue should be escalated to the next step. For time-sensitive issues (such as critical regressions or issues that are blocking other work), this timeframe may be shortened or a committer may recommend a follow-up discussion instead.
Maintainers can and should take time off, whether for vacations or just because they feel the need to. However, when doing so, maintainers should let their co-maintainers and/or the core committers know about their impending absence and what they'd ideally like done with any issues that need their feedback in the meantime, such as delegating these decisions to another individual.
Also see I disagree with a patch that was committed, and it introduced problems with an area of core I am responsible for. What should I do? and How are patches committed?.
(There is no "Needs BDFL review" tag; issues should be tagged with "Project governance" if appropriate or otherwise simply be assigned to the BDFL by a maintainer.)
The roles of BDFL, product manager, framework manager, and release manager have commit access and are collectively referred to as "core committers" (or "branch maintainers" for a specific major Drupal version). With the exception of Documentation, topic maintainers and subsystem maintainers do not have commit access.
Core committers work together to provide timely feedback on all issues that are marked "Reviewed & tested by the community" (RTBC), either reviewing and committing patches or setting an issue back to "Needs work" (NW) or "Needs review" (NR) for additional work or (in the case of significant changes) for missing signoffs.
For the current development branch of Drupal, committers work together to provide feedback on issues in the RTBC queue as soon as their availability permits. For stable branches, committers may leave issues at RTBC for a longer period to ensure they are adequately reviewed by others.
Committers will sometimes assign an issue to a different committer who has more expertise for that issue or whose signoff is needed.
A "provisional" maintainer is a maintainer who does not yet have full authority for their role, but is working alongside the primary maintainers with the aim to become a full-fledged maintainer in the future.
No. Maintainers can rely on others from the team to support them in areas where they have less expertise. For this reason, it is valuable to have a range of technical skills on the team, but there are no specific requirements like "at least one of the product managers must have a design/UX background" or "one of the architects must be a performance or front-end engineer".
No. In general, maintainers consult others for any significant decision; see How are decisions made? above. Since decisions are made through a system of signoffs and consensus rather than by vote, this mitigates the effect of any one group having a larger majority. If there are concerns about a maintainer making biased decisions on behalf of a particular employer or audience, these can be escalated "up the chain" to the next level, up to the BDFL, or in a worst case scenario up to the Community Working Group. (If there are simply objective concerns about a specific decision, a followup issue should be filed instead.)
A product manager sets forth the "vision" for what Drupal will look like, and decides on its feature set. A Usability maintainer helps maintain that vision by enforcing usability guidelines and providing usability feedback in their patch reviews. It's expected that the product managers and usability maintainers will work closely with one another, by drawing on each others' expertise.
In either case, file an issue in the "Drupal core" issue queue with the "Project governance" issue tag. If stepping up, it's helpful to list a few issues you've helped with recently to demonstrate your track record. If stepping down, it's helpful to recommend another person to take your place (when possible).
Cross-post a followup issue explaining your concern and reach out to the core committer. For urgent or critical regressions, reopen the original issue and request a revert.
While it's possible that this process may introduce slightly more overhead, the intent is to simply formalize what is informally done anyway, and help make the decision-making process explicit so both contributors and maintainers know what to expect and who to talk to if they're stuck. Also, formally spreading sign-off responsibilities to the various parties will hopefully result in fewer RTBC patches being rejected by core committers and a faster and more efficient process for everyone overall.
The following Responsibility Assignment Matrix illustrates the Drupal core decision-making process.
While the most common format for such matrices is RACI (Responsible, Accountable, Consulted, and Informed), this table uses a variation called PACSI (Perform, Accountable, Control, Suggest, Informed), which more closely matches the collaborative nature of our culture.
The role(s) that carry out the activity.
This is placed in the column of the role(s) that predominantly drive those changes, but this doesn't preclude other roles from also carrying out work.
The role(s) ultimately accountable for the correct and thorough completion of the task, and often the ones who delegate the work to the performer (P).
The role(s) that review the result of the activity (other than the Accountable, A). They have a right of veto and their advice is binding.
The role(s) consulted for advice based on their expertise. They provide non-binding advice.
These are role(s) whose input via two-way communication is actively sought, though this does not preclude others from making suggestions.
The role(s) that must be informed of the result of the activity.
Note that if a change includes multiple rows in this table, there will be multiple roles involved.
* The BDFL may proactively make or override these decisions if they deem it necessary.