Get more contributors! – Lessons from the Drupal Ladder – The problem



Get more contributors! – Lessons from the Drupal Ladder – The problem

0 0


get-more-contributors

Slides for "Get more contributors: Lessons from the Drupal Ladder" talk at OS Bridge 2014.

On Github fureigh / get-more-contributors

Get more contributors!

Lessons from the Drupal Ladder

Fureigh / @fureigh

Hi, I'm Fureigh.

(Obligatory introductory slide)

  • @fureigh
  • Code for America Fellow — apply!
  • Started NYC’s Drupal Ladder meetups
Hi, my name is Fureigh, my pronouns are they/their/them, and this year I’m a Code for America fellow working with the City of Long Beach, California in the area of healthcare. Fellowship applications are open through July 15th; come talk to me afterward if you’re interested in getting paid to work on open source projects to help solve cities’ problems.

Ceci n'est pas une Drupal talk

  • Get more people involved in your project
  • Increase the diversity of the group of people doing (and getting credit for) higher-status tasks

But I’m here today because at the beginning of last year, I started organizing skill-building meetups in New York as a longtime Drupal developer who wanted to learn more and start contributing to core myself.

This is not a Drupal talk. It’s using the Drupal Ladder as a case study about how structured systems for step-by-step skill-building and engagement can, especially when coupled with a community element, help your project. It can be a secret weapon for getting more people involved and 2) increasing the diversity of the group of people doing (and getting credit for) higher-status tasks.

TL;DL:

Offering a structured approach for step-by-step skill-building can combat imposter syndrome and build community, thereby increasing the number and diversity of your project’s contributors.

And if this is too long for you to listen, here's my main point:

The problem

With great popularity comes great responsibility.

Drupal is the second most popular content management system in the world right now. It runs whitehouse.gov, major media sites like the Economist and the Weather Channel, and nonprofit sites from small community organizations all the way up to the Red Cross and Amnesty International.

But as the number of Drupal sites and users exploded, the pool of core contributors didn’t keep pace. And in 2011, there started to be a lot of public conversation about burnout and burnout prevention.

http://www.codem0nk3y.com/2012/04/what-bugs-me-about-modx-and-why/cms-learning-curve/ Now, Drupal has had a famously challenging learning curve. And that's changing, we're working on it. But even with a steep learning curve, there's room to make progress.
“There are a small number of people who do the lion’s share of the work on core Drupal. As Drupal’s popularity sky-rockets, so does the volume of issues and sense of urgency for problems to get solved fast. But as Drupal’s code base becomes more complex, the learning curve for contributing to Drupal core gets steeper. Issues are being created faster than they can be resolved. And the core core team feels exhausted and burned out. Drupal needs more people to contribute to core.” —bryanhirsch, October 5, 2011 Anybody experienced anything like this in your own projects?

Enter the Drupal Ladder

or “The Boston Initiative”

(Thanks, @bryanhirsch!)

It was initially known as the “Boston Initiative,” because Bryan Hirsch, now at the White House, led its development at the Boston Drupal Meetup.

Initial proposal

Bryan's initial proposal, based on conversation at DrupalCon London, laid out a few key components:

Key components

  • A list of all the ways people contribute to Drupal core
  • Organizing that list into steps
  • A writeup of clear instructions for each step; make it easy to get up and running in 15 to 30 minutes
  • Explicit engagement of existing community infrastructure (Drupal user groups!)
  • A list of all the ways people contribute to Drupal core. Including rewriting issues so they’re clearer so they’re closer to being workable.
  • Organizing that list into steps. “The first few steps are easy for anyone, minimal knowledge of Drupal required. As you climb higher up the ladder, taking any consecutive step up the ladder is within reach, as long as you’ve taken the first steps.”
  • A writeup of clear instructions for each step that makes it easy to get up and running in 15 to 30 minutes, so people can make a meaningful contribution within an hour or two.
  • Explicit engagement of existing community infrastructure: Drupal user groups!
  • (Plus communication tools, community infrastructure (drupalladder.org and contact people), explicit invitation for Drupal user group leaders to implement this.)

To recap:

  • A series of HOWTOs people can use by themselves
  • Leverage existing community groups to 1) get work done and 2) build capacity
So let’s note: the Drupal Ladder is a series of HOWTOs that people can use by themselves, but from the start, the idea was to leverage existing community groups to get work done and build capacity.

Which brings us to New York

or, "So I started a Meetup"

I’d been out of town a lot touring with the band I was in at the time, and I knew we were going to be back for more of the year than we usually were. I’ve been in the Drupal community since 2006, 2007, and I wanted to give back to Drupal and to the local community that’s been so important to me. I also wanted to finally start contributing to core.

Which brings us to New York

or, "So I started a Meetup"

