As mentioned last month, on July 16 - 17, 2012, several community leaders in the Drupal project sat down with several community leaders from other open source projects and tried to hash out a governance structure to support the Drupal community's continued growth. "Governance" in this case, encompassing all the things we do to organize ourselves, make plans and decisions together, get things done, and resolve conflicts.
Here are the proposals we came up with, and we are actively seeking community feedback on the ideas within.
We began the sprint by brainstorming a list of problems we're hitting, given the scale of our community. This list included items such as:
Over the course of two days, Drupal community members Dries Buytaert, Angela Byron, Randy Fay, Greg Dunlap, and David Strauss met and discussed a variety of these and other governance topics, and we also received input from Jono Bacon, community manager for the Ubuntu project, Jared Smith, former project lead of the Fedora project, and David Eaves.
We propose the creation of a number of "working groups" that essentially make more explicit community structures that already exist. Each working group would consist of ~5 people, appointed by Dries, in charge of collaborating with the community in order to establish effective policy. Each working group will have one "lead" member (chair) who communicates major items and works with Dries. Some working groups will have a set duration (e.g. life cycle of a Drupal core release), others may have terms. Dries, as project lead, also reserves the ability to terminate a group at any time if it feels like they are overstepping their scope (charter).
The summary, in essence:
The "Drupal" groups encompass areas that touch Drupal core or contrib, or the Drupal community itself. The ultimate "buck stops here" with these groups is with Dries Buytaert, the Drupal project lead.
Inspired by the Fedora Community Working Group, this group would be responsible for maintaining a friendly and welcoming community, and their charter will likely consist of items such as:
In other words, this working group tries to make sure the "people" side of our community is functioning well. It doesn't set technical policy or intervene in any code-related matters; this is the role of the Technical Working Group. The ideal make-up of this group would be community-minded people with extreme amounts of patience, empathy, and diplomacy skills.
A corollary to the Community Working Group, this group would set and maintain policies around the technical aspects of our community, including:
In other words, this working group tries to make sure the "technical" side of our community is working well. "People" problems would be escalated to the Community Working Group. Nevertheless, the ideal make-up of this group would be community-minded people who are also technical, known to be fair, and adverse to making new rules.
A lot of time was devoted at the sprint to discussing Drupal Core, and how to address some of the challenges surrounding its development. For example, there is currently a lot of tapping of internal networks to move things along in core, and those without access to those networks can feel blocked out. It's also very difficult to get an answer as to whether or not something is "core-worthy" until far too late in its development process, making major feature development a risky affair.
The recommendation from the Governance Sprint is something like the following, which would not take effect until the Drupal 9 development cycle.
This group works with Dries Buytaert, the Drupal project lead, in order to tackle strategically vital initiatives within Drupal core. Membership includes the initiative leads. This would entail a bit more formalized structure, including milestones and progress tracking, bi-weekly meetings among the various initiatives, and so on.
This would be essentially formalizing what already exists today with the Drupal 8 initiatives and initiative leads.
At the Governance Sprint, we agreed to continue not to impose any additional governance structure on contrib, by design. This allows contrib to be an incubator not only for technical solutions, but also for governance itself.
The exception would be conflicts between maintainers or maintainers and their users which are not able to be resolved among the individuals. These would then go to either the Community Working Group or Technical Working Group, as appropriate.
We have a few overall "Teams" that touch elements of the product, including the Documentation Team and Security Team (we also discussed the establishment of a Support Team). As part of the new governance model, we recommend creating charters for these teams that make it explicit to others what their roles and responsibilities are, how to join, and what is expected of them. It's likely these charters will be modeled after something like the Documentation Team and Leader Responsibilities page.
These groups act in support of the Drupal project and its community. The ultimate "buck stops here" with these groups is with the Drupal Association board instead of Dries. Many of these have a financial impact on the Drupal Association and greatly affect its ability to get things done in support of its mission.
Next to Drupal core, this is probably where we spent the most time discussing. Drupal.org is special, in that it straddles both the community side of things, as well as the operations / support side of things. It functions through a combination of numerous volunteers as well as funding via the Drupal Association for support staff and development on major initiatives.
At the moment, the best place to put Drupal.org seems like it's at a halfway point between the "Drupal" and "Operations" sides of things, and for the charter of this working group to include the necessity to work with the Drupal Association and community members alike. Though eventually, for both legal and simplicity reasons, it would be better for this to be located under the purview of the Drupal Association board.
A few areas there was broad agreement on, however, were the following:
We're very interested in community feedback on this direction, either in comments below or privately. We'll provide an update on the progress at DrupalCon Munich.
We encourage everyone to come and get involved in this discussion. As our community grows, it is essential that we come up with a governance structure that matches our core values and allows us our community to be more sustainable for the long haul.
Updates from Dries straight to your mailbox