Next steps for keeping things going

Mary,

I'm kind of the "Core Contrib" guy in our DUG (Houston), so I'll share what I've learned.

1. In my experience, there are two obstacles to overcome. The first is people being SCARED to contribute, the "I'm not a Drupal Rockstar Genius" mentality. The second is the "Why should I/What's in it for me?" mentality.

   • Overcoming the first is usually best done by pointing out the wide variety of ways people can contribute. I've been contributing (semi-consistently...I'm SUPPOSED to be in Core Mentoring Hours NOW!) since the first Core Office Hours, but there are a LOT of different ways you can contribute. Sometimes getting people up those first two rungs may be work, but with those two steps done, a lot of the 'standard developer' ways to contribute open up. Testing patches is really just a matter of using Git and following the Core Git instructions. Creating patches (figuring out the proper solution and coding it) is more complex, but start with Novice issues. Or, start with issues that don't REQUIRE code. I've done issues where a comment needed to be changed or a text string was misspelled. But the process of making & submitting a patch to change "proprety" to "property" is basically the same as the process to replace a huge, complex PHP function. That sort of thing helps people get accustomed to going through the steps successfully. Also, what areas does your group have strengths in? HTML? CSS? Javascript? If they're better in those areas than figuring out how to fix stuff in PHP, look for those issues first.
     • I'm also assuming everyone is familiar with how the Issue Queue works and is set up. If not, it's best to spend some time getting everyone familiar with it, so they know how to search for issues that THEY'LL feel comfortable with. THAT may take an entire meeting/session. It's not 'sexy', but you can't WORK on an issue if you can't FIND the right one. There are a LOT of issues! Learning to find stuff YOU want to work on or feel you CAN work on is an important part of the contribution process. I'd say start with issues marked "Novice" first, so everyone can get used to the process.
   • As for the "what's in it for me" crowd, point out the benefits of how much more they can learn about Drupal's internals and how much faster it will make them better site builders/developers/themers if they know how Drupal works internally. If they've got a particular bug they're having problems with, they can start to learn how to fix it. Sometimes making small changes (some issues have a PROPOSED solution, but no one has created a patch...that's more common with the Novice issues) helps you understand how the bigger pieces fit together.

2. Two things with an Issue Sprint.

   • First, I think you need to have people in your group doing an "Issue Walk" (yes, I just made that up) before they sprint. They should be comfortable reading issues, figuring out what needs to be done, and taking the steps to test a patch and submit the results of their testing OR create a patch and submit it. Note those are two different things. More on that in Point 3. So, "walking" through Rungs 3-5 is gonna be necessary before you Sprint through them.
   • Second, if your group isn't comfortable with the Issue Queue, you will have to pick an issue or two for them to work on. Otherwise it's chaos. It'll be a bunch of nerds trying to jump ahead of each other, figuring out something on the fly. I say that in the most LOVING way possible. I'd suggest you find an issue for Rung 4 and another issue for Rung 5 BEFORE the meeting. Then step the group through how to Test a patch & submit the results. After that, step them through the Create/Submit a patch process. Once you've got more people comfortable finding issues in the queue, people can pick their own and maybe work in smaller groups. Depends on the size of your DUG.

3. Your assertion is not QUITE true; the process is more flexible. One person/group doesn't have to go through the ENTIRE process. That's part of the beauty of it. Rungs 4 and 5 can be done independent of each other. You could be someone who ONLY tests patches, NEVER creates them. If you can't code, that's what you do. At the same time, if you CREATED a patch, you can submit it and let someone ELSE test it. If you're a great coder, maybe that's ALL you do. So, you could do an Issue Sprint where you FOCUS on issues that have patches that need testing. That takes up a LOT of time and requires screenshots. But you can do that and that alone. OR you could JUST make the patches and submit them. If you're someone who can't code PHP, you may be able to TEST a patch on one issue, then SUBMIT a patch on another issue that doesn't require PHP (changing a comment, updating a text string, etc). That non-coder could easily climb the next two rungs of the ladder, up to Rung 7, without knowing much code. Or, if they were good with HTML, CSS or Javascript, they could help with THAT kind of code. It all depends on what you know. In short, you could have an Issue Sprint that focuses on JUST Rung 4 or JUST Rung 5, or BOTH Rungs. It's up to you, your group and what skills you have.

4. To use a D&D term, "split the party". If you have people who are ready for Rungs 4-5, let them go. Put the others together and get them up through Rung 2. The Learn Drupal Ladder videos are great for that. Getting them going in the Issue Queue MIGHT be better done by a person, depending on people's backgrounds, but the video may suffice. In a GROUP setting, people can TECHNICALLY skip Rung 3, as long as there's someone there to tell them which issue to work on in Rung 4 or 5. But optimally, you want everyone to know how to find issues in the queue so they can do it on their own if they wish. OR, so they can teach OTHERS.

We've got a pretty small group too. As a final few bits of advice, I'd suggest the following:

• try grouping people by rung, skills or interests, depending on the situation; everyone doesn't need to work on the same issue at the same time
  • If you've got a bunch of people who are doing patch testing, put them together, so everyone can see how that process works
  • If you've got people making patches, put THEM together
  • If you've got HTML/CSS/JS/DB people, but THEM together.
• If you have a chance, do EVERYTHING YOU CAN to try to participate in Core Mentoring Hours. Everything I know about contributing to Core I learned there. xjm and the others there know a LOT more about this than I do and they've got more experience helping people get up to speed. The timezone conversion links will tell you when they are. As I type this, the Monday session ended 11 minutes ago. The Wednesday one is 11am-1pm CDT.

Wow, that was a LOT longer than I thought it would be. I'm working on being more concise. Anyway, I hope there's SOMETHING in all that you'll find helpful. :-)

First, sorry for my "tl;dr" initial response. :-)

Second, if you weren't at Drupalcon Munich, you might want to check out the videos of these two sessions.

• The Drupal Ladder: Resources and activities for meetups to help members learn and contribute
• To Beer Or Not To Beer? Making meetups work

Hope those are helpful.