(This blog post is jointly written by Angela Byron, Randy Fay, Greg Dunlap, David Strauss and Dries Buytaert.)

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.

What problems are we trying to solve?

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:

  • No obvious answer to the question, "Who can make a decision here?" and as a result, important decisions can get stale-mated, or in the worst case leave smouldering craters where a healthy, functioning community used to be.
  • Because the Code of Conduct punts on the topic of conflict resolution, a handful of already swamped individuals get tapped on an ad-hoc basis to intervene in conflict situations. This both burns out those individuals, and also leaves the vast majority of the community who don't know who those individuals are with no conflict resolution path apart from "repeat what I already said, but with more volume".
  • While our "do-ocracy" model generally works well for our community, it can also lead to situations like "Tyranny of the person with the most time on their hands." We need ways for smart people who can't be on IRC 18 hours a day or read 300+ reply issues to participate and be respected as equals.

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.

Steve Edwards also recorded a podcast about the Governance Sprint; it provides more background on what problems we are trying to solve.

Overview of proposed changes

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:

  • Establish clearly chartered working groups where currently loosely defined individuals are taking on things that are community-shaping in their scope.
  • Empower these working groups to make decisions, so important community governance decisions do not get stalemated. Keep the groups small enough that decision-making can take place efficiently, but large enough that a diversity of opinions are represented.
  • Make it more transparent and obvious, to newcomers and community insiders alike, where "the buck stops" with decision-making in our community in various areas, what the structure of the community is, what's expected of them, and who to turn to for help.

"Drupal" groups

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.

Governance sprint community

Community Working Group

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:

  • Maintaining and updating community-governing policies like the Drupal Code of Conduct.
  • Helping with mentorship and on-boarding of new community members.
  • Ensuring existing community members have their needs met.
  • Intervening as mediators in cases of conflict resolution (where the conflict cannot be worked out among individuals first) or burnout.
  • Issuing sanctions in cases of extreme policy violations.

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.

Technical Working Group

A corollary to the Community Working Group, this group would set and maintain policies around the technical aspects of our community, including:

  • Develop and maintain policies around things such as:
  • Establishing best practices and recommendations around bug/issue workflows; for example, strongly encouraging a workflow of idea -> architecture review -> implementation -> code style/clean-up.
  • Recommending to the Drupal Association tool changes that will help accelerate contribution.
  • Intervening as mediators in cases of technical conflict (where the conflict cannot be worked out among individuals first).

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.

Drupal Core

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.

Drupal Core Initiative Working Group

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.

Contributions repository

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.

Security and documentation teams

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.

"Operations / Administration" groups

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.

Governance sprint operations

And what about Drupal.org?

Governance sprint drupal org

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:

  • Split off a separate "Drupal.org content" working group from the "Drupal.org webmasters" working group; different skills/levels of trust are needed for managing the content on Drupal.org versus managing access and performing moderation of abuse.
  • Identify a much smaller subset of the Drupal.org webmasters group to form policy for this team. Currently, there are nearly 150 members with "site maintainer" privileges, and they often make and enforce policy on an ad-hoc, individual basis. Community members currently encounter very inconsistent experiences in the queue.
  • While the Drupal Association doesn't manage these groups, it's generally expected that the charters of these groups will include directives to collaborate with the DA in their policy-making decisions in order to ensure the financial sustainability of Drupal.org.

Next steps

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.


Alex UA (not verified):

I'm going to have a hard time not being skeptical/cynical until I see this in action, but overall I think this is really fantastic move in the right direction (I'm also happy to lend a hand, if I that would help, as I really would like to see this succeed). I have been a frequent critic of the processes that are covered under this proposal (or lack thereof), and for the first time in a long time I can say that I feel optimistic about the direction that Drupal governance is going.

Thank you to all of those who came together to help guide this tough step towards maturity for our community! As I said before, I'm happy to help, if I can. I look forward to learning/discussing more in Munich.

Ryan Cross (not verified):

Great to see so much effort and thought being put into this area.

While reading though, I had a few thoughts:

- I"m not sure it really answers the question "Who can make a decision here?" - it seems like ultimately everything points back to you Dries or to the DA Board (which is still an amorphous entity to most people).

