In my earlier blog post, I researched community governance in other open source communities. While it was not exhaustive, I identified a set of trends and practices communities use to serve community members. The question remains: what can Drupal learn from other communities?
To answer this question, we must understand where we are today. It turns out that answering this is quite difficult depending on our individual experience, network, and exposure to the community. Admittedly, with respect to Drupal’s governance, I am far from an expert. While I have been in the community for a while, I never paid any attention to governance and didn’t see a reason to. The situation with Crell made me begin to question such things out of fairness to him and the thought that other community members may need evolved community governance in the future.
Because I’m not an expert, you may question or disagree with any opinion I share. This area is fairly new to me. It also provides an opportunity for me to look at our governance with fresh eyes. My hope is that other community members will participate to open up the discussion on their own ideas that our community may inevitably adopt and/or explore. This concept is exactly what has made Drupal great.
In recent months, Drupal’s community governance has been a focal point of concerns raised by community members. Oddly, I’m not seeing community members propose new ideas (yet) in the same velocity of technical innovation. As community members, we may believe our governance to be broken and providing informed feedback goes beyond mere technical skill. We need to begin by acknowledging the need for a clean separation from technical and communal operations. This needs to be completely community driven. If ideas were to be sponsored by the Drupal Association or Dries, community members could raise concerns of bias or conflict of interest. That leaves it to us, the members of the community to explore changes to our governance. It’s time we recognize it is on us to sort this out.
Motivation: Ongoing evolution
While the Crell situation has been difficult, it’s actually made people pay attention to our governance (myself included). The response to this has been community-sponsored, facilitated discussions at DrupalCon, webinars, and countless hours of planning and discussion by the Drupal Association and others in communal leadership roles. Community members have shared their voice more so than I have seen in my time participating. The community needs to have an ongoing voice in community governance and we need to understand how we can continue to hold these discussions.
Not to sound critical, but our community likely needed to prioritize governance efforts long ago. It may have taken the Garfield situation for our community to recognize the need to pay attention. Governance is a critical function for community health. Through in-person conversation, Twitter, and participation in governance discussions, there have been concerns stemming from issues raised several years ago. I doubt there was an adequate structure or process to listen and engage the community around these concerns.
Agile is often a term people use to manage priorities of product evolution. The concept can be applied more broadly. At its core, Agile advocates for continuous learning. Drupal community governance needs to not be something that is just discussed once and concluded. It needs to evolve ongoing and in tandem with the evolving needs of members. Any outcomes from the current community discussions should recognize this is just the beginning. We need tools and processes that promote ongoing community involvement and impactful governance well into the future. We can’t let governance become an afterthought or it will once again become stale and ineffective. If done well, I see an opportunity for Drupal to become a leader in community governance, not a community struggling to move beyond a difficult and complicated situation.
I’ve heard many people demand clarity from the Code of Conduct. They want to know without any doubt that every community member is treated fairly. On the surface, this is a reasonable request. But I disagree with this strategy. What happens if there is conflict and it’s not addressed within the Code of Conduct? This seems to be the same awkward place our community found itself in the Crell situation. Clarity in the Code of Conduct is not enough. We need a process for making enhancements to it over time. Some may not subscribe to this since a Code of Conduct would be an evolving concept, but how can we ever expect a static document to represent every diverse situation we encounter as a community? It can’t. What’s more important is a clearly articulated, fair and just process for evaluating each situation that can include proposed changes to the Code of Conduct. It is irresponsible to think our Code of Conduct can scale without knowing what will come in the future.
Proposal: Governance Working Group
Much like the other working groups, our community needs a chartered working group responsible for handling community governance now and into the future. It’s primary function should be to provide community members the ability to propose, evaluate, and implement governance-related ideas in a transparent manner. This group needs to be responsible for building the infrastructure to listen to the community, hold routine meetings to discuss ideas proposed, and work with community members ongoing. Retrospectives should be held periodically to engage the community and solicit feedback on governance.
Idea: Standardize groups
For clarity, our community not only needs a new working group for governance, but it needs consistency from all of our community groups listed on our community’s Governance homepage. Consistency should come in the form of both structure and operations with a default of openness to promote transparency. We seem to have “core”, “working groups”, “initiatives” and “advisory groups” all represented in unique ways on the Governance homepage. Each group should have clear purpose in how they serve the community. There should be well-defined roles, operations, policies, practices, and documentation between groups such that any community member can easily understand and engage with when needed. Standardizing certain aspects of these groups and our online documentation would create clarity seen in other communities  .
Finally, roles within groups and within the community more broadly need to be clearer. Every group should have roles and the roles should be articulated clearly with respect to the function served. Other communities seem to articulate their roles clearly  . Due to the scale of our community, this may be more challenging. We need to more clearly define the types of contributors that exist, the various roles that exist in the groups, and, most importantly, the various roles that exist for our leadership structures. This needs to be articulated consistently and with the clarity that other community members understand the qualifications and expectations of those serving in the roles and how individuals may want to participate moving forward.
Idea: Better community documentation
While not directly related to community governance, it is my opinion that our non-technical community documentation has led to a serious amount of confusion. As previously mentioned, we need to look no further than the governance homepage. There is no background or context to inform the reader about how these groups serve the community. It’s an awkward mix of both technical and social groups with inconsistencies in both the format and information captured for community members. The community homepage, as a second example, only discusses the different tools and types of engagement that exist in the community. This has no information on who we are, what we do, our mission, our vision and much more. This is in stark contrast to the many other open source communities    that have introduced the community and offered “getting started” material with a series of useful links like a mission, vision, etc.
Our online community documentation needs to be revamped and decoupled from the technical documentation. There needs to be research and user testing on a more appropriate information architecture and complementary new content that presents the most useful information first and foremost. The usability of our documentation already seems to be a work in progress and there is a stark difference in online documentation even on drupal.org. For instance, a good example is our Support page and, in contrast, a page like the Community page could use some work. Equally as troubling are pages with extensive length, like the core maintainers page. As a community, we need to leverage our member’s expertise in creating engaging content to help make sure we are representing our community effectively through drupal.org. We may want to consider creating a completely different community site that separates the technical documentation from that of our community. These are all issues that my proposed Governance Working Group should be tasked with working through.
To reiterate, my desire is not just for people to be reading my ideas, but for our community to be engaging in a debate over ideas generated from a significant number of community members. If you don’t like my ideas, ask yourself why and come up with your own. We’re all capable of being critical of ideas, of our governance, of our community. But, it’s on us to actually take steps to improve the things we want to see change. Don’t just be critical, follow up with your own thoughts or ideas.