Thử define 1 Roles trong the Drupal Community

We need a better way to work together

This is a dense topic, and this post is very long. So, let me provide a short summary here before you all tl;dr me, which would be deserved. The long and short of it is that Association staff and other community members have to figure out a better way of working together. This post is meant to start a discussion that will lead to clear definitions we can use to better understand each other and our collaborative work. I will certainly explain more below, but you can skip to the bottom if you want to get to the logistics. Now - for those who love detail…

A bit more about the problem

I’ve been at the Association for a little over a year now and I’ve heard a lot and learned a lot during this time. On the whole, the feedback I’ve heard has been incredibly positive about the future of Drupal and the role of the Drupal Association in supporting that future. I’ve also heard criticism of the Association.

I welcome constructive criticism because I firmly believe it leads to reflection and improvement. That’s what we’ve been striving for at the Association - improving the services and support we provide to the community, with the community. To that end, we have had wide ranging conversations with many of you about everything from how to staff the tech team to improve Drupal.org to how session selection should work for DrupalCon. In all those conversations, covering so many disparate topics, there seem to be a couple of constants:

• A lack of clarity about the mission of the Drupal Association
• A lack of clarity about the role of Association staff alongside community volunteers

In other words, we lack a clear vision and mission framework that articulates our role within the community and how we work alongside volunteers.

Here’s the way I summarize this conundrum. I’ll use Drupal.org as the example because that is where we are focused in 2014. We have recent examples that highlight the kind of tensions and problems that can occur without this clarity. However, I think we could use these same types of diagrams to explain DrupalCons and other programs, beyond our work on Drupal.org.

We have to start somewhere, so I am going to start with a gross oversimplification. Essentially, there are three kinds of work to be done on Drupal.org. (I know, there are more, but I am starting with a gross oversimplification!):

• Strategic Value: This is the work that moves the site forward in big important ways to achieve specific community goals. A great example of this kind of work was the Git migration. The goal was to make Drupal.org a better tool for developers (that’s the Strategic Value) and the Git Migration was one project that helped meet that goal. These are usually high-visibility, big, and/or disruptive projects.
• Scratch Your Itch: This is the work that makes Drupal.org users happier and addresses every day pain points. This is often tweaking a feature that’s already in place. For example, several enhancements to the UX of the issue queues were just made. These are usually highly visible, but usually smaller projects. They can definitely be disruptive.
• Make it Work: This is the behind the scenes work that is critical to ensuring that something shows up in your browser when you come to Drupal.org and ensures that the data you enter on the site is not compromised. This work is generally invisible, but is often big and, if done right, not disruptive.

For most of the history of Drupal, all of this work was done by volunteers:

Let’s just take a moment here and pause to reflect. THE DRUPAL COMMUNITY DID ALL THAT AS VOLUNTEERS. I continue to have trouble wrapping my head around how that is possible, and find it to be an inspiring example of the power of good people doing good things together.

Fast forward to a few years ago and the Drupal Association enters the scene. The roots of the establishment of the Association are in the DrupalCons. Producing such large-scale events had become a financial and logistical burden for the community. But, it’s important that the physical aspects of Drupal.org - like the servers - have a legal entitiy to call home. The mission of the Association clearly lays out that the Association is charged with maintaining both the hardware and the software of Drupal.org.

The problem is that the mission is clear, but the HOW is ill-defined (purposely, but we DO need to define it). Maintaining the hardware and software can be achieved in many different ways. The Association could play the role of volunteer coordinator only, ensuring that volunteers have what they need to continue to support the site. The Association could choose to hire a huge tech staff and handle all of it in-house. But we don’t want to live at either extreme. We believe strongly in the power of individual actors to create amazing things and want to empower volunteers. But we also want to provide staffed services to ensure that the lights stay on without overburdening volunteers.

Wanting to have it both ways has been a little messy:

For the last couple of years, Drupal Association staff have been dancing an uncomfortable dance within the community, where no one quite knows who’s supposed to be leading. Our limited staff have been maligned both for not taking enough responsibility for driving changes on the site and for taking too much liberty with the site. There has been no clarity about what, exactly, Association staff are responsible for. Many of the failures in the last two years have been driven by this lack of clarity.

