Last week the DA hosted its first webinar, featuring Kevin O’Leary, Spark UX Lead, and Jesse Beach, Senior Front End Engineer. Our topic was Drupal 8 and Spark for Responsive Design. We spent a great hour reviewing the features of the D8 Spark distribution and the powerful features that it puts in the hands of content editors, wherever they may be. As a person that used to hand code web sites, the idea that I can edit a site from my phone still fills me with awe. A huge thanks to the over 500 folks who registered, to Kevin and Jesse for presenting, and to Acquia for helping us launch this program.
If you missed the session, here's the video:
I've also just sent a list of the unanswered questions from that session to Kevin and Jesse, so we'll hopefully have a few more details up shortly in another post. Oh, and you can find this webinar, plus a whole lot of DrupalCon session recordings, on our YouTube page!
Of course, we walso wanted to address some of the questions that our first webinar raised. Though we've had a lot of great conversation in a previous blog post, we wanted to follow up with some more data and ideas. Here's a bit of a data and some narrative based on your feedback:
Is the DA getting into a an already too-crowded space with webinars?
That was certainly a risk. You're right, there are LOTS of folks out there who are producing great webinar content. My instinct is that while there are lots of folks doing webinars, our audiences aren't as redundant. In other words, the Venn diagram of our audiences don't have a TON of overlap. Greggles smartly suggested that we prove this theory by comparing the registration list for this webinar with the registration list for the last time Acquia held the same topic. We decided not to pursue that because we didn't want to get into the privacy issues that would raise (even if we mask for only domains on email addresses, we learned that the APPEARANCE of data issues is too big a risk). However, we can report that we had 502 registrations for that webinar, about equal to what Acquia pulled in just a few weeks earlier with the same content. We can't prove it, but I feel strongly that this suggests that our audiences don't overlap too much.
So if we all have different audiences with relatively little overlap, the DA can play a very constructive role. Our intention is not to create all new content and try to compete with folks already out there. Instead, we'll be working with our community, starting with our supporting partners, to highlight the great content and remarkable speakers they already have, and bring that to a new audience.
Is the DA too busy to handle a webinar program? Is this the RIGHT way for the DA to spend its limited resources?
I raised the point in our previous blog post that the DA is pretty resource constrained. And it's entirely true. However, we have a BIG mission. Our mission is to support the Drupal Project, the community, and its growth. Since re-forming just a couple of years ago, the DA has grown tremendously and taken on a lot of great work, but the truth is that most of this organization's resources are focused on DrupalCons. In one way, that's fantastic. Cons are a wonderful way to meet lots of objectives -- building the community (BoFs! networking! so much coffee!) as well as supporting the project (Sprints! Training!). Cons can even contribute to the growth of the Project by attracting new site evaluators and developers.
But Cons can't do it all. We at the DA have to grow into new programs and services to support all the areas of our mission. Webinars are a relatively low-resource way for us to start in the direction of supporting the growth of the project. It's easy to experiment with webinars and see - are we bringing in new people to the Project?
Were we transparent enough?
Maybe. Maybe not. The real answer depends on your definition of transparency. We did our very best to disclose all the details in all of our messaging - how your data would be handled and why we partnered with Acquia, among other things. If we didn't say something up front, it wasn't because we were deliberately trying to hide something, it was simply because we didn't realize you would want to know. When I read through all the comments on the DA blog, I actually see a few issues tangled up in the word transparency:
- What IS transparency anyway? I think there are some legitimate questions to explore here. Is it transparent if we tell you after a decision is made, but not before? What decisions are we obligated to share with you? How operational and tactical? When do we talk about strategy?
- I've also seen questions around who decides. If the DA wants to pursue something new, can we just do that? Or do we need to get permission from the community? Or do we just need community input? And do we need that input or permission for everything? If not, what are the things that we DO need to bring to the community? And what if eight people hate it, the vast majority have no opinion, and a few people are excited? What does that mean?
- Finally, I think the community has great questions about the scope of the DA. Is growing the community even part of our mission? How do we interpret the (intentionally) broad language of our mission statement?
I have opinions for each of these, but what really matters is that we have collective clarity here. We're never going to be as strong or as productive as we can be if we aren't starting from the same place - and this is an important part of that. So I'll be looking for ways for us to have this discussion going forward, and certainly welcome your comments here.
And in conclusion...
This is going to be a very dynamic time for the DA while we stretch our legs and find new ways to serve the community. We're going to make assumptions that turn out to be wrong. We're going to forget to include some things and overplan for others. What we need you to know is that every single staff person here has the exact same goal you do: making Drupal awesome. So when we stumble, you should absolutely call us on it. But also, help us get back up. We really are in this together.