 Hi, I'm Kathy. This is a core conversation and it has two topics in this time slot. One of them is patch reviews, how to get people to review your patch and also how to do a patch review, some of the tools that we use to do that, some improvements that we need to make to the tools. The second topic that we will talk about after a break in the middle is mentoring mentors, how to turn regular people into mentors of mentors. Because this is a core conversation, the format is a short presentation and then a long time for discussion and questions. My goal is to do 15-minute presentation, 15-minute questions, 15-minute presentation, 15-minute questions. I won't make my goal because you guys should beat me when I get to close to 15 minutes. My name is Kathy. If you want to stay for only one of those topics, that's fine. If you want to switch rooms, that's also totally okay, really is. My name is Kathy. I'm YSCT on Drupal.org. I'm also YSCT on Twitter, so you can tweet at me during the talk or after the talk. I review patches quite often, mostly in core, but the topics also are going to apply in part to contrib and maybe also to other projects that you have even outside of the Drupal program itself. I do some other stuff like plan sprints. I really like to plan sprints and I love going to them. For example, Friday, I spend a lot of time asking other people to do things so that Friday happens and I do some things to make Friday happen. Also you should all come on Friday, Friday, Sprint Day. I also have a part-time job. I work for Compress, which is a company in Hamburg, Germany. They're a small Drupal shop of about 20 people. My job for them is to work on core. They pay me 15 hours a week, which I split between actually working on core and blogging about working on core. Then usually I also can't stop working on core, so then I keep going even if they don't pay me. A little bit about the process and why reviews are so important. WebChick has this awesome talk that she gives and there's a video recording of it, a YouTube video. There's a tiny URL, a webchick-how. This is one of the slides in her talk. It shows that we can't solve any problem that we have by ourselves. We need somebody to report the bug in a way that makes sense and we can understand it. We need somebody to produce a patch to fix the bug. We need more people to try and document more things about how to reproduce the bug. We also need somebody to review the proposed solution, which they'll find problems with, which we get a new solution. Then we need another review and another new solution and another review and it goes on like that. We don't have reviews. We don't get anywhere in the process. That's important both for the people who make the patch. They want their work not to go to waste, shouldn't sit there in the issue queue forever and not do anything. It's also important for the people who are doing the reviews to know that they are really important in the process. After it goes through a period of community review, when the community thinks it's good, somebody will be bold enough to market reviewed and tested by the community. That's when a core committer sees it, they will review it. If they have a problem with it, they'll set it back to needs work. There's no danger in reviewing something because there's always somebody else that's going to check it after you, too. You just do the best you can. It's a big problem space. We have 1,500 open issues that need review, not all our issues. We have like 10,000 or a lot of issues, 1,500 of them that's 20% a need review. First, it's an interesting order, but first we're going to talk about how to get patch reviews. If you make a patch, when you post the patch, it's very helpful to be specific about the kind of review that you need. You set the status to needs review and what kind of review. You might add a comment when you post your patch, like, I'm just putting up this half done thing because I want to get initial feedback on the approach. That's really helpful for somebody who finds the issue, needs review, they know what kind of review to give. Or you think you're totally done, you're like, I really think this is great, but I need a JavaScript person to look at it. Now you know what kind of review. When you post your review, tell people what kind. You can do that in words, in a comment, and you can also use tags. There's some really common tags that we use in our issue cues, and these are some examples of them. They usually start with needs. So needs JavaScript review, needs a usability review, needs manual testing. When you produce a patch, you worked really hard on it and you invested time in it and you don't want it to go to waste. If somebody finds your issue because they saw it needs review status and they saw that it needs a JavaScript review and they can do JavaScript reviews, you've got a potential reviewer looking at your issue. You don't want them to leave because they can't understand what the problem is or why your approach is a good approach. In order to keep a reviewer looking at your issue, it's very helpful to update the issue summary. Make sure that there are clear description of the problem, steps to be able to reproduce the problem, and a description of your approach. Maybe if other approaches were discussed, why they were not the one that was chosen, and this should be a summary. So easy to read, five minutes to the point. Steps to reproduce for people who are going to test or review your patch should start with install Drupal 7 or install Drupal 8. Number one step. You have to be really clear step by step and they should be numbered. If you add a needs tags, like a needs screenshot, it turns out for almost, for a bunch of the needs tags, the community has instructions written down that tell people how to do that. So we have instructions written down for how to manually test something. We have instructions written down for how to review an issue technically. But those instructions are hidden in a docs page tucked in a corner somewhere on Drupal.org. So I think it would be really great if when we added needs tags to things, automatically Drupal.org added the link to the instructions to the issue. So this is a mock-up of how that might look. If you know anything about usability and can tell me if this is usable or not, that would be great. So there's both an issue in the Drupal.org kind of infrastructure customizations issue queue, and there's also one in Dread Editor. And we can make this happen either of those ways. And there's pluses and minuses to doing that. But the idea here is that the link is the link to how to do the thing. And then paired with the link is the tag so that it's clear to the person looking at it how that link got put there. So the backport, a Drupal core patch link to the instructions for how to do that is there because it was tagged needs backport. So there you go. So that would be really great. And we have issues in the queues. You can start to work on that to make that happen right away. Oh, I should, here's a close up so you can see it better. So the issue on Drupal.org is 2013222. And the issue in the Dread Editor GitHub issue queue is issue 16. So these instructions are all kind of named with a pattern. We call them contributor task documents. There's a list of them at Drupal.org slash contributor dash tasks slash review. That's an example of one. If you go to that one, they're all grouped there in the right hand sidebar. So you can see all of the different ones that exist that we've written. Anybody can add a new one. So if you know of a needs tags that's missing one, you can see how to improve the documentation, the kind of system that we use. And you can go ahead and add one. You can also edit them to improve them. You don't need special permission to do that. Feel free. If you have produced a patch and you want to review, it's because we don't have those issues solved yet for how to automatically add these instructions. It's very helpful if you find the doc, cut and paste the link, put it in a comment on the issue so people who find your issue can actually do the review that you so desperately want. If we don't get reviews quickly, the patches go stale and then we make more work for ourselves because we have to either fix it because cores change wildly in terms of approach or it's just moved a little bit and we have to re-roll it. But you don't want to do that as a patch producer. You want to get somebody to review it when it's fresh. It's less work for you that way. If you are creating patches that are similar or you need to create a bunch of patches that are similar, grouping them together under a meta issue actually helps you get reviews because you can have a new person find the meta issue if you put really great instructions in the meta for how to do a review because it might be like a very special topic, like perhaps it's about schemas or it might be about undefined, unused variables. We have a meta for that. You put very specific instructions in the meta. Somebody who finds an issue, it's linked to the meta or they find a meta, it's linked to the issue. They'll see those instructions. Maybe they'll review one of them. Well, if there's a hundred issues like that and you've written down really great instructions, they're gonna do a couple more. They're gonna review another one, maybe three or four of them, then they'll go on and do something else. So if you have something that's very similar, documenting the instructions for how to do it makes it so other people will do what you need them to do, which is to review. If you've made a patch, if you've produced a patch and you want somebody to test it, but the audience of testers, of reviewers that you need doesn't have the dreadator plugin installed for whatever reason, perhaps they're on a device that can't have dreadator or they don't know about it. You can also build a custom URL to simply test me and you can post that either in the issue summary or in a comment. And when you do that, it enables people to test a patch without having a local environment. So simply test me, lives in the cloud, you tell it which projects, which module, you tell it which patch you want applied to it and then anybody can test a patch and they can test it on their phone when they're on the train. If they can't use a certain kind of device but they can use another one, this is all hosted in the cloud and all they need is the URL that you send them. You can tweet the URL, you can mail it to them, it's really super handy. Another way to get people to review your things is to give reviews, like literally in terms of a trade. You can just say, hey, I really need somebody to review this, I'm willing to do anything, I'll even review one of your patches. And that works, but whether or not you have it one to one trade, the more you give reviews, the better reviews that you're gonna get back in return because there's gonna be more examples of good reviews out there. People tend to repeat the patterns that they see happen over and over again. Not everybody's gonna read the instruction, the contributor task document on how to do a review. What they're gonna do is read the issues, read, read, read, they're gonna get brave enough one day to do a review and they're just gonna repeat what they saw other people posting. So if they see people posting incomplete reviews or reviews that just say looks good or people just mark things RTBC, they're gonna think that's the way to do it. So we can actually improve the quality of reviews that we get by giving quality reviews. So there's more good examples out there. These things, these approaches that patch producers can do actually are accomplishing the goal of helping people find their issue that needs review. So your market needs review, that helps them find it. You tag it with tags that helps them make sure their skills are gonna be useful on that thing, making these easy links and these instructions are all making it easy for people to find how to do it. So if you think that you might wanna review something, and I'm gonna give you some tips on how to do that, what you wanna do in terms of selecting something to review is you wanna look for something that's really simple the first time. You can look for things that are tagged novice and if you're an IRC you can ask the question novice and you can look for initiatives. They will often have a list of things that they think need a review. You can also ask them, you can say I'm new, I want to review something, do you have anything good for a novice to review? And usually initiatives have some way of bringing people in and they will help match you up with an issue. In IRC the bot that lives there answers these questions, these other questions are helpful too in terms of finding issues to review, metas and focus. So when you log into d.o, you can find issues to review using the novice link that's in your dashboard. Takes you to a page that searches all things and it's just an active search of issues but that have the novice tag on them. You're looking for something to review. You can use this advanced search to customize this. You can select only things that have status needs review. Maybe you want Drupal 8 things. Perhaps you want to work inside a particular initiative so you can tell the needs tags filter you would like all of both novice and maybe D8MI if that's the tag for the initiative you're interested in. Initiatives, you can find out more about them on drupal.org, community dash initiatives slash Drupal dash core, for example. Here's what the views initiative page looks like. The cool thing about this is it doesn't matter exactly what issues are listed here. You can click on a couple of them and figure out what are the common tags that they're using with the issues that they're kind of working on right now. So you just need to find anything that somebody's working on. See what tags they're using and then search for some more issues with those tags. Sometimes issues have a lot of tags. Other initiatives have hubs instead of a list of issues on that page. So there's a link in the multilingual section to the multilingual hub, which has a focus board on it that we use to organize our initiatives because I'm part of multilingual. But other initiatives use focus boards too. So if you're in IRC, you can ask the robot focus and it will tell you the focus boards for lots of initiatives. If you want to work on one of those meta issues where it has really good review instructions and you want to kind of be productive even though you don't know all of Drupal 8, you're like, well, at least if I learn about this one topic in this meta, there's a lot of sub-issues. I can do a bunch of them. You can feel really productive then. So you can ask at Metas and it'll help you find some meta issues. So there's the entity field API focus board is there too. So I'm out of my 15 minutes. When you're giving your review, it's really important that we're constructive because you could be reviewing somebody's first patch. So we need to be very supportive and make it so that when they make a future patch, they make it better the next time, but we do it in a nice way. So we're very specific in our feedback. We include links to resources and standards. It's enough to ask a question. You don't have to say whether or not they've used the right approach. You can ask a question about the approach. And the idea is to scale the community so that we all improve together. Dread Editor is a very handy tool. It's no longer ND.0. It's on GitHub. You want to delete it out of your browser. It's a browser plugin. And then use their nice just easy click button to install it. When you find an issue you want to review, please follow it because you will lose issues. Issues get lost. They're like poor little puppies. We have to keep track of them. They might have a good issue summary. If the patch producer has updated it, which identifies the problem very specifically, they should have steps to reproduce. If they do, you should thank them and also follow them. Simply Test Me is a good tool to help with that. My tip here is to register. If you don't register, your example of your patched Drupal 8 in the cloud only lasts 30 minutes, but you register and you get more. And it's free. The way you use it, these are quick, but they'll save you a little confusion. You type Drupal in the search, pick Drupal core. You want D8, you want, you want D8. No, you want 8.x, which is the bottom of the longest drop down in the world because you always want to test on head. Don't test on the last alpha. It's weeks old. We're not like that at all anymore. You gotta be on 8.x. I like this tool, Jing, lives in the corner of my computer and it's really easy to make screenshots and has this cool markup tool. I will usually, anything that affects the UI has to have a before and after screenshot posted in a review. It's also a nice post in the issue summary. Sometimes, even if something doesn't say that it affects the UI, I like to try the patch because nobody ever actually tries it. So it's good to just try things in the UI and post screenshots before and after. Jing is a good tool. When you have Dryditor, it's really cool. You get these review and simply test me buttons. You always want to use the most recent patch on an issue and this can be confusing if you're new because it can be like 20 patches. Which one should you test? Scroll all the way down to the bottom. You want to test the most recent one. You want to find out whether or not it works. It's not doing too much. It doesn't break anything. The simply test me button is awesome. It's really easy. But if you need to test it locally, it's nice to right click, copy the link address. You can curl it down or W get it. Apply it. I like get apply minus minus index in the patch name and I like to commit it right away because a lot of times what happens is if I'm doing a review, I will find some little things that need to be fixed. If I've committed the patch, I can go ahead and fix them when I find them and then it's really easy to do my inner diff because I'm diffing against what I've just committed. It used to be like last month, a couple months ago, I would apply the patch. I would forget to commit it. I would fix a bunch of things and I'm like, oh crap. Now I have to make another branch, apply the patch in there and then diff against this branch, against that branch. So download the patch, apply it, commit it. Then make your changes. Or do whatever you want. I'm sorry. The other nice thing that Dread Editor gives you when you attach your screenshots is an embed link which puts the image tags right in there. You want to say when you write up your review, how you did the review, in case there's another patch posted later on the issue, you don't have time to do the review, some other new person can come by and do what you did. They'll know how because you wrote down what you did. You wanna say whether or not it works. It's also really great if you can test it without the patch and verify the issue it exists without the patch. The new Dread Editor is awesome. It's just great. You should use it. The diff stats are kind of cool. I learned about those. Somebody told me about the diff stats. If you're re-rolling, you wanna look at the diff stats on the old patch. You re-roll something. Look at the diff stats on your new patch. It gives you a hint about whether or not you've done it right at all because if the diff stats are radically different, you probably messed it up. The other kind of cool thing you can do, like a sanity check, is you can look at your patch and your inner diff and just look at the size of them. And if they're zero bytes, you did it wrong. And if they're the same size, you probably did it wrong. When you do your review, number your points, but you don't have to do that anymore because the new Dread Editor does it for you. So it's really important that we have a strategy for how to deal with these 20% of our issues need review and there's like a bazillion of them. And so the strategy is to scale ourselves and we do that by clearly explaining our steps even though it seems silly in a comment. Say how you did your review. Say exactly what you did. If you only looked at the code in Dread Editor, say I only looked at the code in Dread Editor. If you only tried it manually, say, I only tried it manually. That's really helpful. Oh, and when you're done with your review, it's great if you update the issue summary and if it needed a JavaScript review and you did it, you can remove the tag that says needs JavaScript review. Oh, and there's other things that we don't have time to talk about. But I will, because I can't not. So the problem is when you do reviews, you don't want to tell the person all of the things that you found wrong because it's too overwhelming. You want to tell them only the minimum stuff that we have to get fixed in order to get the patch into core. The way you know what is the minimum stuff, they're called core gates. So it's drupal.org slash core dash gates. If you find something wrong and it doesn't meet one of these core gates, you mark it needs work. If you find something wrong and it's a little knit, don't mark it needs work, just fix it. Submit your own patch. It's really cool then because it's probably something small and then you'll get a core commit mention for doing a review and fixing a small thing. Interdiff's are great. I will tell you about them anytime you want. You can ask me. It's fine. And we won't talk about that. Oh, this one is good. So I got PHP storm and it totally rocks. Should get it. It identifies problems for you. So you apply the patch, look at it in context and it'll be like, hey, look at this, it's wrong. And then you can sound all smart when you're like, hey, did you know you did those? And then I have resources in my slides, which I will post up on the session talk. So, yes? Oh, yes, we will find out. There may be a PHP tips or something about PHP storm. Okay, so, hold on. So you guys, that's it. So the point of the take home points here are, people who produce patches need to know what reviewers need and reviewers need to know what to do and you have to kind of work together. So the topics are linked. I want to skip to a particular slide. So if anybody has any questions like about how the review process sucks and what tools we need to improve, there we go. You should go to the microphone and complain right now. I think maybe, I'm gonna guess nine. Yes. So, this was one of the ideas that I had to help improve things and then I have another idea I'll show you too. I'm gonna get it ready while you guys figure out if you want to suggest something or... I was just gonna ask, if something's gone RTBC and then it's been reviewed by a core committer and it's gone back to needs work, but it's only a little thing. Does it then need to go back into, needs to be reviewed by someone else and then... Yes. It seems really hard to find reviewers to do things. Yes, so, I was a little too close. So right, so one of the common things, like when we looked at that, it can take a really long time to get something committed into core. It's dedication, it's patience, but it's also teamwork, tag teaming. So you don't have to take something all the way. You can do one of the little steps and then you can ask for help or you can just hope that somebody helps. Those are actually okay work patterns, but if it's something you care about a lot, sometimes you're like, oh please, please, can we get this in right away? So you can do some things to help with that. If a committer marks a previously RTBC patch needs work and you fix it and when you market needs review, make a really good comment there and also update your issue summary. Make it clear that those concerns have been addressed. Say how you addressed them and when you post your patch, hop in IRC, post a link to the issue and you could say, I've addressed the concerns of whoever. I'm around for the next two hours. Ping me if you take a look at this and you have any questions. It needs review. And make sure you have an interdiff. And make sure you have an interdiff. Yeah, that's the sort of example I was thinking of. It's a really simple patch that I've just been sitting around with and needs review for months or so because I added the HTTPS in Drupal in the link to Drupal. Yeah, it was RTBC, but it is now back to needs review. And it's been sitting at needs review for months. It's just got the expert, S added. Yeah, so when, you almost always post an interdiff when you post a new patch. The only time you normally don't is if you're re-rolling. If you're new at re-rolls or it's a complicated re-roll, instead of an interdiff, you can copy and paste the conflicts and copy and paste how you resolved the conflict. And that can kind of help somebody evaluate whether or not the re-roll is still good. So that can be helpful too. So anything you can do to describe what your changes were in terms of an interdiff, but also words or anything else, that's really helpful. And then actually talking to human beings, that works too. You can tweet out links to your issue. You can go in IRC. You can go to Meetups. You can come to Sprints. I know it's weird, but sometimes you have to talk to people. Okay. Does anybody have any thoughts about this mock-up here? Do you think it's socks or it's redundant or annoying or it's great? Just go to the mic. It's great. The descriptions might be a little bit redundant. I like great parts, but having these instructions at hand for the most important or most common tags will greatly, I think, make it a lot easier to follow up on all those things. For instance, needs tests is a very common tag that is added to a lot of things. And I think if you're a newcomer, writing tests, you have no prior experience with writing them outside of Drupal. It can be daunting. You don't know where to start. This prevents you from having to ask on IRC, et cetera. Yeah. As an example. Yeah, so that is one of my worries is I want to kind of reveal how these things get automatically added by kind of noting that they're paired, but then they're also tags and now they're also over here and sometimes the names are also very similar. So if anybody has some better ideas for that. I guess if you put it like that, you want to do this using a simple checkbox on the issue summary, but yeah, take this up with Boyan and Roy from the UX team, for instance. Oh yeah, I should market needs usability review. There, ask him. Okay, I have another picture I want to show you. You can come up to the screen if you want to see it better. Okay, so this is a pencil drawing. You have to know the issue queue to understand this. When you go to make a new comment, you have the comment box where you write your comment right above that. If you have dreaded her, which you will all have after today, if you don't already. There's a autocomplete field where you can type in tags like needs magic and my proposal here is that next to the needs tags, autocomplete, we put a button which says edit tags when you click the button over the top of your comment is something and it has two sections at the top are the tags that are already on the issue either with checkboxes that are already checked or with X's on them so you can just click it to remove a tag instead of having to backspace to remove tags. And then under that section of tags already on the issue is a curated list of common useful tags that are unchecked and if you check them and hit update tag button or cancel but if you hit the update tag button what happens is that window goes away, the tags are added to the autocomplete and if the tag you added has a contributor task document that gets appended to the end of your comment pasted into the comment and then right before you submit your comment you have the option to take out those automatically added instructions. So this is another proposal so I'd like to have some feedback on that also. Jess. So last night Kathy was looking at our slides and we were sitting down in the lobby of the hotel having some beverages and Alex Pott looked at the slide and commented and said what was talking about how tags was a bad idea and I yelled at him, I was like screw you. We worked with what we had and I think that we solved a problem that was there but that said the Drupal 7 upgrade of Drupal.org is imminent apparently and in that upgrade there's things like fields so we could have like I mean these needs tags that we came up with that like things that you have to do that are part of the process of developing a patch that's not really the same as something like tagging something for the web services initiative or you know so I mean maybe something to consider is and you know in consultation with designers and in the fullness of time and so forth is there a better way that we can expose our process as a separate field? I mean there's already too many fields but at the same time not enough and I don't know anything about usability but that's one thing to keep in mind and relate to that. It does seem like the needs tags are, there are different kinds of tags. Yeah, for sure. It is. It's a subset of both needs work and needs review. Which is very tricky, which is the other thing that can be frustrating for new contributors sometimes is they don't know which status to pick because in fact issues are in both states and one of the ways that more experienced contributors can help make that clear is in the issue summary. There's a very common section that people add sometimes which is called remaining tasks. So in the remaining tasks section what we can do is number them, identify each item so we can say it needs a JavaScript review but it needs work to address the concern by Alex Pott. And that remaining tasks list is handwritten by a human, expresses the idea that something might be in both a state of needing review and needs work at the same time. Related to what I said before and this idea of being able to do new things with project issue for the first time in a long time. Tomorrow night. Yay! Tomorrow night. So like I said about the Drupal.org D7 upgrade being imminent and... So we were talking about... We're looking at Neil because Neil is working very hard on it. So we're talking about tomorrow. So it would be really great if people could beta test it and so we're talking about tomorrow night in the lobby of the Corinthia. Right, Wednesday night. Wednesday night in the lobby of the Corinthia having a Drupal.org user testing slash drinking slash music party festathon fun time. So if you have ideas about usability if you like using issue queues if you're good at breaking things like you should come and hang out and test Drupal.org and have a few drinks because the best usability testing is done with alcohol. I mean, right? Like after, I'm not... I don't mean to promote alcoholism if you don't drink that's fine too. You can have a tea and enjoy the music which also inspires you to pay less attention focus on just what's most no-stool. So it'd be great if anyone wants to help out with that. Yes. There could be a guitar and a ukulele and I may write my review as lyrics. So it's gonna be fun and you can be with your friends and everybody should come Corinthia Wednesday night so we can review the new D-Dado interface. Okay, so let's do one more question and then we have to talk about how to turn regular people into mentors. Okay, as a follow-up on those status things and that needs work and needs review for instance and as you can be both states one of the things that has been annoying me a lot is that whenever you post a patch and you said it needs review and you want people to look at it the test bot does it as well and then it says no, your patch fails slams it back into needs work and then nobody will look at it anymore even though you just want the review for the approach you took. Ooh, that's a good point. Somebody write that down. Oh, if you don't want, that's if you know you don't but it's just, it's both needs work and needs review at the same time. You want a human to give you some advice on your approach but it also doesn't work so it needs work, yeah. I want the test review to see does it break any tests and I want the human review to see, okay, is this approach acceptable? Does this approach solve the problem? Which is one case where the needs tax are kind of handy because the test bot might mark it needs work but you can still have it needs usability review. Right, because it kicks it back to needs work. People use that issue status to filter. I know but it's a human doing it. So, okay, that definitely, we should think about that. Somebody should make an issue. Oh, okay, so if we, yeah, so a human being after the test bot comes back and says it fails a test, you can still set it back to needs review. I would recommend when you do that in a comment, say what kind of review you're looking for. Another thought about crazy workflow things regarding this, a reviewing is let's, we have computers that can do things for us. The problem is that we need the humans to program them to do them for us. So not everything is reasonable but there is one idea floating around. If a patch is submitted and it has certain characteristics like it changes any file that is a .js, that Drupal.org should be smart enough to know that that needs a JavaScript review or if it changes CSS that it needs a CSS review because those are sometimes not capable of being tested by the test bot and so we might need humans to look at it. The people who produce the patches, especially new people, don't know that if they change a JavaScript file in their patch that they should tag it with JavaScript or needs JavaScript review and since we have computers that can detect which files we're changing in our patches that might be something that we can one day have automatically noted for us. So I really wanna talk about this other topic also. I can't find the top of my window. There it is. That didn't work. Okay, it's talk number two. Turning regular people into mentors of mentors. Sustainable core development through the core mentoring program. So we have two topics during this core conversation and we have some new people in the room. So I'm Kathy, I'm glad you came by. I'm yesct on Drupal.org and I'm also, oh that's a lie, I'm also on Twitter as yesct. I work for Compress and they pay me to contribute to core and it turns out asking businesses to pay you to work on core might sometimes work if you wanna know how I did that, I can talk to you about it later. And we're gonna talk about how people become mentors because you don't just like come into a community and all of a sudden you are a mentor. If that's interesting to you, please stay but if you only wanted to hear the review part it's really okay if you'd rather go do something else. Sorry. So people start out as just a participant in a community. They help do one thing once. They tested a patch, they filed an issue. Those are participants. What we'd really like to do is to scale. So we need to turn a one-time participant into a repeat participant. And we can do that by making sure that they feel welcomed, making sure that they have tasks that are well matched to their skills. Finding issues to work on is the hardest thing for a new person to do. Finding a second issue to work on is still hard to do. So we have one way of handling that which is directing people into core mentoring. And there's IRC weekly meetings so people can participate from any part of the world. There's also very commonly now sprints at camps and cons on Friday. And where mentors can talk to somebody, find out what they're good at and match them up with issues to work on. But not everybody knows that these things are available. So we also have to figure out kind of how we can make that more transparent and integrative in the process. Like how do you find the next issue to work on? Experience contributors or initiative leads can help with that if you notice a new person has stumbled upon an issue that you see and they've done something useful on the issue we can thank them. And we can suggest another issue they might find interesting. It sounds like you're being pushy or asking people too much but they're actually really appreciative when you make a suggestion of a similar issue, of a similar skill difficulty level but maybe a little bit harder. They actually will say thank you for telling me something to go do because they can't find anything to do. Once people are repeat participants, we want to turn them into mentors. And we can do this by mentoring in public because habitual participants are hanging around the community a lot. They're looking at what people are saying in IRC. They're seeing how people are interacting in the issue cues. And when more experienced people or their mentors are around, if they're mentoring in public, in Pound Drupal, not in private but in Pound Drupal, or they're doing it actually on an issue, they're doing their mentoring on an issue, they're accidentally training people who aren't mentors. The people who are hanging around just working on a lot of issues. They happen to see a conversation take place. And that has like this subtle social change in people's brains and then all of a sudden they're like, they start to repeat that pattern themselves even if they're not officially become a mentor. So mentoring in public is really important. This is a picture of a shadowy spy. It's so shadowy, we can't even tell they're there. So when we do that mentoring in public, it's like we're subversively training everybody to be mentors. So we're being a little covert about it. Then people still need a little push though. So they've seen this, they've experienced it, they know how it happens. One day a mentor will be too busy to do something and what they'll do is just ask somebody to do it. So that happened to me this weekend. I was mentoring or trying to work on something else and mentor at the same time was just overwhelmed. And there was somebody that had been, had worked on like three issues that day. So they were a habitual participant. They had been in the room where I was mentoring. So they had accidentally seen how to mentor. I had unconsciously trained them and I got too busy. So I just said to them, could you please help this person? So I asked them and they did it. And now voila, they're a mentor. If somebody mentors once, we really want them to like that experience, not be stressed out or scared by it and become a habitual mentor. So to do that, that impromptu mentor, we can make that conversion happen by remaining a resource for them. So it wasn't like, hey, I want you to mentor this room now and I'm gonna go get lunch and go watch a movie. No, it was, I help these three people. I'm gonna be right here. If you get confused or you don't know how to help them, just come ask me. So they're doing this mentoring thing, but I'm gonna make sure they have a really good experience and that they feel empowered and capable as a mentor by kind of hanging around and being there in case they get stuck on something. Maybe they turn into a habitual mentor. At the next event they have, they've had this good experience mentoring. They knew they were supported and they might actually volunteer, find the conference organizer and say, I mentored before at this other sprint. Do you need any mentors? And now they're gonna become a habitual mentor over and over and we want those people not to just be mentors, but we need to have them start turning people themselves. It's not enough. We need some people to mentor the mentors. And so the way to do that is if you have a mentor that you've worked with and you see that they're doing a good job at mentoring, you can tell them what they've done good and then a new mentor comes up and says, hey, I'm a new mentor, I'd like to mentor. You can be like, wait, new mentor, experienced mentor? Experienced mentor, you're now a mentor of mentors. Would you please go show this new mentor how to use the tools, explain to them some of the things that you've found really helpful when you're dealing with people and now you have a mentor of mentors. While we're doing all of this stuff, we wanna expose how we know how to do things so people don't think that we're magically smart. We show them the resources that we use, how we track things, the cool tricks that we have, we support them, we make jokes together, we go out to dinner, we help each other with maybe something that doesn't even involve, mentoring directly and you build relationships with people and then what happens is they start to want to be in the place where all of this magic happens because it's fun and it's great and they get a lot out of it. Technically, socially and that happens when we're nice and when we expose our reasoning. So it's really about people and other people and getting together. So that's a quick overview of some ideas of how to turn regular people, not yet participants or just first time participants one day into being a mentor of mentors. I could tell you quite embarrassing stories about my particular journey along that way and all the mistakes that I've made and that would inspire you to see that you have the qualifications to, in fact, become a mentor of mentors yourself and you can ask me anytime. I would love to tell embarrassing stories about myself. So right now though, we're gonna do questions and suggestions brainstorm about the process, complain about experiences that you've had and what we might be able to do different in the future to make sure that those don't happen. While we're doing that, if you could please find this session on the schedule and give some feedback that would really help us in future cons decide what topics you find useful or how to make them even more useful for you. So you go just to the schedule page and find the talk and there you go. So the questions and answers here. So I want to know if you have any answers to any suggestions for new things that we can do and if nobody has any wild brainstorming, great ideas, you can ask me questions and I can answer those. We can actually do them in any order. You're so shy. Who's been a mentor at Group of Cons? Yes, who's that? Let's get things started like that. Who's ever participated in a mentor sprint as a mentor and helped people get started? I've been a mentor. That's not too many. Okay, we have a lot of potential. Okay, wait, hold on. It's a third of the room and we have maybe 25 people. I'm looking at this as potential, you know? I'm telling for the people who can't see. Not everybody can see the room. Who wants to be or is planning to mentor this week on Friday? Oh, who's mentoring on Friday? So, okay, there are a few hands not raised. Why? I'd like to know. So it turns out that we have this big sprint on Friday. Hundreds of people are going to come and want to communicate. They're gonna want to contribute. And we can help make sure that they have a good experience by providing mentors that help them through that process so that when they go home or when they come to the next event, they contribute again. And the cool thing about that is what we end up in the end is a better Drupal because we have people who are helping to make it better. And like, so if you come to a sprint and you fix something, that's cool. That was good. If you come to a sprint and you help eight people fix something and three of those people continue to fix things in the future, you've now become more productive in your work because you fixed three times as many things even though you haven't fixed anything. So we have all these people coming. We need about 50 mentors and we have 27 signed up. So the beginning of this talk where you get some idea for how maybe you've reviewed things before or produced a patch before but some of these tips, you thought, oh, that's a good tip. So what you can do is you can come to the sprint on Friday and you can share those tips with people who maybe weren't at this talk or your own tips with people. And you don't have to go through special training in order to show up on Friday and come up to me and say, Kathy, I was totally inspired by your awesome talk. I'd really like a yellow t-shirt. Can I mentor? We'll get a yellow t-shirt? You get a yellow t-shirt when you mentor. Say you left it in the first place. Just one question, I wonder maybe it's about the definition of being a mentor because I plan to come on Friday on the sprint and I plan to get some work done or get really into it, coding some stuff. And surely I'm going to be supportive if someone beside me needs to set up an Apache or whatever. It doesn't just qualify me as a mentor, just I will be there and will be supportive but I won't run around telling anybody. But I'm the one with the yellow t-shirt, just ask me, I know bearing nothing. Right, what's your name? George. George. So you have two interesting things that you've brought up. One is you're coming to the sprint on Friday, you'd like to get some work done and you don't mind helping some other people also. One of the things you can do on Friday is you can work half of the day. You can tell me I'll mentor for the first half but I really want to get some things done so after lunch I'm gonna sprint or you can do it the other way around. I will say, that's great. The other thing is one of the cool, we have extended sprints around cons now, it's kind of a thing. We also have them around big events like bad camp and dev days and they're usually two days before, two days after or something like that. The cool thing about that is the hardcore people who just want to work and they just feel bad when they're not working at a sprint, it's a little bit easier to deal with that if you can say to yourself, I can mentor on Friday because I can sprint on Saturday and Sunday. And so Saturday and Sunday instead of hundreds of people there's like 50 people and they're mostly people who know what they're doing so there's not as much need for a mentor and so people can get more work done. So you might be more willing to mentor on Friday if you were planning to also stay for the sprint on Saturday. It doesn't help you today when your plane leaves on Friday at six o'clock but at the next Drupalcon or the dev days or bad camp or wherever you are planned to stay longer than the event I guarantee you people are sprinting the days before and after I will be because I'm mentoring on the day when we do the thing. So the other interesting thing that you brought up is what is the definition of a mentor? So for Friday the definition of when you are mentoring and when you're sprinting for me like one of the clear signals is mentors usually are walking around wearing a shirt that easily identifies them as somebody who anybody can bug. So you see a mentor walking around and you're sprinting and you have a question you know you can interrupt that person and that they will help you. There's another kind of mentor both on Friday and also always in the community at the same time and those are camouflaged mentors they don't wear yellow shirts they sit at the table next to you working quietly but are really willing to help you if you just ask them. So I was reviewing this thing and I've never seen this before should I correct it? Should I mention it? And this experienced person sitting next to them will totally mentor, right? Like it happens all of the time. In Dries' keynote when he put those community people up there, right? He mentioned me for mentoring but what he didn't mention is all of those other people up there are mentors. Every single one of them. Burdir mentors all the time but he doesn't wear a yellow shirt, right? So that's the other cool thing about the covert mentoring, right? Like when you do mentoring in public people who are participating a lot they start to pick up these mentoring things and they start to do them. So like when you say like how do you define mentor? Like it's actually kind of an interesting question. I also wanted to respond to what you said with regard to the point about I can help people set up an Apache stack but I might not know the answers to their other questions and so maybe I can't do the whole mentoring thing. That's wrong, you can because the most important discovery I think that I made is that you don't have to know everything. You don't even have to know a lot. For anyone I haven't met, I'm Jess, I'm XJM and I kind of sort of started the core mentoring program. She kind of sort of absolutely did. So she is a mentor of mentors. I'm a mentor of mentors and mentors. She turned me into, like she took me through that process, right? So she's my mentor. So the thing is when I started in 2011 I didn't know what the hell I was doing. I was such a noob. It was ridiculous how much of a noob I was but I just was like, I was willing to be wrong and I took the things that I didn't know how to do and help people do those things. And so like when you're at a sprint, especially, but also when we do mentoring, if you talk about IRC mentoring when I was late. Maybe a little bit. Okay. We have IRC mentoring, it's twice a week, you can Google it. Or you can follow Drupal Mentoring on Twitter and I tweet when mentoring hours start and I also should totally follow Drupal Mentoring. You totally should follow at Drupal Mentoring on Twitter all the way. So in both those scenarios you can ask other people. Like Kathy said, there are already 27 mentors there and it's gonna be busy and crazy. But on the other hand, both when you do mentoring in person in a sprint or online or even in like not a formal setting like we just mentioned, but just this like stuff that happens in the issue queue. It's totally okay to be like, you know, I don't know but maybe Kathy knows someone who knows the answer or like, oh, you know, I know that there's this guy over there who's like, looks like he's working right now but it's a really technical question and I think he know the answer to it. So let's go there. So it's more about just like, help giving someone someone to ask and then pointing them in the right direction because there's going to be this huge volume of people who are just looking for someone to just give them a nudge. And so if you can give them that nudge and then just say, oh, you know what? I don't know how to answer that question but let me ask someone else who can find someone to help you. That is huge. Another thing that Kathy and Andrea did at DrupalCon Portland, which was really valuable is they had a couple people out in front of the sprint who's just spent a couple hours just organizing people like saying, this is where you need to go. If like asking people, what's your skill set? You know, do you need to set up a DevSec? Oh, you do then go to the workshop. Oh, you don't. Well, maybe you want to go in here and just sort of like coordinating back and forth. That's a big thing. They were like greeters and like traffic cops. See, what happens sometimes at a sprint? Hosts at a restaurant. Is people first of all, don't think that they're smart enough to come to sprints but what happens is that we talk about it all the time, how much fun it is and we keep telling them so eventually one time they like walk down the hall towards a sprint but they're still really nervous. If they don't know where to go or what to do immediately, they leave. I mean, it's tempting, right? Because what is your choice? Hold up in a room where a scary experience, something totally new to you is gonna happen that you may not enjoy or you could go to the castle in Prague, right? So it's easy to turn around and just leave, right? Or get up and go. So having somebody smile and say, hi, yes, you're in the right place. This is the sprint. Oh, oh, you've done that but you haven't done that. I know exactly who you need to talk to and where to go. Come with me, go here. So we don't like put handcuffs on them and like drag them to where they need to go, right? Right. We entice them and we make it so easy that why wouldn't you do it, right? And the thing about not being skilled, I remember just being the maintainer of taxonomy access control. And I remember, I remember you were starting out by doing reviews and stuff and now she can do all these cool things. But the reason she can do all these cool, one of the reasons she and I can do more things, way more things than I could before is because I mentored. Because what happens when you mentor is forces you kind of outside of your skills into others because I don't talk to a new participant and say, let me tell you what I'm good at and let me help you find an issue that I know about. Okay, sometimes I do. But what I do is I talk to them so I'm gonna talk to somebody who knows something I don't know anything about but I'm the mentor. So then I have to find an issue for them to work on, figure out what the issue needs because they're not gonna solve the whole issue, they're only gonna do one part and we do that together. I can even show them how I find an issue to work on so I'm exposing that to them because they don't know. And then together we have to figure out how to do that thing and then we have to figure out how to know how to do that thing and we do it together and in the end they're happy because now they know how to go off on their own and how to do all of these things and their area of interest but I'm accidentally forced to get a new skill and now I know how to do that thing too. But what I have sat down at home by myself and said, you know what, I'm really gonna figure out local tasks, routing YAML things. Like yeah, no, I'm not gonna, like that's not my idea of a fun evening by myself frustrated when I can't find examples, they don't work, da-da-da-da. But somehow when I mentor somebody who wants to work on that and we're doing it together and we're interacting, I don't know, it's just more fun and now I know these things that I didn't know before and so you don't have to know a lot when you mentor, you just kinda have to do it and then over time it's amazing. It's like, we say that companies should encourage their employees to contribute because when they contribute to core, their work gets reviewed, they learn how to do their work better. It doesn't matter what it is, mocking UIs or making suggestions about possible solutions or writing code, whatever you do, somebody's gonna point out what you've done wrong, you're gonna discuss it, you're gonna figure out what was really wrong and how to do it better and we make that argument for companies all the time for participating but it turns out the same thing is true for mentoring. Companies can pay their people to mentor, we haven't tried this yet, but I don't know. Companies can pay their people to mentor and the company gets the same effect. What do they get back when that person returns to work? Somebody who knows a whole heck of a lot about a lot more things so you don't have to initially know things, you just have to show up. I'm back. For people who didn't know me yet, I haven't introduced myself, I'm Bart Zano with an X on triple.org. I'd like to share three short experiences from my two times of mentoring in Drupalcons, Munich and Portland. One of them you may already have heard in the previous boff. So I started mentoring in Drupal- You have two minutes. Drupal-Munich, last year. I stayed for the sprints but I had never touched Drupal-8 before and there were all these focused groups of people working on views and routing, well not, I did not know what to do until Jess started talking about the mentoring sprints and I thought, well, I know jack shit about Drupal-8 but I know how the review process goes. I've done-