 So the topic of our next half core conversation is New Contributors and Core Initiatives. I'm XJM and this is Yes CT and you know her already because she's been talking to you. If you don't know me, my name is Jess but XJM is fine. I work for the Office of the CTO at Acquia. I'm one of the four co-leads for the Views and Tribal Core Initiative and I started the Core Mentoring Program. So I loved, I wish I could have been at their talk but I had another thing trade you. Okay. We have two mics. This is, this is very clever. So this session is about, this session is directed at leaders in the Drupal community who are initiative leads or might become initiative leads in the future. So if you're a new contributor and you're interested in contributing to a core initiative, you're welcome to hang out and listen and you'll have to forgive us our snark as we tease the initiative leads. We're going to be very frank but what you can do that's even better is come to the sprint on Friday because there will be lots of, first of all, initiative issues in the mentored sprint if you're not sure how to get involved and the initiative leads will also, almost all of them will be there so that's something you can do too. So if you're welcome to hang out or, you know, we're not offended if you go. So Kathy and I are both core mentors and we're both core initiative contributors and the other day we decided that Drupal Core doesn't have enough initiatives and it doesn't have enough acronyms. So we will bring to you the new contributors in core initiatives initiative and that's N-C-C-I and it's almost a Roman numeral. So let's tell you about what new contributors have that you, hypothetical initiative leads, don't have. They have time. You're busy and I'm busy and the top challenge that I've heard from every single initiative lead to do these bi-weekly scrum calls is that they don't have enough reliable resources. They can't find the people to do the things that they need them to do when they need them to do them. And when I was a new contributor I had loads of time. I did things like, well, I ate dinner without having my laptop open and a dreaded or window open. I actually also socialized and there's a whole group of people out there in the world who haven't already come to the point where Drupal has taken over their entire lives and this is an opportunity that we need to seize. So if you're in an initiative lead and we're thinking about what new contributors have that you don't have, one thing they have is a fresh perspective and they have a lot of skills but they can look at the work that people in your initiative have done with new eyes. So I hear a lot of people who contribute a lot to Drupal. I hear them sometimes worry and fret that Drupal 8 is going to ruin Drupal because the contributor, not the contributor, the contrib experience, contrib modules, those people are not going to be able to deal with it and we're going to lose them. Or that the developer experience within side core is so terrible that we're not going to have anybody to work on core. And what new people can bring to initiatives right now is those are the people that we're afraid are going to leave. We need to get them in now so that they can look at the work that we're doing and find out what they're scared about and what doesn't work for them and fix it while we still have some time to fix it. And also what does work and we can check off the list and not worry about anymore? New contributors can bring to initiatives also fresh energy. Core initiatives are really attractive and shiny and they get excited about them. They have that pain point that the initiative people had also. That's why they made their initiative and they want to solve it too. And they come to you and they're like, I want to work on your initiative. It also gives that new person a way to focus on something they can do and not get overwhelmed by the sea of, oh my God, everything is wrong with Drupal 8. So an initiative is a great place for a new contributor to be involved because it makes them, it gives them a chance to be more productive because they can focus on some small part of it. Another thing, I don't know if you guys have noticed, sometimes core developers are kind of cranky and kind of feeling sad. And to me that means burnout. So if you're in a situation where you're feeling kind of down and everything's frustrating and there's these criticals you don't know how to fix and say your block conversion patch got marked needs work on a usability issue you didn't anticipate this didn't happen to me recently. The thing to do at that point is take a step back and work with someone who can see all the things that are good about your initiative. Who can say, oh wow, this is amazing, I'm so excited to work on this and that energy will reinvigorate you and infect you and help you remember why you're doing what you're doing. Alright, so you're an initiative lead and you are thinking what can new contributors bring to my initiative? Another thing that they can bring is other contributors. So new contributors, their friends don't yet work on Drupal. All of our friends already work on Drupal. The new people, they have a whole pool of people that they can bring in. They're coworkers at work, they're friends that hang out with them and when they come and work in your initiative and they have a really good experience, they get excited about it. It's brand new, it's the thing everybody is doing. They're going to go and talk to their friends and their coworkers and they're going to be like, come with me, come with me on Friday, let's do it in the office for a couple of hours. Come with me to DrupalCon and we'll sprint on Friday. Come with me to our local meetup and we're going to sprint there. So we can exponentially grow because the new people have pools of other new people. And finally, we cannot afford to not onboard new people. The number one problem that I hear from initiative leads, like I said, is I don't have the resources I need, I don't have enough reliable people. The number one problem in the core queue in general, as Kathy and Andrea just talked about for half an hour, is that it's difficult to find people who have the technical competence to do a code review on a patch. And the number one problem in Drupal at large, we always hear about the talent gap. So we need to, as a community, as core developers, as Drupal eight interested parties, as Drupal nine interested parties, we have to start focusing on our new contributors. And so I hope we've convinced you in our brief four-minute discussion that new contributors are an amazing and necessary resource for all of us. But there are definitely challenges that you'll face working with them that you don't face when you're working with experienced core developers. And believe me, I have seen it all. One thing is that highly technical initiatives can be difficult. It's hard to interest new contributors in them, and hard to get them going. Everyone knows what VUES is, so I have an advantage there. But it's hard to explain what WSCCI even stands for, much less what the scope of that initiative actually is. So that's a challenge. The second challenge is that it takes a long time to onboard new people. Depending on their backgrounds, they might be programmers in another language. There's lots of little things that we take for granted in terms of how we handle issues and having a Drupal eight environment install all these details that they might not have covered yet. And finally, it can be kind of hard to find things for people to work on. If you schedule a sprint for your initiative and you show up and there's all these eager, shining eyes there, people who want to work on things for you and you ask them about their background and realize this really hard problem that I have, I don't want to depress them and try to make them help me solve it because we're not going to be able to do that here. So it's important to find, you know, it's a challenge to find the right task for them to do. And because Kathy and I apparently have all of the answers, we can tell you how to make it work and how to address these problems. Okay, so because it takes so long to onboard people and initiative leads or prolific contributors in initiatives, they get stressed out and they don't see return on investment. It takes a long time to onboard people. One way of dealing with that is to use core mentoring. So if a new person comes to your initiative and they haven't yet done anything with core, welcome them in and then say please go to core mentoring. And then core mentoring will fix them. They will get them all tooled up. They will get into IRC. They'll learn how to use the issue queue. They'll install and make sure Drupal 8 runs on their environment and initiative owners don't have to mess with any of that. It also gives that new contributor a really good first experience by mentors who are passionate about onboarding new contributors. So that's another advantage of using the core mentoring. It is also functions a little bit as a pre-screening because if somebody comes into IRC and they're like, oh my God, I'm so excited. I really want to help you with your initiative and you help them for six hours and then they don't come back. That's a waste, right? And it frustrates everybody. But if you're like, oh, I'm really glad you're here. You can help us with our initiative. Go to core mentoring. If they don't come back, you haven't lost anything, right? But if they do come back, you know that they actually really are committed. They really want to help you with your initiative. Core mentoring, by the way, I realize we don't have a slide for this, has held twice a week in the Drupal IRC channel. All they have to do is show up and say, I would like to participate in core mentoring and people will descend on them and help them. And there's also a sprint on Friday. If you have anyone like this who has come up to you at this conference and says, I really want to contribute and help you with Project X, send them to the sprint on Friday and we'll get them ramped up. Okay, so another way of dealing with new contributors in initiatives is to assign them a specific issue to work on. So they come in, they're ready. Let's say they already tooled up with core mentoring and now they come back and they're like, okay, I did core mentoring. I'm ready to work on your initiative. And you're like, okay, great, go work on it. They can't pick an issue to work on. They just can't. They don't know how to evaluate if it's a good fit for them. They don't know which ones would be a good thing to work on at this point in time. So as an initiative owner or somebody who's really involved in an initiative, pick a specific issue, give them a link to it and say, I think this is a good issue for you. Let me know what you think. Give them one thing to work on. When you give them that issue, they will also still not know what to do because an issue is not the same thing as a task. There are many tasks in an issue. There are many things that it needs. It might need a code review or it might need accessibility review. We talked about that already. So tell them specifically in that issue what you need them to do. Be really careful about what issue you give them. The most epic controversial issue is not a good place for somebody's first experience in your initiative. Even if it's your most urgent need time-wise, it's not a good match for somebody new to your initiative because you might pick out a small task. Because you've listened to us talk about this and you're like, oh, I should give them something easy to do. So you think it's going to take you like an hour to do it. It's going to take them three days. And if this is something that you need to be committed this week, that's not good for them. You want to pick something where they have time to work it out and you're not irritated at them because they're taking too long. So pick something that's not critical. Pick issues where there are not high emotions running. And another good thing to consider when you're picking on an issue to give somebody new is that meta issues are excellent. Or any issue that has had something similar already done. So you can say, I want you to work on this issue. Look at this other issue as an example of this very similar thing having been done already. And that really sets them up for success. Make their first task one they can succeed at. It has to be the smallest, simplest task that you think they could possibly do. Just the first time. Because people who have a lot of skills, they do other things very, very well. It's difficult to separate how to work on core with how to work on an initiative with solve this intellectual problem. So you get rid of that, solve this intellectual problem out. Just get them used to the process first. So you pick out a really small, simple task even if that person has a lot of skills. Myself, in fact, my first patch to core was my first update to a patch from core was removing one blank line. One blank line checks, asks an IRC for someone to remove a blank line. I'm like, oh, I can do that. And so I did it. I had 10 years of PHP development experience at that point, 10 years. But that 10 years of experience didn't give me the courage to start working in the issue queue. Removing a blank line did. So, also, you need to let your new contributors make mistakes. This is something that's very difficult for a lot of people. It's very difficult for me. You might have met me. If you have, you know that I like things to be done well and thoroughly, and I have great attention to detail. And it's been a challenge for me to learn not to stand over someone's shoulder and say, oh, no. No, do this. Oh, no, no, no. You don't want to use that assertion. Use this other one. And oh, actually, you should do that. And oh, that doc block's not formatted correctly. You have to restrain yourself from doing that and let them make mistakes in their own. Because for one thing, if you're sitting there telling them what to do every step of the way, they're going to feel kind of threatened and insufficient. And they're going to want to say, you know, why don't you just do this since you're playing puppet master? And the other thing is when they make mistakes in their own, they'll discover what the mistakes they made were, and they'll remember for next time they'll actually learn it. Whereas if you're just talking at them, they won't retain that thing. So now we're going to tell you how to make them come back. We've talked about why you need them, how to get them. And now we're going to tell you how to keep them coming back and make them into the people that you eventually will rely on. First thing, full frontal nicety. Angie Byron coined this phrase. This means on the other side of me. She coined this phrase. She claims not to remember doing it. The idea is that for people that are outside of your close-knit group, always defaults to being courteous to them. And honestly, it's not just about being a jerk. The subtitle is a joke. The most important thing you can do is to treat new contributors like peers, because they are your peers. They might be a heck of a lot smarter than you are, actually. You don't know yet. And the thing that they're stuck on is not a technical problem necessarily. The first thing that barrier they're up against is our community structure and understanding that. Also do your best to not be abrupt or curt. It's very easy online to type a very short sentence and you reply, you need to do this. But don't try to avoid doing that because the internet's a funny thing and it's very easy for people to misunderstand your intentions. Also, you need to give them feedback. And Kathy and Angie just explained why this is important. And when you give them feedback, you start by thanking them for something specific that they did. Then do your patch review. And then close with what the next step should be. You might know that if their patch is failing test spot, they might need to retest it because maybe it was a random failure. Or they need to run that test that failed locally and then debug why it's failing. You know that and they don't necessarily know that. So if you just spell it on the issue, one sentence, it doesn't have to be a detailed explanation. Especially one sentence with a link to the new contributor task document that explains how to solve this. It'll be a lot easier for them to move forward and they'll feel like they have a direction they can go. Another way to keep people involved in your initiative is to thank them publicly with a tweet or update somewhere, a blog post. I remember the first time that I saw my name listed in the multilingual section of the core initiatives page where it has the pictures of all the initiative leads and the status and what they've done so far and what the next thing to do. And my name was listed there with all these other like super great multilingual people. And I felt like I had made the cover of the New York Times. Like I was like, holy crap. Like people are going to read that and they're going to see my name there. And I did something significant enough to be listed and thanked. It was amazing and it really energized me and I worked even harder the next week after that. Initiative meetings are awesome. They're in IRC or Google Hangouts or something. One small thing to do is at the beginning of the meeting ask if anybody's there for the first time when somebody very shyly says, oh yeah, it's my first time. I'm really glad you're here. And then that's it. Move on with the rest of the meeting. That's going to have an impact on that person. Also keep in mind that what really matters, the one thing that matters the most is the long-term effect. Sometimes people won't work out and that's okay. You're casting, you're trying to, you know, maybe you interact with 10 people and maybe out of those 10 people, two or three drop off and you don't hear from them after a couple weeks. And maybe if you are active for a while but at a low rate, what you really want is the one person, the one person who's going to get excited and get really involved and then take the next step and become someone who leads you and guides you. There's a story you might have heard at this conference already, but so a year ago at Drupal Condenver, a person who had never contributed to Drupal Core before was a competent developer, approached the configuration management lead and expressed that he was interested in working on that initiative. And I hate to think what would have happened to Drupal if Greg had blown him off because I'm talking about Alex Pot. He's our new Drupal Core maintainer. So you never know when the person you're talking to is the next Alex Pot. They're out there somewhere and you just need to talk to all 10 of them because it's just the one. It's the one that's going to make your life easier in the future. So we lied and we don't actually have all of the answers and we also didn't go into a lot of details because, you know, short session and I'm trying to brush and talk fast. Actually, I do that anyway, that's a lie. So does anyone have any questions about contributing, you know, how do we engage new contributors in initiatives or questions, ideas and suggestions because we'd love to hear them come up to the mic and ask your question and we have five minutes for questions. I think that one of the big problems that we have is about keeping people involved and we spoke about that. And I think one of the most off-putting things is people actually finding issues. Finding issues in the issue queue and I know a lot of people that are competent developers have done some stuff in the past but it's that kind of like hour or so that it takes them to get them back going and puts them off doing it. What I'd like to see, I think the tagging has been fantastic. I think the novice tag is a really great way of getting people involved. What I'd like to see is kind of more of a timeline of tag. So you have novice but you have other levels so that people are more likely to jump in at other levels and it's not a very time-consuming thing for people to do. So there's a core conversation you should come to this afternoon. Yes, it's this afternoon on this topic. I agree, I think it's very, very important to give people a way to find what's important in a format that they can digest and build community around that information and also help them identify what's easy and what's hard, what's time-consuming and what's not. And Gabor has some great ideas about this. His core conversation about tooling for core initiatives is this afternoon so I won't talk about that anymore. Come to that instead. No, I'll talk about that. So there's an IRC factoid for D8MI for Drupal 8 Multilingual Initiative so if you ask about D8MI it will give you a link to the multilingual hub and one of the things that we've played with is we have tags for novice and then we have one for medium and we have one for challenging that are challenging but they're for new people. This is what Gabor's talking about. And then we also have a hidden one that's called EPIC which is don't tell anybody to work on this. Don't burn their soul. The node access multilingual issue got tagged with that and I felt very bad. I'm actually one of those people who's almost brand new to contributing and I got to my first issue that I worked on was a little bit substantive and I was very proud of the work and it got committed to core and I was so excited to see that thing pop up on my profile saying, you know, this guy has contributed and it never has. So I don't know if that's why that happened but that's I would say if I were on the other side of this be really careful to make sure those attributions take place. So the reason for that actually is so contributed module projects if you've authored a commit in those projects it will give you a list of it but because core is highly collaborative we can't grant authorship to just one person because there may be three or four or ten people that helps solve an issue. So instead in core we do something that's different from most of contrib which is to give the attribution in the commit message as a string which means that in order to display that information on user profiles we have to parse the Git log and there's three or four different inventions like Marvel has one and yours is in Python and Eric has one in Ruby and Greg wrote one in PHP but it's never made the leap to being part of Drupal.org we've also talked about solutions in Git like adding this information in the Git notes instead so we have a more parsable format so that's something that that's a tools problem and I agree it would be amazing to see on someone's profile that this person has you know this many has been attributed this many times in the you know core but you know it's right now it's a technical challenge and not a you probably were mentioned in the message and you might have been mentioned in the release notes even but it's not showing up in your user profile which is actually I mean that's like that's our identity as community members that's where employers go to look for information about you in the job so I think that is a really important issue and I've hoped for a long time we can solve that when I want to get a quick estimate I do a Git log and pipe it into grep for my name I don't ever do that it works really well if you have a unique stream string for your username like XJM or YSCT and not so much if you have a username that's well anyway yeah okay so any other questions great then that's it and we are available if we have any questions from the previous session or for these things you can come hang out with us over here thanks guys