You are here
Today Morten Birch Heide-Jørgensen stepped down from his role on the Drupal Association's Board of Directors. The Drupal Association's Board of Directors supports Morten’s decision. The Drupal Association and the Drupal community value inclusivity and diversity, and our leadership must demonstrate those values as well.
We want to thank Morten for his service; he came to the board with a mission to foster improved transparency and communication. He helped both the board and staff embrace those principles in a way that will carry into the future.
Today’s development underscores the need for a broader discussion that we need to have about inclusivity and diversity. Creating and maintaining the right culture and environment is vital to Drupal's success. Therefore, we have asked the Community Working Group to define a process to help our community address these issues and identify positive, proactive, and concrete steps we can take to ensure that everyone feels welcome in Drupal.
Morten is vacating a community elected seat. The Board of Directors will discuss how and when to fill this vacancy at the next board meeting.
Last summer, a number of Drupal community members as well as key figures from other major open source projects met in Portland for the first-ever Drupal governance sprint. The proposal from that sprint recommended the creation of a number of chartered "working groups" to better formalize the existing governance of various aspects of the Drupal project, now that our community is at its current scale. We have now chartered the first of these working groups: the Community Working Group. Thanks very much to everyone who participated in the vigorous community discussion and drafting efforts around this.
However, while the governance proposal coming out of Portland provided some fairly solid direction on the governance of the Drupal project itself, it left some pretty big questions unanswered as it related to the governance of Drupal.org. Drupal.org isn't just some ordinary website. While it was originally a small portal with a few hundred members hosted on a friend's shared server, it is now serving millions of page views to over 2 million unique visitors per month, as well as terabytes of data, and is home to almost a million active members, among them thousands of contributors committing code, reviewing patches, improving documentation, etc. at all hours of the day. The old "do-ocracy" model of getting things done on Drupal.org isn't scaling for our community anymore, and lack of clarity around decision-making has cost us repeatedly, in the form of slow progress on the Drupal.org Drupal 7 upgrade, Drupal Association funding challenges and staff inefficiency, and various community volunteer frustrations.
I've therefore spent time over the past few months talking with a number of members of the Drupal Association, various Drupal.org volunteers, Drupal core/contrib developers, as well as other interested parties, in order to determine how to put into place a structure that clarifies the decision-making processes around Drupal.org. The following is the overall proposal for Drupal.org governance we've come up with, as well as links to more specific draft charters for community review.
Note: the finer points of this can be found in http://buytaert.net/files/drupal-governance-plan-2013.pdf.
While "governance" can sometimes sound like a scary word, really it's about coming up with a way to:
- Make decisions fast,
- In as lightweight a way as possible
- Allowing affected parties to have a say,
- With clearly-defined processes and easy to understand decision-making.
Cracking this problem for Drupal.org provides us with less frustration/uncertainty among volunteers, more money and resources funneled into improvements, and better community velocity overall.
Governance mostly comes down to establishing "working groups" around major areas of the project, many of which already have governance in at least an ad-hoc basis. Working groups will consist of a chair, plus 3-5 members who are empowered to make decisions, then a team of N volunteers and/or DA staff to help carry out their tasks/policies. The working groups are only empowered to make decisions as a whole, not on an individual basis.
Drupal project governance / Drupal.org governance compared
For the Drupal project, we are working towards developing a number of working groups related to various aspects of the community (security, documentation, conflict resolution, Drupal core, etc.), with myself as the final decision-maker:
The working groups might be compared/contrasted this way:
|Community working group||Technical working group||Security team||Documentation team||Drupal core X working group|
|Guarantee a friendly and welcoming community for the Drupal project by upholding the Drupal Code of Conduct.||Maintain technical policies, procedures, and standards as required to keep the technical side of our community operating smoothly.||Maintain technical policies, procedures, and standards as required to keep our projects secure||Make sure that we have high quality technical documentation for Drupal, including the Drupal handbook and API documentation||Provide technical leadership and project management for Drupal core development.|
In the case of Drupal.org, however, it makes sense for this final decision-maker to be the Drupal Association, since they are ultimately responsible for the website, purchasing hardware, etc.
The working groups might be compared/contrasted this way:
|Drupal.org infrastructure working group||Drupal.org software working group||Drupal.org content working group|
|Responsible for all infrastructure-related needs of the Drupal project, including the servers, Git repositories, mailing lists, DNS management, e-mail management, network, server access and security.||Responsible for guiding the planning, architecture, development, and maintenance of the Drupal.org websites.||Responsible for maintaining policies around the major content areas on Drupal.org. They also manage the overall look and feel and voice of the website, including its information architecture and design elements.|
Needless to say, groups will often have to work together. For example, to answer the question of whether to keep developing project module or move our collaboration tools to Github, we'll have to get the following groups together: (i) the Drupal.org software working group because it affects the features of drupal.org, (ii) the Drupal.org hardware working group because they may need to host new features, (iii) the technical Working Group because it impacts how we collaborate on software development, and (iv) the Drupal Association Board of Directors because they have to write the check.
Draft charters for review
This is a work in progress. Please help shape the future of Drupal.org governance by reviewing and commenting on the following proposals:
- Drupal.org Infrastructure Working Group
- Drupal.org Software Working Group
- Drupal.org Content Working Group
- Technical Working Group
- Community Working Group (Already formalized)
Our plan is to allow everyone in the community to provide feedback during the next 3 weeks. Then, around the end of March I will post updated drafts based on community feedback, with the aim to finalize the charters by the mid-April.
Onward and upward
I'm really excited about the possibilities for Drupal.org in the future with this governance structure. My hope is that this helps address some of the ambiguity and confusion around the current structure, while at the same time not being overly constrictive.
Thanks in advance to everyone for their participation in helping to shape the future of Drupal.org!
Today is bittersweet for the Drupal Association, as Jacob Redding has transitioned the Executive Director role to Holly Ross. Jacob did a phenomenal job growing the Drupal Association, Drupal.org and Drupal as a whole. Jacob’s special attention to the community has helped create a culture that many of us are proud to be a part of; his passion and dedication for Drupal has always been evident.
Under Jacob’s leadership we have broadened our activities, streamlined operations and significantly increased revenues. The Drupal community members grew by 1143% to 800,000 and we gained 3286% more committers to 23,000 in just three years. That said, our DrupalCon sizes and attendance expanded, which has helped increase Drupal adoption throughout the world. The Drupal Association staff of 12 has settled into Portland and is well positioned in Oregon's active open source community.
With Holly onboard, our vision remains to become the largest open source, non-profit organization that continually increases its support to the community and project. Jacob, thank you for all your hard work and tenacity! I look forward to continuing to work with you in the community.
I'm pleased to announce that the Drupal Association's Board of Directors has appointed Holly Ross as its new Executive Director. Holly is a well-known visionary leader in the nonprofit technology community with a proven track record of developing and implementing organizational strategies that provide direct community benefit.
Most recently, Holly was responsible for NTEN, the Nonprofit Technology Network, which works to help nonprofits use technology to create the change that they want to see in the world. During Holly’s ten years at NTEN, she helped grow the community from just a handful of individuals to over 60,000 people. NTEN has also been using Drupal for the last six years, so she is no stranger to our community.
Holly shared her excitement with the Drupal Association Board of Directors about her new role, saying, “I am thrilled to be making this move, which allows me to capitalize on my experience building community and embrace the added challenge of helping this international community collaborate on the Drupal project. I can’t wait to get started and be a part of a group of colleagues who share the values and passion for technology that I do.”
We are fortunate to have someone like Holly step up to lead the Drupal Association. Holly will start on February 1st, 2013. Like the rest of the Board of Directors, I look forward to working with Holly to grow the Drupal Association and to support the Drupal project.
Holly succeeds outgoing Co-Managing Director Jacob Redding and interim Managing Director Megan Sanicki, who both led the Drupal Association during the search process and have prepared it for new leadership over the last few months. The Board and the entire Drupal Association thanks Jacob for his hard work and dedication over the last several years. He has architected a strong foundation for the Drupal Association that allows Holly to take the organization to the next level. We wish Jacob best of luck with his new ventures. We are excited to have Megan continue with the Drupal Association as Chief Operating Officer, focused on Operations and Business Development.
Holly is looking forward to connecting with our community, and you should feel free to reach out to her with your feedback and ideas at email@example.com.
In June, Jacob Redding, our Executive Director at the Drupal Association, decided that it was time for him to transition out of the Executive Director role to pursue new challenges. Hence, the Drupal Association Board of Directors started a search for a new Executive Director. We have had some very promising conversations, which we feel will lead to a strong placement that will strengthen and grow the Drupal Association and the community.
The Board understands the importance of the Executive Director search and is conducting it with diligence and thoroughness. Since that means there is a chance that the next Executive Director will not be secured by Jacob's departure, the Board has worked with the Association staff to implement a continuity and transition plan for the organization. For the next four months, Megan Sanicki, former Director of Sales & Business Development at the Drupal Association, and Jacob Redding will both serve as Managing Directors of the Association. Megan has already worked closely with Jacob over the last two years to build the Drupal Association and set direction. In the event that there is a gap of time between Executive Directors, Megan will be well prepared to bridge that gap and ensure operations continue without missing a beat. And, in this new role, she will focus on optimizing Drupal Association operations, so we will be positioned for the new Executive Director to start strong on his or her first day.
Please welcome Megan to her new position at the Drupal Association.
Earlier this year, I posted about our first Drupal Association community elections. We introduced the community elections with the goal to make sure that the Drupal community is always well-represented on the Drupal Association's Board of Directors.
Well, the time has come to run our elections again. Nominations opened on 1 September and were open for two weeks. 18 people from the Drupal community put themselves forward as candidates. Please have a look at the election candidates. Voting will be open from September 24 to October 7 but now is the time to engage with the candidates.
Who can vote?
You are eligible to vote if you have an account on drupal.org, logged in during the past 12 months, and created your account before August 31 this year when the election was announced. Once voting opens, you can login at http://association.drupal.org and rank the candidates in order of preference.
How does voting work?
Voting uses the 'instant runoff' method powered by Drupal's own decisions module. For more information about this method of voting, watch this helpful YouTube video which explains it with post-it notes!
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.