Last night was the second learn sprint here in DC. Like the first one, we had around 25 people attend, and our gracious hosts at APCO even bought us pizza!
We did things a bit differently this time. At our first sprint, we had several experienced developers who were at or above step 6: Find a core system that interests you and learn about it. Right now, it just has list of the core systems with links into the API documentation; none of us had really did anything with it because it wasn't really clear how to proceed, so instead we spent the time finding issues to prepare for the next (as yet unscheduled) issue sprint. I considered making this event last night a combined sprint, thinking that the newer folks could work through lessons while these experienced devs worked on issues.
Some of us got to talking about it in our IRC channel last week, though, and the fact that we were all at or above that one step without having done anything about it. Someone suggested that we start researching these core systems and learn how they work so that we could give presentations to the group on them. After we got started at the event last night, this idea evolved into writing lessons. Lucky for me, Bryan Hirsch was there again: he always has good ideas, and pointed out that like the User module ladder that was started at Drupalcon, we could build ladders for core systems, starting with basic lessons on usage and working up to the hairier details that none of us quite understand yet.
So that's what we did. There were about 8 of us that wanted to work on lesson writing, and all agreed that none of us understood how Fields work in D7 (and all of us need to, eventually), so we came up with a list of basic lessons that we could write and started a ladder. Right now, the lessons there are stubs and rough outlines, but I'm hoping to keep interest up—and pester those involved—so that the lessons get finished.
In my mind, that was the big win of the night. Most of the attendees were working through lessons, and I don't mean to understate that, but I think it's really important to continue adding lessons so that people don't get frustrated in the middle, where there's less guidance.
Here are some other things I took away from it:
- Stick to learning or coding. Bryan and I talked after the sprint and I mentioned that I still thought a combined learn/issue sprint might be a good idea, and he made a good point: it would be hard to focus on the task of working on an issue when people in the room are working on lessons together and asking you for help. An issue sprint is intended to be more focused on working, while a learn sprint is more focused on the lessons. What we did worked out really well, because most of the group was working through lessons while some of us worked on writing new ones.
- Have a projector or large display available. We didn't have one last night, and I think we could have got off to a better start with one. I asked everyone to go to the ladder while I described what we would be doing, but it was less focused (more chit-chat and such) than it would have been if I could have walked through it quickly on-screen to explain what we would be doing.
- Have a list of things to cover at the beginning. I totally forgot to mention the IRC channel, and while I covered the goals of the initiative, I neglected to explain the difference between learn and issue sprints. Next time, I'm going to have an index card with the list of things to cover at the beginning. Also, this was a good use for the whiteboard in the room: put the IRC channel and Drupal group URL up where everyone can see it, so people who want to can make a note of it later in the evening if they want to get more involved.
- When getting people started, go several steps up. I mentioned in my last recap that Bryan started by asking who didn't have Drupal or git installed, to direct the newest people on how to get started. I did the same thing this time, but found later that a couple people who I thought were working together were just kind of doing their own thing because they didn't know who else was at their level. I got the new people started and got the experienced people working on lesson writing, but the folks in the middle fell through the cracks. Next time, I'll be sure to bring up the ladder on screen and work my way up, to identify who is at what step and help people get connected with others at their level.
- And most important from last night: Lesson writing is great, but have a plan! We were kind of winging it last night, since we weren't quite sure what the experienced devs were going to do. We discussed what system(s) we might want to focus on, then wrote up a list of lessons that we could write, and while we were considering what order to go them in or which ones might be grouped together, I glanced at the time and saw that we were already an hour into the sprint! (which is why those lessons are just stubs and outlines—we didn't have much time to actually write) Still, this was a really valuable learning experience: now I know that before our next learn sprint, I need have a list of lessons ready for some other core systems (and probably some unfinished lessons that were started last night) so that we can get started straight away.
The other important thing here: I'm not going to be shy about asking people to take on specific lessons. We worked as a group to decide what to work on and how, but no one had especially strong feelings about it: everyone was there interested to help in any way they could. Next time, I plan to come with a list of lessons to be written, and just work my way down the list and ask specific people to do specific things, in the interest of getting things going quickly.
We have another learn sprint in two weeks, and plan to get our first issue sprint on the schedule another two weeks after that.