This session is about an experiment we've been doing in Boston to try to make it easier to contribute to Drupal core. The idea is to come up with activities and materials that we can share outside of Boston, but it's come to be called The Boston Initiative.
We need more people. Our talent pool is too small, and we need to solve this. From the perspective of the issue queue, the number of developers contributing to core has gone up from release to release, but as a percentage of users, the number has gone down from 0.5% to 0.1% since Drupal 4.7. As the popularity of Drupal skyrockets, the number of people making suggestions is going way up, and it's impossible for contributors to keep up. A lot of core contributors are feeling exhausted. Back in August of 2011, there were 9,000 open issues in the core issue queue. Only a very small number were reviewed and tested by the community, but 20% of them were ready to be tested by somebody.
This is also frustrating for site owners. How many people here have tried to hire Drupal talent but have not been able to find someone with the chops needed? How many people have tried to train a Drupal developer in house and found that to be a daunting task?
How can we get the rate of people contributing to Drupal to keep pace with, or exceed, the rate of adoption of Drupal? How can we get 1 out of 100 people active on drupal.org to contribute?
If we look back at the decreasing percentage of contributors, about 0.5% of users contributed to Drupal 7 core. People are trying harder than ever to get involved with Drupal. Look at the time and the money that we and the people around us are investing in training, conferences and books. Look at how competitive it is to get a slot at DrupalCon and the increasing attendance at local meetups and Drupal user groups. This is one of the coolest open source projects I have ever heard of.
The Double Whammy
- As Drupal gets bigger, if it gets harder to contribute to, our developer community won't keep pace. We need to make it easier to contribute to Drupal.
- We aren't as good as recruiting developers as we are at recruiting people who use Drupal.
Between 2001 and 2006, I was a political organizer. I learned that there is no substitute for one-on-one conversations. If you pit fancy advertising against a well-organized canvass operation, the grass-roots organization wins every single time.
Identifying target markets, reaching out and having one-on-one conversations bring huge dividends. I don't see a similar recruitment going on to bring people into our developer community. When someone walks in the door to a core sprint, they're likely to have a positive experience. If we made a big effort to get people to walk through that door, it could do huge things to grow our numbers.
There's a lot of low-hanging fruit. We already have meetups, camps and conferences. We have all these great opportunities to reach out, with a relatively small additional effort. We have to be deliberate and methodical about making sure that each person gets invited to contribute.
The Experiment: The Drupal Ladder
There are a lot of people who want to contribute, but do not, for various reasons. What if, to lower the barriers, we make a list of all the different ways that a person can contribute to Drupal, and organize it like a ladder. The first few steps are easy, and each consecutive step should be easy to jump to in a bite-size chunk.
We all got excited about this idea, but we needed to develop these How-to materials. We needed to do usability testing for each rung on the ladder and make sure that people were set up for success. Then, we need outreach at Drupal user groups.
I went back to Boston and made the pitch to their user group that we should dedicate one hour of each user group to testing the materials. The group agreed, and over the past several months we've been trying all kinds of different things. We've been digging into the issue queue, breaking up into small groups, unconference-style groups. We've gone through several drafts of the ladder and each lesson, with lots of feedback from Moshe and Angie.
- Install Drupal Locally
- Install git
- Test and clarify core issues
- Test patches
- Write a patch
- Find a core system that interest you and leran about it
- Join an issue team to work on an issue in the queue
- Create an issue team to work on an issue in the queue
- Re-roll patches to apply cleanly to the latest version of Drupal
- Write tests
- Review and review patches
- Help maintain a core component
- Join an initiative (for a set of components)
- Own a project (core component or initiative)
To get started we focused on the first six steps. We learned a lot of things testing the ladder with users. The issue queue can be a major stumbling block: the experience can leave a potential contributor deflated or demoralized. Getting people to feel comfortable in the issue queue is an important and non-trivial first step.
Hopefully with your help, we can develop more lessons for these first six steps.
The next six steps are great for people who want to contribute without making a huge time commitment. They are great for meetups where you want to run a session in less than two hours.
The last three steps are focused on people who want to maintain components on an on-going basis. Meetups are great for recruiting these people on an on-going basis.
We found a lot of things that didn't work, and some things that did work. We have good anecdotal evidence that this is working. We normally have a thin crowd at 6:30, and people show up around 7:30, and people would go out for pizza at 8:30. Once we started doing the Boston Initiative, we saw people arriving early and the room filling up around 6:30. We had a number of people submit patches and join initiatives. We have three concrete reccomendations:
1. Learn Sprints
A learn sprint is a great one-hour activity and it's perfect for people of all levels. It encourages people to identify where they are on the ladder and leap one step. If you set up 60 minutes for your meetup you can get through a 1-hour learn activity.
For people who know all of the stuff in these lessons, step 8 (create issue team) is a great step for them to start working on. There is prep work for running a great issue sprint which can be great for them to work on. Find something where you know how to start, and get them to put that into a spreadsheet.
If you don't have an issue sprint on the calendar, encourage that person to write a new lesson.
2. Issue Sprints
These are a great 2-hour activity. We're pairing people up to dig into issues and work on them. Create or join an issue team. Let's say we have a person named Jane who has agreed to start an issue team. She checks out the issue queue and finds an issue where she knows how to start. She puts her name on a spreadsheet. On the day of the issue queue, Jim wants to get involved in issues but doesn't know where to start. Jim looks for an extra slot and joins Jane, and they work on the issue.
- Select issues before you arrive at the sprint. It can be a real time-suck to identify issues during the sprint.
- Recruit team leaders personally before the sprint. A post on drupal.org won't get enough people to lead teams.
- Feed people at the beginning.
- Issue sprints are a 2-hour activity.
Two is the magic number for Learn Sprints and Issue Sprints.
How do we Grow?
There is the immediate question and the long-term question.
- A place to find lessons/materials
- A place to contrbiute lessons/materials
- A way to track what lessons a user has completed
- A way to package lessons
We found that it's very necessary to have a step for the user to find a core system that interests you and learn about it. We may have a separate ladder for those interested in nodes, versus themes, for example. Learndrupal.org will allow you to create custom ladders.
I believe that with modest amounts of help from large numbers of people, I think we can get to 1% involvement by 2014. If we can get a respectable version of learndrupal.org up by Drupalcon Munich, I really think we can get there. I know that sounds ambitious, if you look at the milestones from Drupalcon to Drupalcon, it seems achievable.
- Between now and Munich: Get 10 use groups to hold issue sprints, get a 1.0 release of learn.drupal.org.
- Between Munich and Portland: 30 groups to hold issue sprints, develop curriculums for D8 initiatives
- Between Portland and DrupalCon EU 2013: Every active user group holds an issue sprint, identify 2 out of 100 active users who can be potential contributors.
- Between DrupalCon EU and DrupalCon US 2014: 1 out of 100 active users contribute.
Q: My group in Madison, WI is not as big. We have maybe 6 people. Do you have suggestions for how to engage them?
A: With six people in your group, if you're the only issue team lead, and you reach out to one other person, and you submit a patch, your group will have a 30% contribution rate, which is way high! I've talked to people today who may be the only person in their group and may be in remote areas very isolated. We now have Google+ hangout and group Skype... perhaps there is a way to match people up online. Pairs can work very well even through other types of communication.