Defining Our Roles in the Drupal Community

holly.ross.drupal's picture

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

Comments

Consult or Con+Insult?

slef's picture

Much of that sounds good, but I'm disappointed by the description of the drafting process. It's the bad old usual one where a group of insiders go write one draft at retreats and similar, then that's presented to us outsiders as the only option, maybe with a little fiddling around the edges allowed, unless any volunteers can repeat the drafting work in even less time and with a fraction of the resources.

Could Drupal learn from the great development work done by other hybrid community projects and use something like http://www.neweconomics.org/publications/entry/crowd-wise to reach a better solution?

Great framework

holly.ross.drupal's picture

Hi MJ -

Thanks so much for the link - that's a really great framework, and reminds me of the IRV election process we use for At-Large board elections. I want to clarify - did you mean that we should use a process like this to get to adoption of RASCI with the community, or for every decision we make about a whether we hire a consultant, rely on volunteers, or take it in-house?

I definitely hear your concern about the drafting process, and want to assure you that we want this to include real feedback from the community. Couple of things I would add to flesh out the text that's written here:

  1. In the first phase, the team members are talking to about 50 community members who represent all kinds of Drupal.org users and are from all over the world. We're doing in-depth interviews to understand their needs, concerns, and feelings before we begin drafting.

  2. I would like to add that since we posted this, the team of staff and board that are leading this work had a kick off meeting, and we decided to add an additional step to this phase. We will be posting a version of the RASCI as a survey and asking anyone in the Drupal community to tell us where they think the responsibility lies.

So with these two methods, we will have both qualitative and quantitive feedback from the community to use in the initial draft. Hope that allays some of your concern, and am happy to hear more.

What decisions?

slef's picture

In the current setup, I think it's largely up to the directors when they feel it appropriate to build a community consensus: if they get it wrong, I hope the community will either redirect them or boot them out.

I was suggesting it for both the values and the Responsibility Assignment Matrix here.

I'm not really placated by that. I suspect I wouldn't consider any of the secret 50 community members to represent users like us or those we collaborate with, because I feel DA has been rather poor at consulting other civil society groups, and I've seen too many surveys where the questions or the methodology have biased the answers. If you'd like to read more about how I run surveys, I published http://people.debian.org/~mjr/surveys#advice many years ago and http://www.news.software.coop/get-the-survey-monkey-off-your-back/878/ slightly more recently.

Your Responsibility Assignment Matrix is wacked!

Michael-Inet's picture

First lets reflect on:

"THE DRUPAL COMMUNITY DID ALL THAT AS VOLUNTEERS."

That means they can!!!!

Why does the DA want to change that ability?

We believe strongly in the power of individual actors to create amazing things and want to empower volunteers.

Good!

But we also want to provide staffed services to ensure that the lights stay on without overburdening volunteers.

HORRIBLE! Self-Serving! Can be read as, "I want to keep my cushy DA job!"

+1 MJ Ray (slef), "Consult or Con+Insult?"

It's the bad old usual one where a group of insiders go write one draft at retreats and similar, then that's presented to us outsiders as the only option, maybe with a little fiddling around the edges allowed, unless any volunteers can repeat the drafting work in even less time and with a fraction of the resources.

Exactly. For something as overarching as "How the DA pays people" the community needs to decide this, not have a Board/Staff committee create a draft and in essence shove it down our throats.

"Us vs. Them?" Please don't.

And one bad example of how not to Request for Proposal. Or is the DA already hiding by obscurity?

https://association.drupal.org/node/18998

There is a Drupal Group just for Jobs, why is the DA not using it? And from https://association.drupal.org/content/drupal-job-board-will-be-built you're about to screw it over by replacing it with the DA's private job board with "paid and subscription capabilities?" Great, I'll never be able to post a $20 bounty again without paying the DA just to post it?

How ominous to find a seemingly live example?

Furthermore, why was the Drupal Job Board, Request for Proposal even created before this discussion was started?

-#-#-#-#-#-#-#-#-

The above is intentionally inflammatory. I'd say I'm sorry about that, but I'm not, this discussion is too important to drift off into banality like the "Volunteer or Contractor?" discussion did.

There has been no clarity about what, exactly, Association staff are responsible for.

This seems to be the crux of the problem. DA doesn't have a grip on what it should be doing.

And as opposed to thinking, "we think there are certain things that make sense for a volunteer to tackle, and some situations where a contractor makes more sense, [and things only the DA should do]" where the community get's the impression that the DA hides in the dark the really good [paying] jobs, through favoritism, nepotism, [insert other corporate insider political badness], or just keeps the task to themselves to guarantee their paycheck...

How about something a bit more flexible and most importantly open?

