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.
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.
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:
- 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.
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.
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.
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.
And what about 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.
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.
I helped start the Drupal Association in 2006 because we needed a checking account for the $10,000 or so required to produce a Drupal conference and to support our infrastructure. In a short six years, we grew the Drupal Association from a volunteer-run organization to one of the largest Open Source non-profit foundations with an operating budget of $3 million USD and 8 full-time employees. Today, we support over 18,000 developers, 9,000 conference attendees, 2,300 individual donors, 800 organizations, and a web presence that reaches over two million people every month.
A lot of that credit goes to Jacob Redding, who took the position of Executive Director two years ago. Under Jacob's leadership we have broadened our activities, streamlined our operations, and significantly increased our revenues. We have supported the Drupal community in its exponential growth from 70,000 members to over 800,000 and from 700 committers to over 18,000. And we are just getting started.
Today, we are announcing an important leadership transition at the Drupal Association. We're sad to say that Jacob, who has worked tirelessly and effectively to grow the organization to where it is today, has told us he intends to step down later this year. Needless to say, it was a difficult decision for Jacob to leave, but he has agreed to stay on until the right replacement has been found, and plans to stay involved as a member and volunteer after his responsibilities have been transitioned.
This transition doesn't come as a surprise for the Drupal Association's Board of Directors. With Jacob's help, we have been preparing and planning for this transition for a while. The Drupal Association is in a good place; we are better organized than ever before and have more momentum than ever before.
This leaves us with a tremendous opportunity ahead. We are now seeking someone to help lay the foundation for our next stage of growth. Someone to help drive us to become the largest Open Source non-profit organization. This will need to be an experienced executive to take over Jacob's responsibilities and to grow the Drupal Association from a $3M organization to a $10M organization over the next few years so we can better support our massive growth as a community and project.
If you are interested, or if you know someone that is interested in this job, please take a look at the job description. I think this truly represents one of the most exciting opportunities out there for someone with a strong leadership background, and that is interested in fostering enormous growth within a non-profit and collaborating with an extensive and active volunteer network. Together with the Drupal community this person could change the way the world builds websites.
The Drupal Code of Conduct, heavily borrowed from our friends at Ubuntu, does an excellent job enshrining the characteristics we aim to foster, in order to ensure people "Come for the software, stay for the community". However, there are still some gaps. For example, how to deal with conflict resolution, and how an individual best goes about proposing new governance policies.
Key Drupal contributor Randy Fay has done a tremendous amount of research into governance models of other open source projects, which you can read more about on his blog. For those who have not been following Randy's posts, he and I are holding a sprint about Drupal Governance on July 16 and 17 in Portland, Oregon just after the Community Leadership Summit. Randy, Angela Byron, Greg Dunlap, David Strauss, and myself will be in attendance.
This sprint is a first for Drupal. The goal of this sprint is to come up with a proposal for subsequent community discussion with recommendations around some of the following topics:
- Processes to create and maintain policies, as a general concept
- A process for resolving technical conflicts
- A process for resolving community/interpersonal conflicts
- A process and team for resolving "nuclear" issues that need extremely delicate handling.
If you have other topics you'd like to propose, or would like to provide feedback on these items in advance of the sprint, please chime in in the Governance project issue queue. It is important work to streamline and evolve the governance of our project, so thanks in advance for your contributions.
Today, I'd like to share designs we've created for a "responsive layout builder" for Drupal that we hope to include as part of the Spark distribution. I'm very excited about this because it brings mobile and responsive web design to the masses.
We've worked on this "responsive layout builder" concept for many weeks, and I believe the result is groundbreaking. While other layout building approaches hand-wave responsive design and produce messy markup, our approach promises to be simple to use, produce clean and semantic markup. At the same time educating the user on the logic of responsive design. Once implemented I think that this is something that could really push Drupal to the forefront of the competition.
What better than to show you what we have come up with? The following 8-minute video walks through the designs, and also provides a bit of background on the Spark project:
Special credit goes to Kevin O'Leary from Acquia for being the driving force behind this work.
Technically, this is intended to layer on top of the Panels module, for better forwards-compatibility with Drupal 8. We hope to integrate this work with the research and prototyping actively being done for the Drupal 8 Blocks and Layouts initiative.
Acquia is actively seeking implementation partners for this and other important work. If interested, please contact Angela Byron. We'd love to work with others on this.
You may remember that two weeks ago, I shared a video of an in-line editing prototype that we'd like to add to the Spark distribuion in addition to this responsive layout building tool. Its implementation is well underway in the Edit module.
As you can see, things are starting to move along quite nicely. Please join the discussion in the Spark issue queue if any of the above functionality sounds exciting to you and you'd like to help!
In the interest of further increasing the velocity of Drupal 8, I am giving Angela "webchick" Byron commit rights to the Drupal 6.x and Drupal 8.x branch. Angela was already a Drupal 7 core co-maintainer, but with this new appointment she is also a Drupal 6 and Drupal 8 co-maintainer. This appointment is primarily to help with Drupal 8's development, and does not automatically extend itself to Drupal 9.
In her new role, Angie will do what she does best: supporting the other core maintainers and core developers with general core patch reviews and commits in order to ensure better throughput of the patch queue.
The following chart explains the relationship between all of the people with core commit rights in graphical form:
Please join me in welcoming Angela to her new role!
The goal of the Spark distribution is to incubate authoring experience improvements in a Drupal 7 and Drupal 8. It was announced earlier this month, and since then we've been hard at work on initial research and design.
The Spark team's primary focus is on improving Drupal's content authoring and editing experience, and the first feature we're prioritizing is in-place editing: the ability to edit content, menus, etc. directly on the page, without the need to navigate to a separate edit form. Think of it as "true" WYSIWYG.
Members of Acquia's design team spent time analyzing how some of the most widely adopted Open Source as well as proprietary CMSs do in-place editing. We then prototyped some initial ideas, and performed usability testing on those prototypes to see what works and what doesn't. After a number of iterations, we're happy to report that the usability testing has validated Spark's general design direction. People loved the prototype. Now is a good time for us to share our initial prototype and to solicit further feedback from the community so we can shift gears into implementation.
The following 5-minute video walks through the HTML/JS prototype, and also provides a bit of background on the Spark project:
Our goal is to deliver this functionality in a contributed module for Drupal 7 first and foremost, which will live at the In-Place Editing project on drupal.org. This module will be bundled into the Spark distribution. Depending on how it is received, I hope we can also target this functionality for Drupal 8 core.
From a technical architecture standpoint, we are currently in the process of selecting the WYSIWYG editor to use in Spark for in-place editing of HTML content. For now, we plan to focus on supporting only the Filtered/Full HTML text formats in order to get us to something testable faster.
Later, we are hoping to branch out into other areas of authoring experience too, including helping with the content creation form improvements that the Drupal usability team has been spear-heading, as are well as the layouts UI work being actively discussed in the usability group. The Drupal usability team is doing an incredible job with these issues, and once fully staffed, I would like to see the Spark team help implement these improvements for Drupal 8 and backport them to Drupal 7 so we can ship it with the Spark distribution. (Did I mention that the Spark team is hiring? ;-))
As you can see, things are starting to move along quite nicely. Please join the discussion in the Spark issue queue if this functionality sounds exciting to you and you'd like to help!