Drupal 8 fireside chat: A D8 PM Perspective

For the last 6 months or so I've been a volunteer project manager for the Drupal 8 core development process. I've been helping (as much as time allows), with the regular calls held bi-weekly to go over progress and with fleshing out some details on initiatives. One of my goals is to bring transparency on the calls for the community. I realize an update is overdue, and it will be coming soon. In the mean time, I wanted to share some of my perspective with you. Take it with a grain of salt, I know many of you have more years of experience than I do in this group, and I hope to hear from you to enlighten me where necessary.

The Drupal Dream: The good, the bad & the ugly

The promise of Drupal as I see it, is that web people from all over the world, who speak different languages, and hail from varied cultures come together to build an amazing web development toolset that ultimately benefits the web community at large. It's all very kumbaya, kittens (live ones), rainbows and unicorns. Sounds great right? Now the bad news: Drupal is a complicated beast as open source web tools go. Other web toolsets don't have the same environment issues, and I'm not talking about servers. Drupal decisions are made by community consensus. Dries and several other key delegates help to resolve conflict, but ultimately, the community decides. I've heard from Drupal community members that this is what sets Drupal apart from other platforms. It's also what makes Drupal decisions so hard to make. That's where it can get ugly. This group is full of passionate, talented and knowledgeable people and for that, I'm grateful. On the other hand, there are many egos to balance, many itches to scratch and many many people to *try* to please. This is a creative environment that many label as a "Do-ocracy", meaning, "You want it, do it!", but at times it seems to me like a "Do-crazy". Tensions run high occasionally, and that's to be expected. What is unfortunate, is that I sometimes hear about people impeding progress because they disagree, and that doesn't seem to go along with what Drupal is all about. The Fireside Chat that Dries held a few weeks ago brought up some questions, that deserve discussion. But, I think keeping the big picture in mind is important. The initiative leaders are very dedicated to the community, and they're donating an incredible amount of time to making it better. I really admire their efforts and applaud them for all they are giving. That goes for the rest of the community of contributors as well -- you lot are pretty awesome.

Drupal 7 Lessons Learned