Increasingly, we believe that the Association can and should play a similar role for Drupal.org as it did for the Cons - take on the burden of making it work so that the Community can focus on their passions. And, as we have done with Cons (to an increasing degree), this success of this will depend on knowing who does what. As discussed in the volunteer or contractor discussion we started on GDO this year, we think there are certain things that make sense for a volunteer to tackle, and some situations where a contractor makes more sense. I would like to see us address these issues with some clear definitions:

We need some clear guidelines that make it easy to understand who is responsible for what - BY DEFAULT - but are flexible enough to allow for situations where the circles intersect. For example, we can’t expect that only volunteers will work on things that “Scratch Itches” - the Association needs to make sure that developers can do their work productively. We have also seen Volunteers lead amazingly successful projects that have high strategic value, and lots of volunteers helping maintain major services and make sure everything works. We’re not trying to define a zero-sum equation, but a framework that provides guidance without mandating absolutes.

As a community, we took a huge step forward last year in chartering and forming the Drupal.org Working Groups. The formation of the Working Groups established clear decision makers who are empowered to decide what changes we (the community) can make on Drupal.org. However, it is still a challenge to decide WHO should do the work. If we need to implement Back-links on commit messages, who does the work? In this case, the Drupal.org Software Working Group decided to hire a contractor (marvil07), but there was a substantial amount of discussion about how to make that choice. That’s time that could have been spent just implementing the solution if we had clear processes.

So What’s Next

It has become increasingly evident that if we do not address these larger issues, we will continue to run into problems and stumble frequently as we continue to grow and evolve. So at the January board retreat we spent two days talking about the future of the Association and how to create a framework that will allow us to confidently navigate the future, anticipating needs and taking advantage of opportunities as they arise.

The bottom line is that we have to choose a new path forward. More of the same will mean that Drupal.org remains behind the times and that we never get to the point where we can address other important community issues like growing our community of developers.

So today we want to launch a widespread conversation that helps us address the two pain points and prepares us to live up to the idealism of Drupal itself - that anything is possible. In fact, we started to nibble at the edges of the volunteer/contractor issue a bit earlier this year. You’ll be seeing even more communication from the Association over the next several months regarding this shift and your role in helping shape it. At the end of the process, we will produce:

• A vision and revised mission statement. These two elements are set by the board as the strategic gatekeepers for the Association. These statements will provide the context for all the work we do at the Association and will help shift the Association from reactive mode to anticipatory - an organization that can meet community needs as they come up, rather than reacting to issues.
• Values statement. Values are an essential part of our work. If the vision and mission statements tell us WHAT work we do, our values statement will tell us HOW we do our work. A committee made up of staff and board members will work on a draft that will be discussed with the community before it’s finalized. It will be important to remember that these are Association values, not the larger Drupal community values, which may be slightly different (and not something we are going to tackle in this go around).
• Responsibility Assignment Matrix. Defining who does what is an essential part of any technology project, and is especially true in an open source project as diverse as this one. Another committee made up of staff and board will lead the development of a RASCI (Responsible / Accountable / Support / Consulted / Informed) chart in cooperation with you, the community. We will be posting updates and questions that will inform drafts that you review and comment on before anything is finalized. This will become our guidepost as the Association documents our processes and brings on new work.

Here are the rough timelines for this work:

Drupal Association Values

• (April/May) Board/staff Committee to create draft w/ community input
• (June 1) Draft discussed at DrupalCon Austin Retreat (2nd week of June) Revisions made and shared with community
• (Late June) Revisions made based on community feedback
• (July 9) Present to board at July board meeting for adoption

RASCI Matrix

• (March) Announce work to community
• (April) Board/Staff committee to research with key stakeholders
• (May) Board/Staff committee to create draft with stakeholder input (June 1) Draft discussed at DrupalCon Austin Retreat
• (Early June) Board/Staff make revisions based on board feedback
• (Late June) Draft shared with community (Late July) Board/Staff make revisions based on community feedback
• (August 13) Present to board at August meeting

After a year here at the Association, I am more convinced than ever that anything is possible in this community. We are creating some of the most powerful sites on the web and building strong community ties while we do it. The Association exists to support the community from within, but can only do so if we go after opportunity and fix the real problems that frustrate everybody.

I look forward to the discussions - and the criticism - that will spring out of this process and know that, like Drupal itself, we’ll build something great together.

Flickr photo: Stuart Chalmers