 So welcome, as Kathy was saying, this is the session about sprinting and mentoring and that lot. If you have questions, please write them down or tweet them so that you remember them and ask them at the end of the session because we are going to be kind of switching between and we don't want to like interrupt the flow. Our goals today are to introduce the contribution training resources and all of the things happening at the events to get you ready for the sprints and give you the resources to plan a contribution sprint or training in your own user group or company or Drupal event. Our slides and handout are linked from our session page at portland2003.drupal.org slash node slash 2433. The URLs and resources that we mentioned during the talk are linked from there so you don't have to write them down. You can just go to there and check it out. And then there are also some other resources. If you have one of the postcards that you can pick up at our booth, there will be a QR code on the back that will take you to some more resources as well. So I'm Andrea. I've been working in Drupal for a few years since 2006 and have been working in core and in core mentoring since Denver, which would be a year or so ago. So my name is Jess. I'm XJM on Drupal.org and I sort of started the core contribution mentoring program. I'm also one of the four members on the views and Drupal core initiative team with four co-leads. And finally, I also work in the office of the CTO at Aquia. This is very recently. My job title is code and community strategist. And what that means is that I basically, Dries is my boss and I work on core stuff. So it's actually a full-time job for me now. I'm Addison Berry, add one son on the interwebs. I'm the director of education at Lullabot. And I've been doing a lot of Drupal stuff for a long time. But obviously, like, director of education, my focus is on sort of training and education. And so I've been very involved with the Drupal ladder and the core mentoring stuff in terms of trying to provide underlying training for everybody so that they feel comfortable and confident with what it is that they're trying to get into. So, yeah. That sounds good now. Hi, I'm Kathy Thays. I'm YSCT on Drupal.org. And I work for Compress, which is based in Hamburg, Germany. And I do community contribution as part of my job. And then I blog about community contribution. And I'm a regular mentor in the weekly core mentoring IRC sessions that are every week. And I also organized the Global Sprint weekend that was in March. So, between us, we've led nine sprints in the last year. And Kathy led, organized the Global Sprint as she was saying, which, and then if you look around the room, some of you have picked up your shirts. These are the people who will be mentoring on Friday as well. If you are signed up and you don't have a shirt yet, you should go to the mentoring booth and pick it up. So, today, Jess is going to tell us a little bit soon about the case for core contribution. And Addison will talk about some contribution solutions. And Kathy is going to tell us a little bit more about planning a sprint. And I will tell you what to expect in the sprint this Friday. And then when that's done, we'll do our questions, which we do ask that you wait till the end. Excuse me. That you wait till the end so that we can continue our flow and pace and all that sort of thing, which I am clearly having trouble with. If there are only three things that you get out of the next hour, we hope that you'll feel confident with finding and using resources and the tools to help you plan a successful sprint. It needs to be like maybe how to find the people and how to find the people that you might need to help you along the way. We also think that it would be good if you remembered to plan to deal with development environment issues, which almost always happen when you have a sprint. We don't expect you actually to know how to set up a dev stack on every single different development environment, but we do expect for you to maybe collaborate and anticipate a problem and have potential solutions and we can try to give you some advice on those things. And we would also hope that you would learn to prepare taskless in advance so that when people, and we're going to go into this a lot more later, but it really does help to have reviewed the tasks and be able to help people to choose something that is more suitable to their abilities. But first, let's talk about some basics. So we're all on the same page. What is a sprint actually? Does anyone have like any kind of things that they think a sprint is all about? Anyone? Stand up? Jump up or down? No? Okay. Running fast? What? Running fast? Yes. Running fast is my favorite. What do you see up there? Zoom. Okay. So a sprint is, yes, it's running fast, but it's also when we all get together and in a coding context is when we all get together and we, especially at like an event like this, it's the only time when some of these people can get together in one place and work on things. And so a lot of things get done at once. So it goes fast. And that's I think why it's called a sprint. So what a sprint is, is it is a focused contribution event where people who write code and work on code and write documentation and these sorts of things get together in one place. Is it generally a very fun event? I really very much enjoy it. Andrea is a lot taller than I am. So I'm going to talk a bit about the case for core contribution or the problems that we're actually trying to solve here. And I'd like to start by telling the story of how I actually got involved with Drupal core because I faced some challenges that I think a lot of new contributors do. So two years ago, I was trying to upgrade the text on the access control module to Drupal 7. And I hadn't ever looked at Drupal 7 when I started, but with some help, I was able to get about 80% of the way through it before I got stuck on this one thing. So I talked to some people in IRC and we eventually came to the conclusion that we needed a new alter hook and core. A hook field widget form alter in case anyone is curious. So we're like, okay, we're going to do this. We're going to file a core issue asking for this hook. So we filed the issue. And I kid you not, two hours later, Sunhead created a patch adding the hook to core and then posted on the issue. Two hours later, I came back from lunch and it was there. But the problem was that it was failing tests. And I knew that there was a bug in the patch but I had no idea how to fix it. So by this point, my port of tack was about two weeks late actually for a contract that I had. And I started asking, you know, what can I do to help this patch getting faster? I can't fix it myself. So what can I trade? And people suggested that I should just work on other core issues. So this was two years ago. And my reaction to that was kind of, so I'm not a core developer. I don't know what you expect me to do. I don't know anything about this stuff. Now, as fate would have it, there were actually two things that happened that same week. The first is that checks. Everyone know checks? Bald Hungarian guy, very passionate contributor. He asked an IRC for someone to update a patch just removing one blank line that he'd added by accident. And so I thought, huh, okay, this is a core issue and I know how to do that. So I'm going to do that. So I did it. I downloaded the patch, applied it, made this one small change and then uploaded a new patch. And it was such a tiny ridiculously simple thing. Checks could have, of course, fixed it himself in like 30 seconds flat. But instead, he gave me the opportunity to take that first step and cross that line in my head. The second thing that happened that same week is that the issue summary functionality was deployed on Drupal.org. For anyone who's not familiar, the main post of a Drupal.org issue, the top part before all the comments, is its issue summary. And it can be edited. So the idea is that anyone who's looking at the issue can collaborate to update it, describe what's been discussed and describe the issue's current status. So instead of having to read 50 or 100 comments to figure out what's going on, you just read the summary. By this point, my part of, like I think I mentioned that it was two weeks behind schedule. After a couple of weeks, it was actually RTBC. Someone else fixed it for me after I started doing some of this work. And then it was actually just stuck near the end of a big backlog of other RTBC issues. In summer 2011, there were just two core committers at the time. And it's a lot of work to commit all these patches. So I figured that if I could write issue summaries for those issues, save the core committers' time when they reviewed them, then they'd be able to get to my issue faster. So I started writing issue summaries. I took one issue every day, read the whole thing, researched things in it that I didn't understand, and then tried to write a concise up-to-date summary. And a lot of things actually happened as a result of me writing those summaries, beyond even helping my patch get in faster. The first was that every now and then, I'd come across an issue that I actually knew how to fix. And thanks to the confidence that Checks had given me, I was able to just create patches for those issues myself. Another thing that happened is I actually figured out there were a lot of other Drupalists in a similar situation to me who had an interest in contributing to these issues, these core issues, but had no idea where to start. And issue summaries seemed like a fairly approachable thing, so I started encouraging other people to write issue summaries for issues as well. And that was one of the seeds for the core contribution mentoring program. And finally, completely by accident, I taught myself about core. By reading an issue every single day and researching it and then trying to explain it to other people, I learned a lot. I started writing automated tests for core bugs and fixing more of those bugs myself. I started reviewing other people's code. And it was such an entirely different experience from working on a contributed module. Instead of just hacking away on things until they worked, I actually learned how to do them in the right ways. So that's why I think that core is the best way to learn. You learn a lot about Drupal, first of all. And you interact with more people and get more feedback than you do in Contrib. You're helping other people at the same time. And finally, you also get this ownership in Drupal and this empowerment to solve the problems that you encounter in your job, in your client work, in your volunteer work. So let's look a bit at who contributes to Drupal core. This graph shows the number of contributors to the past five major releases of Drupal from Drupal 4.7 up through Drupal 8. And you can see that the number increases steadily from about 300 contributors in 4.7 to it's actually over 1200 contributors to Drupal 8 now. This graph is about a month old. And Drupal 8 is also not even done yet. So the point is that there's a lot of people in Core to learn from. Something to keep in mind, though, is that Drupal's adoption is actually increasing faster than the number of core contributors. As a percentage of the active accounts on Drupal.org, the ratio of core contributors is actually dropping. So this graph is counting only the active accounts on Drupal.org, people that logged in at least once during the year that each version was released. And we also know that only a tiny, tiny fraction of people who download Drupal ever create an account. The workload isn't evenly distributed either. Most of these 1200 developers are part of what we call the long tail. In fact, half of them have contributed to just one issue each. Just one issue. While this top dozen or so contributors to Drupal 8 core by commit mesh accounts have contributed to hundreds of issues each. Now, it's important to keep in mind the long tail is a very important part of Drupal's development. 25% of the total work that's been done in Drupal 8 has been done by contributors with fewer than 10 patches. On the other hand, though, 50% of the work in Drupal 8 by commit mentions has been done by only 3% of the contributors. And finally, there's a large burden on existing regular contributors. Right now, there's over 7,000 issues filed against Drupal 8 alone. This is even including Drupal 7, which is the active version. And core affects all of us, right? If you use Drupal in your job, if you are a fan of Drupal in any way, the core Drupal project affects you. If we rely on only 30 or 40 people to do most of the work in most of these issues, that's clearly a problem. So nearly half of the open issues in Drupal 8 are active, meaning that there's no patch in the issue yet. And among those active issues, over 500 have zero replies. No one has answered. Also, almost 20% of the issues are sitting at needs review, which means there's a patch in the issue. It might need to be, mark needs work. It might be ready for a core committer to look at it. And probably, I mean, this is 1,300 issues. There's probably a lot of issues in there that are actually, we're at one point, ready to be committed to core. A lot of them probably need some feedback and need to be marked needs work. But the fact of the matter is that a lot of the patches in those issues don't even apply anymore because 900 of them have been sitting with no replies for a month or longer and core moves very quickly in the development version. So there's a few things that need to happen, right? We need to somehow reduce the burden on that very small subset of existing Drupal core contributors. And ideally, recruit more contributors who will do more of the work. We also need to do something about the issues with no replies. And finally, we especially need to close that review gap to make it easier to get good reviews and issues faster. And if you're interested in that topic, by the way, Kathy and Andrea are going to be doing a core conversation on that tomorrow morning. So you should come to that too. It's hard, though, to grow the number of doers in core. And the first steps especially can be difficult like they were for me. Some of you have probably seen this graph before. It's a mock graph of learning curves for different content management systems. And it has Drupal's learning curve represented as this insurmountable cliff. It's a joke, but it might resonate for anyone who's tried to learn core development, especially a couple years back. There are, frankly speaking, barriers to core contribution. And the first, the most obvious, is this, I'm not smart enough thing that I went through. Because of Drupal's like, it's famed complexity, flexibility, and so on. And maybe a bit because of our rock star culture where we glorify certain prolific contributors, it gets to the point where it's hard to see anything that little old me can do. Another thing is that core processes are kind of hard to understand and certainly more rigorous than in contributed modules. And also it's unfortunately not entirely rare for someone to have a bad first experience. Either an unfriendly curt review or worse, no review at all. And it goes back to this review gap that I keep talking about. If someone posts an issue, they spend a bunch of time working at a patch, and then no one responds to their work for months or years, why would they ever try again? And finally, people have difficulty finding the tasks that they can do successfully. There's so many thousands of issues, so much terminology and jargon, and so much to learn. It's hard to know where to start. So our goal in the Contribution Mentoring Initiative is to give everyone a way up this cliff and maybe even round it down to a nice foothill. If you have Drupal site building experience, we want to make contributing back approachable to you. So our solutions focus on helping people find the tasks that they can do and getting the tools to do them. And in Core Mentoring, we've focused on that first part, helping people find the tasks and then guiding them through the contribution process. So this is my big realization back in 2011. One issue, wonderful.org issue, actually includes many different tasks with it. We don't get that far with one Rockstar programmer trying to solve everything by herself. Core is at its best when it's collaborative. So to make it easier to identify the tasks that need to be done in an issue, we added this set of issue tags. Needs manual testing, needs re-roll, needs issue summary updated, and so on. And it'd be totally awesome, by the way, if you get in the habit of adding those issues when you're working on them, we have a list of them that is linked from our session page. We also worked on some documentation in the Drupal.org handbook that explains how to do each of these tasks, sort of demystify the process for new contributors, and I really recommend checking out this section of the Drupal.org handbook if you have the chance after the session is over. And especially for sprint mentors who are helping us on Friday, this is a really good resource. So it's at Drupal.org slash contributor dash tasks, and that link is also in our resources. And then finally, for core mentoring, we picked out the task types that work the best during IRC mentoring and during sprints, and there's a lot of overlap. I would say it's almost always the same list of tasks. And we group them by the tools that you need to do them. So to help people figure out where they can start based on their skill set and previous experience. So the first group, the A tasks in core mentor parlance, just require a user account on Drupal.org. This includes writing issue summaries for issues, like I described, documenting the steps to reproduce an issue, and also simply triusing a reported issue to verify it, to make sure it's filed correctly and look for duplicates. And this, that's where that's almost half of our open active issues, and especially the 500 that have zero replies need that kind of attention. Now it's important to keep in mind that even though these are like the minimum tools, these are not necessarily simple tasks. Writing issue summaries in particular can be very challenging, and I can speak from personal experience and say that the more you put into it, the more you'll get out of it. The B group of tasks require using Git, which is our version control system. This includes small cleanups, like the patch that Chuck's had me update, as well as manually testing things, creating documentation patches, and re-rolling patches so that they apply it to the latest head. And finally, the C group of tasks require programming skill, writing patches, but also writing automated tasks, doing code reviews of other people's patches, and also writing API change notifications for API changes in core. We also built a website to assign people's tasks, because the Drupal.org issue queues, they don't really do what we need them to, they don't expose the right information. So the site is DrupalOfficeHours.org, and it provides a curated list of core issues. And having the site allows us sort of filter the noise of the core queue and helps us match contributors with the tasks that are available to them. It also does something else, which is it records, it pairs each contributor's task with a mentor for that task. So they have someone they can go to, if they forget, or if they're not sure where to go next. Someone they can talk to in IRC and say, hey, this thing that we worked on last Wednesday, I'm having some problems with it, and what should I do next? And we'll explain how to use this website at the BOF following this session. And it's in Room B110, forum communications. The whiteboard is kind of ambiguous, but I think it's supposed to be B110. And at that BOF, we'll be having, we'll be presenting the website in more detail for those of us who are coming to the Friday Sprint to mentor, and we'll explain how to use the website then. So I've mentioned IRC mentoring several times, and we realized recently that we didn't actually have the details about it here, so I just want to cover this briefly. IRC mentoring is also a great way to get practice for sprints. If you're interested in hosting your own sprint at a camp, we often recommend that you try to do mentoring in IRC first to get an idea of the kinds of questions that people will ask you. So it's held in the hash Drupal channel on freedom.net, Drupal's main channel, and anyone can participate in it. All you have to do is show up and say, hey, I'd like to work on core mentoring. And we use the Drupal Office org website to assign tasks to participants. There's two time slots, and in this time zone, it's 7 p.m. on Mondays and 9 a.m. on Wednesdays. So it's really a great way for sprint mentors to prep. So when we were talking about this, we were talking about tasks and tools. I like to think of it sort of as the tasks, the concept of breaking issues into tasks is great. It's sort of like taking a warehouse of food and packaging it up into digestible meals. Like something that a human being could consume. But if you give them a knife and a fork and a pot or something, then that gets even easier for them. So I want to take a look at the actual tools that people really need to have and be familiar with in order to be successful. So this is sort of the knives and forks of Drupal, as it were. Stick with me, stick with me. But... And it's kind of like, you know, stick with me. But... And if you look at this sort of in relation to what Jess was just talking about with those three levels, A, B and C tasks, right? So she said, A task, you have to have a Drupal.org account. To do anything pretty much in any kind of involvement with the community, you have to have that. But also for those A-level tasks, you need a basic familiarity with the issue queue. A lot of people who've never worked in an issue queue are pretty frightened by how that works. And there's all these important people doing things and you might break it. And I don't know what this button does, kind of thing. And so you need at least that kind of baseline, even just to kind of get started working with Core. And then for the others, for B and C, again, you're going to need to have kind of a local development environment and Git so that you can actually start working with the code and working with a Drupal 8 site. So these are sort of the essential things you need. And you'll notice I also have IRC listed on there, which is not necessarily a critical tool to working on a core patch, per se, but it's sort of an essential tool for this community. And not just in terms of I want to work on a patch, I need to, you know, getting help in things like that, but having that engagement and that camaraderie and collaboration, which is where people really learn. And when people come to a sprint and get engaged and they work on an issue and that's great, making sure that they have a way to continue the conversation and collaboration that they start at a physical sprint I think is really, really important. So I consider that an essential tool that everybody really should have when working in the community generally, not just core. So the approach for this. So I started working on this stuff with the Drupal Ladder, which was presented at Denver last year. The Drupal Ladder project was started by Drupal User Group in Boston. And so it's very focused around user groups and how can user groups get themselves involved. And so it has lessons on how to use a lot of these tools that we're talking about and they're designed to be done within the course of a meetup at a local user group. And then there are also resources for actually working on issue sprints, but again, like small, more like meetup size, like a two hour sprint, not a day long or a weekend long sprint or something like that. So this is where I started getting involved with things and it was like these nice little chunked up ways of approaching it and walking people through. You need these tools, you need to understand these concepts and processes before you dive into just, you know, playing in the issue queue because it's really overwhelming to people. So, based on the work that I did with the Drupal Ladder, I created an actual workshop around it that I've done a number of times. It's always free at Drupal Camps and Drupal Cons and such like that. We've done it in a lot of different formats through Drupalize Me. And the idea was to sort of take this concept of these are the tools that people need that they're terrified of or they don't even understand that are out there and to actually walk them through it with a lot of how to get involved with the community presentations and they talk about a lot of things. But at the end of the day, until someone does it, they don't have the confidence that they really get what you're talking about or how to use the tool. So the idea with the workshop is to literally like, okay, everybody's going to get an IRC client and we're going to get on IRC and we're going to talk on IRC together. Yes, you can do it. We're going to get your local development environment installed and you are going to check out Drupal 8 and actually get it running on your local machine right now. And that is a huge step for people to actually getting involved. Because that's a lot of the scary stuff that happens. There's all of these new tools and weird technologies that they've never dealt with and just the mental like overhead of trying to figure that out just to even get started is a bit much. So, we have the community tools workshop and I love going to events and doing them particularly in relation to sprints. We do the workshop in the morning and then get everybody set up and then they can sprint in the afternoon and actually apply everything that they've just learned in the workshop. But obviously I can't be everywhere. My team at Drupal is me can't travel all over the planet to do this. So we've made sort of our notes and our curriculum and all of our resources available for free at that URL, drupalizeme slash community tools. We'll be continuing to improve on it and fill it out more. But it's like in the sense of there are two important things about this. One is if you're mentoring, particularly on this Friday, but if you're mentoring at any other event, you should be familiar with the materials in the workshop because it's kind of a baseline and you should understand what tools people are being taught and you should be familiar with them as well. And particularly when we're talking about different environments and you have people we have videos that show you what it looks like to install WAMP on Windows. So even if you don't have it, you don't have windows you don't know what's going on. If you can get through that video and understand this is the screens, this is the kind of stuff that people deal with. So when you're in a mentoring situation and someone's on Windows, you don't freak out. So the information is just sort of there for you to sort of understand and just check in make sure that you have the basics in place. But on the other hand also I wouldn't really encourage people you can go back and teach these workshops yourself in your local community your camps and that kind of a thing. And I totally am willing to help support that in any way that we can remotely as well. A lot of the information in the curriculum has videos associated with it. So if you really don't want to stand up and teach people by talking to them from a podium you can play a video and then have everybody sit around and work through it together and talk about it. So if you're really terrified you can even do it that way. But I want to make sure that everybody knows that that's sort of out there. We're going to be doing the workshop this Friday in the morning so if you're interested in what's going on with that I know when people were signing up for mentorship and you wanted to be involved with you can get more information about that then. But at any point during this week if you want to talk to me specifically about this curriculum and what the workshop's like and how you could use that curriculum for yourself in other circumstances please track me down and I would love to talk to you about it. So I'm going to talk about what it takes to plan a sprint in terms of location and publicity and mentors and scheduling tasks in advance and also planning to do reviews after a session. And depending on the size of a sprint you have to do a lot of planning or a little bit of planning. For example the four of us together with the Drupal Association we've been planning Friday's sprint since like January. But a smaller sprint needs a lot less planning so when you go home and organize your own small local sprint you don't have to do quite that much. And so what we're going to talk about now are just the essentials the minimum that you'll want to do. So you can host a sprint and be the mentor at your sprint. And the question is like will you need any more mentors besides yourself. So the way to know that is to estimate the number of people who might attend your sprint is to guess that one mentor per eight participants is a really good ratio. That keeps the mentors busy but not too busy. So if you are guessing that you might have more than eight people come to your sprint you might run a recruit an additional mentor to help you out. On the day of your sprint if you get a better turnout than you were expecting you don't need to worry though about the amount of crowd that came to your sprint and they will help you mentor on that day. So like for example if somebody at your sprint is having trouble with Git you just ask everybody there like does anybody know about Git somebody will know more and you pair that person up with the person who's having trouble and ask them to help them and move and sit next to them and then wow Bamo you have another mentor at your sprint. So it's really nice of that person who didn't know they were going to be mentoring to see that they really have a ton of skills that they can use to help somebody else and it's really empowering for that new mentor and it's really rewarding for you as the sprint organizer to mentor other mentors. When you're thinking about location you want to make sure that your location has Wi-Fi and outlet strips and food. If you don't have food at your sprint people will leave to go get lunch and everybody will lose an hour and a half of sprint time. So there's some ways of dealing with that. One simple way is to get a menu take everybody's order have one person go get the food and everybody split the cost so that way most people stay focused at the sprint. Another option is to plan ahead of time and get a sponsor for food. I was picking a location for my local sprint that was part of the global sprint weekend that was in March I talked to the location ahead of time and I asked them if they had Wi-Fi and they did so I kept talking to them and then I asked them if they had outlet strips they didn't which was fine I have a ton of my basement I'll bring them and I planned ahead for food and got a sponsor and then the day before the sprint I went by the location and it was a meeting room that doubled as a yoga studio and the secretary there was chatting and they were like what are you using the room for and then she's like would you like tables I'm just picturing everybody sprinting on the floor on yoga mats and I'm like yes please could we have some tables and she's like no problem but if she hadn't asked me we would have shown up on the sprint day and there wouldn't have been any tables so the idea is when you are planning your sprint just ask them ahead of time for everything you think you might need we ordered lunch and it was only about $80 to feed more than 12 of us so it was really reasonable and I came in below my sponsorship budget this is a picture of the two tables two rectangular tables and you can see lunches sprinkled around on the table and we are on both sides of rectangular tables facing each other that or round tables works really well to encourage the sprinters to interact with each other so you are planning the sprint you're putting in work into that you want to get people to come you want to publicize your event Drupacall.com is an independent website that has real time event information for Drupal events all around the world and it's Drupacall like Tropical but for Drupal and I like to think about it comes from Drupacall I like to think about it as a pun I like to think about it as Tropical like if you want to plan your vacation there's palm trees man it's totally tropical so if you want to plan your vacation you're like I would like to go to Switzerland you can look for an event in Switzerland and tell your boss you really need to go so this is an image a sample image of what that map looks like the sprint pins are purple so if you're planning a sprint you're like well how do I get my sprint my little sprint to show up on this map that all these Drupal people from all around the world are looking at when they're trying to figure out where to go for their next event and it's really easy to get your purple sprint pin to show up on this map you go on to groups.drupal.org and you find your local group there and you make an event anybody that's a member of a group can make an event and as soon as you make an event this reads from and your event will show up on this map so it's like totally easy additionally to get people to come to your sprint or instead you can make an event on meetup.com and the nice thing about that is people who aren't like really deep into Drupal or aren't paying attention to groups.drupal.org they might find it on meetup so that's nice too when you're publicizing and spreading word about your sprint you and you're making announcements you want to include in your announcement who is welcome at the sprint usually that's anybody with site building experience and also more experienced contributors they're welcome too in your publicity remind your attendees your potential attendees to bring with them whatever they need to bring like their laptops some people will come to their first sprint with like nothing it's important to mention bring your laptop to the sprint we're looking forward to you coming and then also bring anything else you want them to bring if you need extra outlet strips or if you want them to bring snacks include that in your announcements like everybody should come and you should bring your laptop on the day of your sprint so that's helpful getting set up to work on drupal 8 they're gonna have trouble we know that from past camps and cons that although max are popular they're not the only flavor of development environment and the other ones are equally popular so you want to find people at your sprint or plan ahead to ask some people to come to your sprint who are familiar with other environments than the ones that you have people there who have experience with each max linux and windows you it's really helpful to encourage your participants to set up their development environments before they come to the sprint so in a reminder before the sprint you can send them a note and say hey we're really glad you're coming to the sprint be sure and set up your development environment ahead of time and here is a link that will help you do that if you send them a reminder that means on the sprint day they can be a lot more productive because they will have gotten some of the setup out of the way ahead of time we have a link to development setup help resource that's from our session page or you can write your own to customize it to your group so I'm saying like they need to set up their development ahead of time what is a development environment it's all those tools that we were talking about it's an amp stack like a patching mysql and php but it's also those other things so they need at a minimum a shell an editor an irc client a git and dreaditor as a minimum they just need a web browser an account on d.o and dreaditor helps to make d.o usable for contributing irc I'm with adi on this it's really useful at the sprint to get them talking and then when they go home they can continue to use irc to continue to communicate with the community so that's like the minimum set some tasks can be done with just that minimum set a drupal.org account like what tasks summaries right so what you want to do when you're planning your sprint is you want to be careful that you select tasks ahead of time and that you select a few of them that can be done with just a drupal.org account something else that will really help you deal with the development environment problem is simply test.me with simply test.me people can do more than just that they can test patches and they can reproduce steps to test a patch and add those into the issue summaries so they can test patches on drupal 8 without any web server on their local computer just by using simply test.me for other tasks though you really do need a web server if you're going to make a patch people at our sprint on Friday and at your sprint are welcome to use any development environment they already have set up but if somebody's coming and they don't have anything set up yet we recommend that people set up an amp stack like MAMP or WAMP and we have a lot of experience with getting new contributors set up and when they set up first their web server and their PHP that helps eliminate some confusion for them and especially new people so they can set up a hello.html file and just make sure that patch is working then they can use get and get drupal and install it and they can see the total separation there between what is the web server and what does drupal do and for some people that's a barrier so new people we recommend setting up an amp stack this is a table of task types that Jess talked about earlier and they're organized by the tools needed to do them it's at www.drupalofficehours.org slash task and the link is in our resources this table is helpful when you're selecting tasks in advance and selecting tasks in advance of your sprint is the bare minimum thing that you should do so if you don't do any of the other stuff that I said do this, select your tasks in advance but not too far in advance about three days in advance is good because if you do too far in advance by the time of your sprint the tasks may not be relevant anymore be sure and pick a few tasks in each tool set www.drupal.org get and programming and you can make your own table if you want, it's helpful to have the information that this table has which is the task type a way to find tasks like that so either a d.o search for certain issues that have a status or issues that have a needs tag on them and then also instructions for how to complete that task and we have the contributor task documentation pages that have instructions to tell people how to do a re-roll or how to update an issue summary so those instructions are really helpful for your sprint participants so they know how to do the thing that we find for them to do on the day of your sprint you want to tell people what to do when they enter the room so this is a to-do list on a whiteboard and it's very typical of what gets posted on the sprint day it has instructions for people to create an account on d.o add their user names to a google doc install a web stack install git clone and install drupal 8 get a task from a mentor assign the issue to themselves tag it with the sprint tag and it has the wireless password and it has a password and it has a password but in general on the day of your sprint you want to make sure that you have signs so that people know they're in the right place for the sprint welcome each person who comes and introduce yourself post a link to instructions we have a link to some generic sprint instructions from our resources or you can write up your own instructions get to know the attendees ask them questions and you can make a good match for them take pictures and write down who comes to your sprint feedback is really important for new contributors and getting them to stick around a new contributor if they don't get any feedback feels like their work is going into a black hole contributors who get fast feedback are going to feel like their work is really valued often mentors at a sprint the sprint organizers will make a special effort to make sure that any new contributor who came to their sprint and did something gets a quick review and if there are too many people they recruit people to help them do reviews this is a screenshot of the task review page that's on the drupalofficehours.org site at slash tasks dash review and it's a handy tool to use if you used the core drupalofficehours task selection tool but even if you just wrote down your own tasks that you thought were good you're going to want to keep track of similar information so you'll write down the task that people did who worked on it the participant and also the issue number that the task was in if they tagged tasks that they worked on with a sprint tag you can use drupal.org to generate a list of issues that were worked on for you we have a review test scheduled for one week later on Saturday and Sunday June 1st and 2nd in IRC in pound drupal dash contribute we will tweet about it so you will hear about it and then you can come and help us review hundreds of tasks from Friday we also have a core convo tomorrow where Andrea and I are going to talk about how to get reviews and also how to give good reviews how to review patches and how to get reviews on your patches which might be of interest but when you do a review fast for your sprint it's a little bit different than that also because you're not always reviewing patches one of the tasks that a sprint participant might do is update an issue summary so later as a sprint mentor you make sure that somebody looked at that and gave that person feedback on how they did did they update the issue summary what was great about what they did next time they updated issue summary what should they do differently so you need a list of tasks that they did so you can give each person feedback on that general idea of a task awesome thanks Kathy so Kathy and Steph I know she said that we've all been working on getting the sprints ready for Friday mostly Kathy and Steph have really rocked the heck out of this the planning and that's she's amazing at that but there's sorry there's really a whole lot left to do and that's where you guys come in so immediately following this when we're done here there is a a task entry bof in B110 we also tomorrow we have an environment bof and do we have a room for that yet well just ask afterwards and we will tell you where to go we could use some people that can help new contributors get their dev environments set up so that then they're ready on Friday when it's time to go on Thursday there is another task entry bof which is at 1145 come see us about the location and on Friday of course we have the workshop and the mentored sprints and then everyone who is a mentor at the sprints is absolutely welcome and encouraged to join us for the mentor dinner afterwards there are several other things that would be very interesting for you to go see and do this week come and see us for these you can get them at the mentor booth in the exhibit hall or you can come get a few from us when the session is done and then of course see Kathy for the dates and times I think she already listed those for the review test in IRC so what are we expecting to do on Sprint Day this is going to be one of the biggest events for sprints ever we're very excited about it we expect to have 700 sprinters it's going to do the Friday Friday Friday Friday Friday okay sorry so the morning mentors will need to show up early this is where you are now if you when the time comes you will be over there which is kind of around the hall and down there's the first hallway and we'll kind of get there what we'll find is that some of the people who show up they want to be trained they want someone to talk to them at them they want Addie to be amazing and do what she does these are the people that may not even have their development environment set up and they're maybe not as familiar with the community tools there are going to be some sprinters who just want somebody coach them to maybe help them find something to do or help them to finish a task and there will be some sprinters who just want cookies or water or whatever it is that they need wifi and Pringles there's really not much more you need to get some awesome stuff done right so that means that we have three kinds of sprints three audiences that we'll be addressing the first people as I said those are going to be the ones that are in Addie's workshop the second group these are the people that are the sprints and those will be in another room and then there will be the main sprints where all of the twigs, sprints and is there a views sprints? twig, views, web services lots of stuff look on the website there's a ton of them and those will be in the main sprint room the community tools workshop and then room C 123 and 124 the get involved with core sprint is in B1 17 through 119 that'll be like the main mentored sprint and then the contribution sprints where Chex and Jess will be those will be in 105 and 106 113 through 116 and if there is space the other ones will be in 105 and 106 you can expect to have a morning intro I'll be doing that I'll be doing a morning intro we'll talk a little bit about the contribution tools and see we'll probably divide people off so that we know we figure out between those two groups the workshop and which ones can move on to the other to kind of doing some mentored work already and then we obviously we have the workshop and the mentored sprint at the same time where we will expect the mentored Kathy has a better word for this participants sprint participants because mentor manatees so the participants we'll want them to work in pairs because it helps people to learn when they explain it to someone else and when they work in pairs we find that people are a little more successful I'm sorry if I'm trying to speed through it we're running out of time and then once the workshop is done then we'll probably do some environment setup assistance and that sort of thing of course there's lunch and then we'll kind of go back and do some more maybe more dev environment setup and more mentoring and then we'll have some live reviews are you doing the reviews this time? Jess will do a live review and someone someone who might be Jess's boss will be doing a live core commit participants has worked on will be in core before the end of the day it's very exciting and it's very rewarding for the participants to see this kind of thing happening so you know what to do to plan your own sprint what's happening this week and on Friday and we're going to go through a few things to do it well this is a picture from a Drupalcon sprint and it shows one of the best things about a sprint which is two people sitting next to each other collaborating and as a sprint organizer you might be thinking that you have to do everything yourself and know the answers to everything but that's not true you don't have to solve every problem by yourself other mentors and attendees will help you find answers while you're mentoring participants will think that you are magically brilliant but you want to show them that they in fact can do what you can do so when you mentor expose your reasoning by asking participants questions and then revealing your process as you find the answers so show them what resources you access and they will see that it's not magic it's knowing where to find the answers and this really builds their confidence that they will be able to do it when you're not there matching a task to a participant will leave the participants smiling and mentors help participants find tasks to work on and we do that by assessing their skills and making sure that we pick tasks that are good matches for their skills we want to give participants tasks simple tasks that they can succeed at because that will keep them coming back be really nice treat people like peers and remember that you were once new too and while you're at the sprint and you're walking around mentoring ask people how things are going because they might be heads down working or they could be being shy of asking questions and when you approach them it gives them a chance to mention what they're stuck on and if a task isn't working for them be sure they know it's totally okay to have you help them pick another task what's next for you guys your mission is to lead a sprint you can help on Friday or you can go home and do it and when you do we want to know you should tell us we're proud of you we want to know what you're doing but also if you need any help we can help you and after you lead a sprint give us some feedback and let us know what worked for you because then we incorporate that and we tell other people that organizers have an even better experience we want you to remember these three things to prepare a task list in advance ask your participants to set up their development environment ahead of time and use the planning tools that we have like the Drupal office hours follow Drupal mentoring and we will tweet about important things to remind you and our session page portland2013.drupal.org slash node slash 2433 has a link to resources and URLs that we've mentioned in the talk and should have a way to evaluate our session they're working on making that happen we have the extra postcards up here so you can remember what to go to picture yourself leading a sprint mentoring at the sprint and we have the boff right after this which is in B110 where we are really happy to answer any questions that anybody has we do have like three minutes so if anybody has a question come up to the mic here so we can hear you and also it gets recorded that leads to a question if you set up your sprint in a more corporate-ish environment the wireless network will likely or often block IRC so if that happens what do you guys generally do it drops alternatively if you're in a corporate environment in theory you are doing that maybe with permission from the people who maybe manage the network and they could poke a hole in it for you to do that which I mean the IRC port is not it's one port if you don't have it you don't have it and I feel your pain on that one because I actually was not able to use IRC at my office for several years in Drupal and that delayed my contributions an announcement that's related to the topic the Drupal ladder which Addy mentioned is a great tool for your sprints at home and certainly also for getting people set up for Friday's sprint when you meet them say on the street and you just decide you want to help them get set up there will be a sprint an introduction on the Drupal ladder tomorrow in the lunch area at 3.15 thank you we have time for one more question can you refresh us again real quick on publicizing your own sprint hosting so to publicize your own sprint the first step is to go to groups.drupal.org find your local group like for example I live in Oak Park which is a small town outside Chicago so the local group that I post my event in is the Chicago group and because I'm a member of that group I get a create event link when I go to groups.drupal.org that tells people who are part of that group and who read their group who read their email about it but it also makes the pin show up on drupal.com and then meetup.com is another way of spreading words so we're going to wrap up and we will answer any questions afterwards and at the BOF which is in B110 so I'm really glad that you guys came thank you very much