Here's one alternative for "some clear guidelines that make it easy to understand who is responsible for what."

  • The DA lists everything that needs to be done, in a single place, that includes not only all details (requirements, desired completion time, max budget, etc.), but also includes a flag for "provide more details," to circumvent cries of those concerns of favoritism, nepotism, et al.
  • People/firms openly bid on what they want to perform a task/item.
  • The community then votes for who they want to do the task.
  • After the task is completed, the community votes on how well, or badly, the task was performed.
  • The community gets to see the prior tasks results of the bidding entity.
  • Recurring items (hosting, etc.) go up for new bids, no less than yearly.
  • Any other Drupal member can post Bounty/Bonus/Issue Queue Sponsorship to this list.
  • A block on the Drupal.org frontpage lists the last five task entries.
  • {insert more to make this Drupal Wide useful}

It's just an example, use it or not, but please don't fall into the corporate/insider trap you seem to be heading for.

@Holly, I do apologize for the tonality, there is nothing personal inferred. I'm sure you'll agree Drupal is not served by it's membership not having full faith in the Drupal Association.

Best Regards,

Michael

Hi Michael - So, there's a

holly.ross.drupal's picture

Hi Michael -

So, there's a lot in your post to respond to, but I want to address one thing first:

Or is the DA already hiding by obscurity?

I promise you that hiding in obscurity is not our intent, nor is it our intent to try to hang on to our jobs. Everyone who is here is focused on serving the community and takes that mission very seriously. We are also working very hard to increase transparency about what we are doing and why. If we were trying to hide, we would not have written this post or planned for community involvement in the process. In the last year, we have demonstrated our intent to be more open repeatedly - posting financials, hosting community discussions, writing about our processes. I can't MAKE you believe it, but I hope our actions will continue to back this up.

the community get's the impression that the DA hides in the dark the really good [paying] jobs, through favoritism, nepotism, [insert other corporate insider political badness], or just keeps the task to themselves to guarantee their paycheck

We have strict financial policies so that favoritism and nepotism do not rule the way we approach hiring. Any contract that could total $25,000 or more must be subject to a public bidding process. We followed this process for the job board. We are also forbidden from awarding multiple contracts to one person/business that could total over $25,000 without a bidding process. So I can hire someone I like now for a $5,000 job and just keep extending $5,000 contracts forever to get around the rule. These contracts are reviewed by the Finance Committee and the Board.

This seems to be the crux of the problem. DA doesn't have a grip on what it should be doing

That's right! We definitely have ideas about how this work should be done, but the Association was created after a community already existed. We're looking for the right way to amplify and support the work we're we're all doing. You can't criticize us for being too secretive and controlling and then turn around and say that we're not clear enough about what we do. That's the point of this conversation - to come to an agreement within the community about what our role is so that we can move forward professionally and without the tension that surfaces now.

There is a Drupal Group just for Jobs, why is the DA not using it?

That's a really great question. Before we made the hire for the job board, we talked to dozens and dozens of Drupal shops around the world, as well as the folks behind the job board on Groups. It was clear to all those people that the Jobs Group is not effective for recruiting and hiring talent. It's just not meeting the needs of the people who would want to use it. We also know there are community members who want to see Jobs moved from Groups. We looked at ways to integrate the existing job board functionality into a new product, but we ultimately felt that it made more sense to build from scratch for a variety of reasons, chief among them our ability to protect user data about job seekers on a site controlled by staff who are governed by NDAs in their employment agreements. And - we committed to keeping a free level of posting service that is equivalent to what you get on the job board now. So you only need to pay if you want additional features.

As I mentioned in my reply above, I definitely don't want to set this up as an Us vs. Them conversation - that's why this post is out here now. So I'll be taking the constructive comments and figuring out how to weave them into the work we are doing.

+1

Crell's picture

Holly, this sounds like a reasonable overall guideline. The diagrams make it very easy to follow. (Yay for Venn Diagrams!)

To those objecting on "the community can do it" grounds... well... not really. "The community" doesn't maintain Drupal.org; it never has. A small group of horribly over-worked dedicated people that we put way too much pressure on maintains Drupal.org. And that's not at all a scalable process.

"The community" can do a great many things, but doesn't necessarily do them efficiently or effectively. Why did the Drupal.org redesign take so long? Why did the Drupal 7 port take so long? Why have so many other things taken so long? A large part of it it because big strategic changes require a lot more structure and dedicated, predictable resources than "the community" is able to provide. That's not a slam on the Drupal community at all; it's just a straight up question of consistent hours from consistent people. (Drupal core suffers from the exact same problem, but the barrier to entry is lower so we don't see it quite as much. It's still there, though, and it's painful.)

I used to be on the DA Board, and have been on the Advisory Board for the last few years. I've seen up close where the "let the community do it, the DA should not get in the way" approach has failed, every single time, when it comes to large-scale Drupal.org work. If anything, I'd argue moving to a combination of paid staff and paid contractors (with a proper public bidding process) is not an invasion; it's years over due, and my only criticism would be "why hasn't the DA done this sooner?"

Holly, please proceed. :-)

Drupal Association

Group categories

Category

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

Hot content this week