During the meeting, Dries and Angie shared some slides about lessons learned from the Drupal 7 release that I wanted to put in here in case you missed it (http://blip.tv/dries-buytaert/chat-with-dries-drupal-core-development-process-5839273). I commend the community for taking a beat to reflect on the past (More here: http://buytaert.net/drupal-7-development-process-retrospective). So as we can see in this image, some formalization and structure are becoming a part of the process. But issues around Drupal version development remain, check out these next two slides:

What does this mean?

Most of these last 2 slides seem to revolve around the decision-making process (Initiative leader authority, community empowerment, release modeling, communication, prioritization, the list goes on). I know, you're going to say "The buck stops with Dries.", but realistically with all the decisions to be made, I think we can agree that he can't be everywhere at once. From where I'm sitting, it sounds like we're facing a problem that is essential to Drupal's growth and success: How best to suss out, convey and support the community consensus? Dries has chosen to implement initiatives in this release cycle to help solve this problem.

What I like about initiatives:

1. We're setting goals. Goals are good and bring focus to our project. I believe goals are the basis for any project's success, and I've said so in previous blogs (http://www.bluesparklabs.com/blog/10-ways-rock-your-project-planning). If you don't know where you're going, you'll never get there. As a Project Manager on the D8 initiatives, I've seen some changes that are rattling cages, like #2 below. 2. We're being specific. Instead of making a sweeping statement like, "we're going to make x better", we're trying to get a clearer vision of what exactly we are going to make better, how and why. We haven't time boxed anything at this point, but it doesn't seem to be an issue yet since we don't have a code freeze date. Another thing we lack, is specific assignment of tasks to resources, but that's the nature of the beast in a community of volunteers. However, steady help is here, and that is #3. 3. We've got leaders. I don't think it's realistic to expect Dries, Angie or Catch to do all the work. I love the idea that people have stepped up and said, "I'll help!". That's the Drupal spirit! Furthermore, we need it. We need people who are willing to lead the charge and follow the details. It also means more outlets for the community's voice. Which leads me to #4. 4. We're listening to the community. I've heard some think decisions are being made behind closed doors, but from what I've seen as a part of the Drupal 8 project, that is not the case. On every scrum call we've had, I hear all the initiative leaders pointing out suggestions, improvements and disagreements between their proposals and the community.

Why are these things bothering people?

1. The process is changing. I'm definitely hearing push-back about the initiative process and version release model coming from different groups in the community, and even initiative leaders themselves. This is still evolving from what I'm seeing, so it's hard to know exactly what the end-game will be. Having lieutenants and initiatives is a departure from the "standard" method used in previous Drupal versions, and it puts some pressure on the leaders and their helpers to get things done. The organic creation method is a fine way to go, but at some point, I really believe some organization is necessary. I think Drupal 8 has reached that point because these initiatives need support, more than just one person can handle. When we're talking about multiple people, multiple goals, thousands of issues to track, etc -- I think there is some real merit to adding more structure to the mix. Definition of success, prioritization, planning can be powerful tools to employ to rally support and direct it where it's most needed. I'm not sure if the community feels like this is necessary or not, but I'm keen to know. Are they getting enough information? Is it digestible? Could you use more organization? My gut and past experiences tell me that this stuff is useful and helps projects succeed. 2. The community wants more control. Discussions I've had at and after Drupalcon London that lead me to think the community doesn't feel like they have chosen the initiatives. Imho, Dries asked for feedback and compiled it into a useful summary (http://buytaert.net/drupal-7-development-process-retrospective-summary), but the format of comments is not the greatest for determining consensus. Not everyone who has a strong opinion necessarily wants to take the time to read comments and reply back. I think the IRC chats and fireside chats are a better public platform where people can just chime in, it's more organic. I think there's a second problem here… the feedback was compiled, and the decisions were made, but I'm wondering how. Was the community making that decision? Should they? Should Dries? Should the initiative leaders? I don't have the answer to that question. Maybe we should expose all of the arguments for each initiative online (pros, cons, who benefits, why, how, etc), and create a poll module to tally community votes on where their priorities lie? 3. Momentum is slow, and there are complaints about process. People are expressing that the development process (having project managers, phase gates and critical bug thresholds, documentation, etc) is slowing down progress. I think the initiative-style management of this release is going to help us nail down what/why/how/when/who, and may even save time in the long run. Sometimes good planning goes a long way. In the Fireside Chat, Angie mentions that people feel like Drupal 8 momentum is slow due to a focus on Drupal 7 clean up before version 8 really got rolling. The question was put to the community, "are we doing this right", but I don't think they got an answer. Angie said feels hopeful that momentum will improve, and I agree with her. We've only just begun the Drupal 8 journey, it seems preemptive to discount the community's momentum and moral after only 6 months! (Started during Drupalcon London, August 2011). Lots of things are happening, though they are in flux, as we've seen with the WSCCI initiative and the big direction change that Crell has recently proposed (http://groups.drupal.org/node/198538). 4. The community feels they can't/shouldn't work on non-initiative issues. With all the hubbub about initiatives, there is a general feeling that other work doesn't matter, or worse, shouldn't be worked on. These initiatives are important, yes, but that's not all there is to do in Drupal 8. Angie pointed out to me her surprise that people felt they couldn't work on things that aren't initiatives, and as much as we want to achieve these goals, we don't want to stop the contributors from scratching their own itches. 5. Distrust of Acquia. Some in the community feel that Acquia is influencing these initiatives to serve their own agenda. Based on everything I've said above, it's obvious that I don't believe that and I strongly urge the community to take into account my testimony as a non-Aquian.

What's next?

I don't think that the fireside chat solutioned the topics on its agenda, but it's a good conversation starter and upholds Drupal's ideals. Change is hard to manage, and communication is key to adoption. More of these chats, maybe one per topic with a goal to resolve it, perhaps with a poll/vote system to get consensus, would be a great way to keep the community involved in the decision-making process. There are still some questions about the release model, and I hope more discussion on that will follow. I think the topic from the fireside chat "What if there is no consensus" is a valid one that also merits a good think. (ie: Does Majority rule in case of non-consensus?) I realize setting public, specific goals will be stressful if they aren't met, but we all know that Drupal 8 Initiatives are dependent on volunteers, so imho, it's not going to be any one person's fault, but rather a community failure if something doesn't get done in time. And so what if it doesn't? Drupal 9 will need initiatives too ;) My point is, we all do what we can, and a great bunch of people are doing a lot. These problems aren't going to be resolved overnight, or by any one person. It's going to take some time to hash out a comfortable process, and we should embrace change if it helps us create a better, stronger community and product. What do you think about all this? Any ideas to help us resolve the problems that Dries points out? Any reactions to my reaction? Resources: Fireside Chat: http://blip.tv/dries-buytaert/chat-with-dries-drupal-core-development-process-5839273 Drupal 8 on D.o: http://groups.drupal.org/drupal-initiatives Drupal 8 write up from Crell on WSCCI: http://groups.drupal.org/node/198538 Drupal 7 Development Process Retrospective: http://buytaert.net/drupal-7-development-process-retrospective Drupal 7 Development Process Retrospective summary: http://buytaert.net/drupal-7-development-process-retrospective-summary Core Gates: http://drupal.org/core-gates