- I'm a little concerned that the "Technical Working Group" starts to sound like a place where technical decisions are made and formalises putting this in the hands of a few people. If the scope of this group could be more contained to the technical infrastructure of *.d.o that would be helpful I think. Though, then it questions the difference between this group and the "Drupal.org Webmasters group"

- Any thought to limiting the number of roles/memberships that any one person can hold at the same time? It seems like much of what is proposed here is formalizing what is already existing, but seeing it all laid out it highlights the volume of roles/responsibilities/duties and just plain workload that is required on an ongoing basis. Having this all concentrated on a small number of people not only leads to burn out, but also illustrates the risk that a few people's contributions/perspectives can have an unhealthy bias (even unintentionally) on the whole project.

I think it might be beneficial to limit the number of leadership and membership roles that any one person can hold and/or provide a bit of check and balance to the approach. This would hopefully reduce burn out and also open more for more people to get involved in these areas.

- Also, just figured I would point out that the https://www.drupal.org/projects/drupal.org%20projects section of the site is currently very buried from my point of view, which obfuscates the availability of some of these ad-hoc groups that are already existing. Adjusting that could be an easy/quick win until more mature governance changes go into affect.

jhodgdon (not verified):

Great work -- I think this is a really good roadmap, and I would like to thank the 5 of you (and any others who participated) for thinking through things so carefully, and coming up with a structure that (in my opinion) makes a lot of sense.

I do share the concern expressed by Ryan Cross above about the possibility of undue influence from individuals who want to join and/or run multiple working groups. I think his suggestion about possibly limiting any individual's leadership in these working groups is probably a good idea.

I also think it might be important to make it clear that there's a difference between someone who is on the leadership committee of a particular working group, and someone who is working in that area. For instance, in the Documentation area, there are hundreds of people making on-line documentation edits and core/contrib documentation patches, and not all of them will be making policy decisions. But at the same time, saying to someone that they're not a "member of the Documentation working group" could be an insult... I'm just saying we need to think about the terminology. Maybe there are "Working Groups" which have "Leadership Committees" (including one person designated as the "Leader"), and a completely open membership (maybe these people could be called "contributors" or "members")?

Finally, I think the leadership of the working committees (both the main leader and the committee) needs to be thought about carefully. The choice of who is in the leadership committees can't be entirely self-appointed, and it needs to to have the appearance of not being self-appointed at all. Even better if there is a community process for appointing the committees, or at least some room for (private) community input. I say this because during my time serving as the Documentation Team Leader, several times I ran into people who didn't recognize my authority to make decisions, or who thought I had just given myself the title of Team Leader (which wasn't really the case), and this was always uncomfortable.

Anyway... I think the structure is excellent, and I'm looking forward to seeing it in action!


Donna Benjamin (not verified):

It seems as though many important decisions get made at sprints, camps and cons in the US, and in US friendly time zones - which effectively shuts out people in the rest of the world from participating in the higher level direction of the project.

This is something I'd like a new governance structure to address.

Jeremy Stoller (not verified):

Glad to see these issues are being thought about. I'll also echo Ryan Cross' concern about individuals with undue influence, but I'd extend that to include companies with undue influence. I expect that might be the harder problem to solve. It's not just blatant corruption, but the appearance of impropriety that must be avoided. If one or two commercial enterprises appear to have an overabundance of access and influence, compared to the competition, then it will have a corroding effect on the community. Aquia is of course the obvious concern here, though I think not the only one. I already hear grumblings when I go to Drupal meetups and events, but those grumbles will get louder as policies are codified and dollar figures grow, unless the concerns are addressed.

And not to be a downer, but is thought being given to a secession plan for you, Dries? All the lines in those diagrams still point to you. So what happens if you are somehow incapacitated, abducted by aliens, or simply decide to leave? Will a new project lead be installed in your stead? Installed by who? I think the Drupal community, and the business community, would both breathe easier if policies concerning this eventuality were publicized.

How does the operation of GDO fit into this, including the setting and implementation of policies? Would the Community Working Group handle this, or would it be left to the webmasters?

In a similar vain, how do local user groups fit into this plan? Will they remain a wild-west style do-ocracy, or will there be some process by which local groups can be officially chartered?