The Drupal project just turned 14 years old. There are now over 1 million known installations of Drupal, and Drupal.org has over 1 million users. Drupal 8 has over 2,700 contributors (almost three times that of Drupal 7) and over 13,000 commits so far (50% more commits per day on average than Drupal 7). I wanted to take an opportunity to reflect on our current governance structure and try to evolve the Drupal leadership team and decision-making, enable better scaling, and document both the formal and informal processes we have currently in place.
Over in the Drupal core issue queue, I've proposed an evolution to Drupal core's structure and decision-making process which documents how things are currently done, and also proposes some incremental improvements:
- Defines roles and responsibilities that are currently carried out by individuals within the core committer team: product managers, framework managers, and release managers. This is done to provide transparency, to help expedite decision-making, and to ensure that these roles are easier to fill in the future, as we can eliminate the requirement for core committers to be “superhuman” contributors capable of doing anything and everything, at all times.
- This document also adds the concept of “provisional” product, framework, and release managers, without actual commit access, who work alongside the core committers until they gain the necessary experience to play a full committer role.
- In so doing, the document also appoints two additional core committers—Alex Bronstein (effulgentsia) and Jess (xjm)—who have been playing this "provisional" role for some time now, informally.
- Lays out an explicit decision-making framework to make it clear who needs to be involved in what types of changes, and to what degree. This documents the process we already use, but also introduces some changes. The added transparency should make it easier for contributors who are proposing changes to direct their questions to the right people.
- Clearly outlines the role of subsystem maintainer (formerly component maintainer) as an active “maintenance” role: performing or organizing regular maintenance tasks: triaging the subsystem's queue(s), reviewing patches in need of review, etc. These responsibilities also come with a more formal opportunity to sign off on proposed changes that significantly affect the subsystem. The advantages to this are additional transparency, delegating and scaling responsibilities, and reducing the workload that currently falls to core committers. Going forward, subsystem maintainers who are not currently active will no longer be listed in MAINTAINERS.txt.
This document builds on ideas that have been blogged about or presented at Drupal events by many people, including Randy Fay (rfay), Larry Garfield (Crell), Cathy Theys (YesCT), Gábor Hojsty, Greg Dunlap (heyrocker), Jess (xjm), Alex Pott (alexpott), Nat Catchpole (catch), Jennifer Hodgdon (jhodgdon) and others. It has been reviewed by numerous people, including the existing core committer team. Special thanks to Angie Byron who has spent weeks helping me co-author this proposal.