I’d been out of town a lot touring with the band I was in at the time, and I knew we were going to be back for more of the year than we usually were. I’ve been in the Drupal community since 2006, 2007, and I wanted to give back to Drupal and to the local community that’s been so important to me. I also wanted to finally start contributing to core. [explain core vs. contrib?]

HOWTO:

Environmental scan (see what's already being done) Organize the thing; start somewhere Recruit, recruit, recruit

Drupal-Ladder-specific groups had started in other cities but there wasn’t yet one in New York. I reached out to the designated Drupal Ladder contact person and to the people running New York’s Drupal meetup group and they told me to run with it.

So I arranged a space through New York Drupal Meetup contacts, posted an event to groups.drupal.org, and pitched the Ladder at the first New York Drupal Meetup of the year.

Know your motivation

“Is your New Year’s resolution to learn more about Drupal 8? How about to give back to the Drupal community?”

I blatantly capitalized on people’s New Year’s resolutions.

Outreach is crucial

“If you build it, they will come” is a flawed design pattern.

I used the following tactics, with a hat tip to community organizing:

Tactics

  • One-on-one outreach to get around the bystander effect and imposter syndrome (but don't be creepy)
  • Promote through existing community channels
  • One-on-one outreach to get around the bystander effect and imposter syndrome: (but don’t be creepy. respect people’s consent.)
    • used people’s contact forms on drupal.org
    • direct messages on Twitter
    • one-on-one emails
  • Promoted through existing channels
    • Drupal Meetup Group
    • Community Twitter accounts
    • We didn’t start a separate group on groups.drupal.org. So every time I posted a new meetup event, I posted it as a comment on the last one to make sure people who RSVPed for the previous event would know about it. or: “Post the next one to people who went to the last one”

Tips

  • Assume the person reading it is new. Be welcoming and avoid jargon.
  • Be responsive. Be the nicest guy in the room.
  • Do your best to make it a positive experience for everyone.
(Areas that do this well: anti-oppression trainings, effective volunteer management, community organizing.)
  • No matter how many events you’ve had, always assume the person reading it is new and make sure they see that they’d be welcome and able to tap in. Avoid jargon. Especially, with all due respect, if your event is called a “Drupal Ladder.”
  • When people say they can’t make it, respond. When people ask questions, respond. Be responsive. Be the nicest guy in the room, even if that room is the internet.
  • And do your best to make the event a positive experience for everyone so they’ll want to stay in the community.

Challenges

A few challenges I noticed over the course of the year:

Trauma around school/structured learning

Many people have ____.

And people have trauma around learning environments. People have to learn how to learn, not everybody feels equally safe experimenting or not immediately knowing something, and people have different levels of experience and comfort with self-directed learning or charting their own course, pun not intended.

I have bad memories of being made to slowly click through follow-the-bouncing-ball-style computer classes as a kid, so it’s deeply important to me to not bore people. It’s also important to me that people not feel lost.

So the same way I might send an agenda around before a meeting and invite people to propose changes, I tried to make space to ascertain consent. Today I’m thinking we’ll go through lesson X on the screen in the other room for about 45 minutes, then put it into practice for the next hour, then have a quick go-round at the end. How does that sound? Is there anything else someone wants to do? If you get bored, please feel empowered to dive right in or go do something else. Encouraging people to follow their interests.

Imposter syndrome

and baggage around non-code contributions

In the words of the Geek Feminism Wiki:

“Impostor syndrome describes a situation where someone feels like an impostor or fraud because they think that their accomplishments are nowhere near as good as those of the people around them. Usually, their accomplishments are just as good, and the person is applying an unfairly high standard to themself (and not to others). It's especially common in fields where people's work is constantly under review by talented peers, such as academia or Open Source Software.” People often have internalized stuff about that, which you have to specifically address in recruiting participants and continue to reinforce throughout.

Explicit invitations

Here's an example I like from my friend and current teammate Molly McLeod. It's for a civic hackathon but forkable for other things.
And here's the page for the "Get Involved with Core" sprint at DrupalCon Portland last year. Note the "who it's for" section. ANYONE WITH DRUPAL SITE BUILDING EXPERIENCE.

All learning, no less tangible contribution

Get in the water

The Drupal Ladder suggests having “learn sprints” and “issue sprints,” but we did half-and-half. Frankly, this was partly because I didn’t want people to show up only for the learn sprints and not the issue sprints.

Even so, sometimes the check-outs would reveal that people were learning a lot but not putting it into practice… at least not for Drupal core, which was ostensibly the goal.

Some of this is about making sure people have clear tasks that they feel are well-matched to them. Some is about smiling and encouraging someone to try it Right Now. And some is about event structure. Having a standup-style “what will you work on for the next hour?” could have been helpful, but mostly it seemed to be about helping people stay focused on Actually Trying A Thing instead of reading more and more about it.

Start building capacity right away

Community organizers [and others?] talk about a “ladder of engagement.” You want to start moving people up right away so when your life takes other turns or you catch a cold or whatever, that doesn’t mean a dozen people don’t get to learn.

This is mostly about individual volunteers, but also include back-up venues, sponsors, and other forms of capacity

Community documentation can help too. Build scaffolding for new leaders.

Institutional memory

Document and communicate

Sign-in sheet Take pictures (with consent) and post write-ups

Have a sign-in sheet so you can know who’s coming regularly, how attendance numbers are doing, what seems to affect attendance.
For instance, though people had been saying they wanted to meet every two weeks, at one point there was such a wealth of activities in the New York Drupal community that the Ladder was at the tail end of three weekends of events and attendance plummeted. (It was also the weekend before Passover and some folks had house cleaning to do.) Keeping some sense of the numbers meant I could say, “Hey, we had this many people before and last week only three showed up. [did gently and as non-shamingly as possible survey people about what happened] Let’s change our frequency for a bit and see how that goes.

Take pictures (with consent)! Post write-ups of what you did and what people learned! Post them so people can see how much fun you’re having!

Outcomes for participants

  • Everyone made their first contributions to Drupal itself.
  • Increased skills
  • Some participants landed their first professional Drupal jobs
  • Network of Drupal friends
  • Confidence --> more contributions
  • Status that comes with contributing
Everyone made their first contributions to Drupal itself. Increased skills: got comfortable with the popular version control system Git, learned to use the Drupal community’s tools (the issue queue, patches, and so on). Some participants landed their first professional Drupal jobs. Built community and a network. (or “Network of Drupal friends”) Confidence: Many said the step-by-step approach and the in-person meetings helped them feel more confident that they had something to contribute. That makes people more likely to keep contributing. And also, let’s be real, the status that comes with contributing.

Outcomes for local community

Increased capacity: – Expanded ecosystem – People who show up completely new to Drupal meet friendly faces and go to the regular Drupal meetup – Participants have stepped up into Camp organizing roles – Another piece of public culture of learning, building and contributing Plus, local pride.

Outcomes for Drupal project

Code contributions Capacity building: some have also mentored new contributors at larger sprints (at DrupalCon Increased diversity of group making and getting credit for contributions

Benefits of a step-by-step process:

  • Clear path to success for participants
  • ...and for event organizers
  • Shared language and shared experiences can help build community
  • People can work on their own time
  • There’s a clear path to success.
    • Once you’ve done these steps, you’ve used the skill! You’ve tried the thing! You can do it!
  • It’s easy for someone to pick up the curriculum, as it were, and run an event.
    • Reusable components. (And since it’s an open source project, any time someone ran into issues it was an example of how you can scratch your own itch and contribute value by fixing something you discovered was missing/confusing/outdated/incorrect.)
  • Shared language and shared experience can help build community.
  • People can work through more at their own pace. Some liked to rehearse before coming to the Ladder. Some would do the whole “learn sprint” at home.

Benefits of the community element:

  • You don't have to reinvent the outreach wheel
  • Accountability and motivation to keep going
  • More experienced people can help newer people
  • Tricks of the trade; we learn more from each other in person than the curriculum covers
  • Community members get to see what it’s like to work with/around each other
  • Networking --> economic empowerment
  • Model and learn good practices
  • Fun! (gasp)
  • Lots of “hey, nice command line trick!” and “what text editor are you using?” and “I had that problem with my dev environment too, then I…”
  • Community members get a chance to see what it’s like to work with/around each other; useful for gauging possible work referrals, etc.
  • It’s an informal networking event; job opportunities come up, people find people to work for/with them
  • Opportunities to model and learn good practices
  • Last but not least, some people think this is fun

Benefits to the project itself:

  • The work itself: patches submitted, reviewed, issues cleaned up, etc.
  • More contributors with more skills
  • More people interested in and getting a chance to mentor and teach each other
  • Increased capacity in general!
  • —> decreased risk of burnout overall.

Increase your contributor pool

A structured approach for step-by-step skill-building can be a secret weapon for 1) getting more people involved and 2) increasing the diversity of the group of people doing (and getting credit for) higher-status tasks. A community element can be helpful for continued motivation, encouragement, learning and networking.

The Ladder model is a way your open source project can build community, combat imposter syndrome and encourage new contributors.

In the Drupal community, there have been more than 2x as many people mentioned in commit messages in Drupal 8 — which is not yet out — as there were in Drupal 7.

A structured approach for step-by-step skill-building can be a secret weapon for 1) getting more people involved and 2) increasing the diversity of the group of people doing (and getting credit for) higher-status tasks. A community element can be helpful for continued motivation, encouragement, learning and networking.

Thanks so much to everyone who’s worked on the Drupal Ladder and other mentoring initiatives to get more people involved in core.

Q&A+

Fureigh / @fureigh

  • Now I’d like to have a Q&A, but I also really want to learn from everyone who’s here and interested in this.
  • What do you think? What are other structured approaches with which you’ve worked? Let’s leverage the expertise of people in the room.