 Hello everyone, welcome to future of mentoring. We're here at Drupal Khan Barcelona in the year of 2015, which will become very important later. I'm here with Davide Hernandez-Ruiz. I'm Alina McKenzie, and this is Kathy Thays. For those of you who are not familiar with the format of a core conversation, we're going to be up here for maybe 20, 25 minutes or so, and with that, we're going to have an open mic afternoon where we all can converse about the future of mentoring. This presentation is already online, so if you want to follow along on your device, you can do so at bit.ly-future-mentoring. That's bit.ly-future-mentoring. And our speaker notes are also there, so if you want to take a sneak peek at that, you're more than welcome. This presentation is done in reveal.js, and it's available on GitHub, so if you want to give this presentation yourself, you're welcome to clone our repo. We also have a Google Doc for collaborative note-taking. It is located at bit.ly-future-mentoring-notes. That's bit.ly-future-mentoring-notes. And I would like to kindly ask one volunteer who loves taking notes and is ready to be our official volunteer note-taker. If you can please raise your hand. Thank you. Go ahead and put your name in the spot of glory on the dock as the volunteer note-taker. And we would like to ask you to take notes during the Q&A, especially. Hello, I am David Hernandez. I'm a Drupal developer with more than six years of experience. I'm also the local organizer of my local group. I'm part of the Spanish community, not too far from here. I'm also been mentoring for at least three Drupal cons in a few more local events. I'm Alina Mackenzie. I am originally from Poland. Right now I'm based in Chicago. I'm a system administrator and web developer there. I've been working with Drupal for about four years since Drupal 7. I've been involved with the community for about two years. And I'm a mentor. I'm Kathy Thays. I'm Yassiti online. I started with Drupal nine and a half years ago and have been a mentor probably at least since Portland. I work at Black Mesh, and it's my full-time job to do mentoring and contribute to CORD. I don't know. 2013? Okay. So we are going to follow a little bit of history. So past, you are not defined by your past. You are prepared by your past. So I'm going to talk about where we are going starting from the very beginning. And we must acknowledge where we have been and where we are now. So this story starts at 2011. Drupal.org gets a new feature that allows the issue summaries to be editable. Then there was also an initiative to get as many issues to get updated. That initiative was started by XGM. Yes, say hi. Also, we start doing the IRC office hours. An initiative started by Katz, with the help with XGM again. And they started doing weekly meetings on IRC. At the beginning, it was easy to get in only. Also, the needs tags were starting to get used and getting popularized. The office hours helped to standardize all these usage of tags. We started using the spreadsheets to track attendance and skill levels to the office hours and sprints. We move a little bit forward to 2012, where D. Hotsdon Jennifer created the first contributor task document as a central page placed for people to find out how they could contribute to Drupal. We also have the first DrupalCon Sprints Day in Denver. It was a full day of sprints with two rooms, one for general sprints, one for mentor sprints. And it was called the core office hours sprint. It was also the first time with the sprints and also the first time with a live commit. If you don't know what the live commit is, it's when Drees or another core maintainer, but I think always Drees comes to the stage and commits done during the sprint. Also, it's the year where Drupal Mentoring was created by XGM again. The idea was to build a community around mentors and mentees where people could say what they were doing, what their attendance list, who were their mentors, and so on. In 2013, Drupal.org got upgraded to Drupal 7, but that looks cool, but also removed the JSON feature with information about the issues, and that broke Drupal Mentoring.org. So it forced us to start doing the things we were doing on Drupal Mentoring on Drupal.org. We'd have to find workarounds. So before the Asignet field was used to indicate when people started writing code on the issues, and Drupal Mentoring used it, we used Drupal Mentoring to put the information about what we were doing apart from the writing code, maybe reviews and so on. So now, we start saying on the comments, I'm starting on a task, and I say what I'm going to do on the issue. The change in the behavior had many benefits, as it helps participants conquer their fear to comment on issue keywords, even if they are not providing a patch or doing a big improvement. It also happens that it also helps to the community to see what's going on and what everyone is doing, and more exposure of Mentoring integrated into the normal workflow. So 2014, it was the first time where the Drupal Association provided t-shirts for the mentors. Yeah, it was the first time the Drupal Association provided t-shirts for the mentors on the sprints. Drupal, the editor added the button to add the remaining task template. That was a big improvement. Mentors in the past before on the sprints, the mentors had to help the new people to set up the full environment, like installing Apache, PHP, JIT, teaching about JIT. That took a lot of time, and there was a lot of different environments. So there was an initiative by Brian Gilbert, who's here also, say hi. Hi. We had the goal to pick some standard set of tools that were likely to work on a wide variety of machines and were good enough to get people started on a sprint day without wasting the time of the mentors teaching all the tools technologies. So we decided to start using Akiadev desktop that was not that disabled before. So Brian and I worked very closely with Akiadev to get the app better ready for an upcoming sprint in time. So the Akiadev desktop evolved thanks to the mentors. To get useable for us during the sprint. It also was the first time we used the contributor task cards. It was on New Zealand, Drupal self, and it has been used all around, all the Drupal cons since that, and we refined them over the next Drupal cons. Oh, yep, we have the cards here. So now we had originally only five cards, the explorer, community contributor, user mover, developer, and mentor, and this year we have added the documenter task card. These cards have a little information about what it's all about this role, the tasks that the people on this card can do, and also the links to documentation. So it helps a lot to get started and everybody can download it and print it, print them to use them on their sprints. We got the stickers if you achieve the goals. Oh, yeah, they are in English and in Spanish. Fantastic, thank you, David. So this brings us to the present. They say, or actually Bill Keane says, yesterday is history, tomorrow is a mystery, but today is a gift and that's why we call it a present. So I'm Alina McKenzie. I've been involved with the core mentoring program essentially since last con, since Amsterdam I would say, in a more involved capacity. I am the lead mentor for communications, and I'm also kind of the person that's behind the scenes doing a lot of little things to enable other mentors to be their best and not have to worry about things like documenting things or preparing or writing emails. So I'm going to define the present not just as like today, now at 226 p.m., but more so in the last couple of months to tell you about the exciting things that have happened since last DrupalCon here in Europe. One great thing that happened is that we've gotten a lot more Drupal Association support, and DrupalCon sprints and mentoring are very tightly linked. So at Bogota, Kathy and the DA sat down together and documented all of the sprint planning tasks, and there's quite a lot of that. Since then, having that documentation has helped the DA staff to begin implementing sprint planning tasks for LA and sort of take over some of the load and some of the activity that we had to do ourselves. What does that mean? They provide financial support for the sprint task cards, which David just showed you for printing them. We're still responsible for designing stickers. Everybody loves stickers. New contributors and sprinters can pick them up during the sprint. We have lunch, right? Food gets people to get through the whole sprint day. Signs and the booth at the exhibit hall that recruits more mentors and participants at the con. So we're really, really happy that the DA has taken a more active role in supporting the core mentoring initiatives. The DA also provides DrupalCon tickets for experienced mentors, which otherwise some mentors cannot travel to DrupalCon, and that makes it a lot easier for mentors to be there, especially experienced mentors. Since last con, we now are on groups.drupal.org. We have a mentoring group, and our main goal for that group was to make our collective mentoring wisdom a lot more distributed and a lot more transparent. We want our activities to not just be locked down into Google Docs or emails, but be public so that anyone can come in and see what we do and how we do it. What do we use the groups that Drupal.org site for? We announce our monthly mentor meetings. We have meetings every Saturday at 20, 30 UTC, and we announce them on the site. We also, after each meeting, we post our meeting minutes so that if you miss the meeting, you can review what we talked about. And we, of course, have people who post questions to our group, and we address those questions from mentors. In addition to the group, we now have an official project. And the goal of our, we've always had the project. It was a sandbox, I believe, under XJM's sandbox space, but now it's an official project at drupal.org slash project slash mentoring. And the goal here is to have our to-do lists, our tasks, discoverable so that any drupal.org user that includes everyone in this room, to be able to comment, to edit, and to work on them without having explicit permission to access that information if we were to have it instead in a separate system like Google Docs or some other site or more specified, more specialized tools like Trello. We track tasks as issues, and we use the plan issues for documenting overarching tasks that have sort of a global meaning, and then we use specific issues for conference tasks, conference-related tasks. And it also allows us to track due dates. So, you know, by what point should we have a given number of mentors signed up and so on? We've made great strides in improving our documentation. This documentation can be found as the child pages of drupal.org core mentoring page. We have a mentoring at drupal events doc, which is quite expensive. It includes notes that were taken at a mentor orientation in Bogota. And now we use it at a mentor orientation. We do a dramatic reading by all of attending mentors to sort of get them engaged in the material. We have a mentoring coordinator and mentor lead responsibility pages, which describe the responsibilities of the sprint and planning lead, the sprint room lead, the booth lead, the communications lead, the first time sprinter lead, sprinter workshop lead, and novice issue triage lead so that that information is not locked up in our heads or our personal notes but rather available for anyone to see what mentors do. In Los Angeles this year, we've had our core commit that David mentioned. It happened at the earliest hour ever. It happened at 2 p.m. And that's sort of like a high point of the day. You know, everybody gets up on the stage and the core committer is there and explains what they do. Everybody's role is explained. It's kind of like who it goes directly into the project. After that, usually people kind of taper out and head out. So our core mentor sprint room, as it emptied out, what we did was we had the remaining first time contributors join the general sprint that's usually in a separate location. And together with the general sprinters, the new contributors could continue their work together with experienced contributors and initiative leads, which sort of shows us a trend that we have which is integrating, you know, separate sites into Drupal.org and integrating our new contributors into our general contributor pool. Finally, we've improved some communications. When I first started last year at DrupalCon Amsterdam, I used my personal email to send out emails and then I used a Google spreadsheet add-on to mass-email people, which is kind of unwieldy. We now use MailChimp, which has been great. Starting with Bogota, we use MailChimp and the reusable templates and scheduled emails are fantastic. And we plan to do some more things with that. So Drupal 7 had 900 contributors with commit mentions. Drupal 8 has over 3,000, right? We can kind of say that we are successful, yeah? Yeah? I think so. In fact, our success with getting new contributors involved in mentoring has inspired other open-source projects. We've had folks from Docker who were interested in investigating our techniques come and ask us what we do and how we do what we do. So I think this bodes very well for the future. The future. So I'm Kathy, Yassiti. I went to Denver as a participant and then have been involved in like every Drupal con almost since then and got really involved as like a lead in Portland with Jess and Andrea and Addy. And so I've seen this whole thing. I've experienced it personally. The pain of the past and the changes that we've gone through and all the conversations that we've had about what we want things to be like. So vision for the future. The best way to predict the future is to invent it. So in general, I think what we want to do is make it so we don't need mentors to help new contributors over barriers that are in their way to contribution. We want the information that people need to know in order to contribute to be on demand, discoverable and usable for them. So they don't need to have somebody to show them how to get there. They just, it just works. And when we do that, that will free up all of these incredibly passionate people that we have that are doing the mentoring that we have right now to do a different kind of mentoring. So that's back to the future and he's saying, 2015, you mean we're in the future? All right, so to get our vision of the future, we want to continue getting more automation. So we still have a ton of manual tasks that mentor, planner, leady people are doing. And they have more valuable skills and more ways that we could use their time to be getting even more participation from people if we could free them up. So one of the things that happens for Drupalcon is we have a page on the Drupalcon website where people can fill out a web form to sign up to mentor. And when they fill out that web form, we get an email to now generic Gmail mentoring account, which is nice. And it has the information from the fields and it has a couple of snippets of text that's formatted to make some of the manual things we have to do later easier. One of the things, though, is we have to get each of those people on the list inside MailChimp. And then MailChimp is awesome and is doing all kinds of automatic stuff for us. What we want to do is have MailChimp integration on the event site that uses the MailChimp API so when somebody fills out the form, they get added to the right list. That's completely possible to do. We just have to figure out what the barriers are to it and implications and then help make it happen. So the way we're tracking that is on issue 257.2663. The other thing that is done manually is we have a page on the Drupalcon sites for each event that talks about what the core sprint is, what the mentored core sprint is. And it lists all of the mentors that sign up. And what we used to do is get an email and it would say somebody signed up and we would go onto the page and edit it and then add that person's name to it and save it. It was very painful and very boring. And what we'd really like to have is just have a view of the web form results and it just gets the person's name on the page.org and makes that list for us. But since we are in the future right now, it turns out we did this yesterday, last night. So like one of these huge manual tasks that we had to do, now we don't have to do anymore and so now we have that time to do something else and it's really great. And the DA staff is awesome. Oh, the reason why we list the mentors on this page is because it's an acknowledgement, like a recognition of these people who are volunteering and giving up their days and also doing a bunch of planning ahead of time where like, look how awesome these people are and then they can show their friends, they can be like, look I'm an official mentor and it's on the website. The other thing having a list of mentor does is it gets more people to come to the sprint because they look at that list and they're like, oh my God, Justifish is going to mentor all day on Friday. I would love to work with Sally Young and then they sign up and then they come. Or like whoever is some name that they've heard of somewhere that they can see who those people are and then they come and then they want to work with them. So it's really good both for the mentors and to encourage participation. So it's nice that that's automatic now and it's just going to happen. So this issue, if you want to see what it looks like, it's part fixed, it's 223903, 2239073. Another thing that mentors always have to do is help new contributors find an issue. People are experts in Drupal, they know all tons of things, they have a job or they have their own project and they want to contribute. And I have had so many people here at this con stop me in the hallway and say I went into the sprint room but I didn't know what to do and I don't know how to work on an issue, I want to help. There was a tweet about it on Twitter, right? Like I asked people and nobody will help me figure out what to do. Like people want to help but they don't know how to do it on their own. So one of the things we can do to help people with this is to make it easier for people to find relevant first issues for them to work on. One thing is we have a ton of documentation on Drupal.org but it's confusing, it has duplicate information in multiple places, it's really long, it may not be the most discoverable thing. So we have an issue to consolidate it, distill it, make sure it's updated and make sure it's discoverable by those people who are wanting to do something. And this is to improve our novice contribution guide on Drupal.org. And it's 233-2789. The sad thing about this issue is it's really old. I think it was Austin. The two days after the sprint, one of the days I sat down with Boyan and we identified the problem, gathered the information, all the locations of things and made the issue. And part of the problem of why this isn't been fixed is we don't have any one person to champion this issue who will just grab onto it and not let it go until it's done. Neither me nor Boyan can dedicate all of our energies to that so we really need somebody who can grab onto this. And then the other thing that makes this difficult is it involves changes to Drupal.org. So we have to consider other priorities that Drupal.org has, maybe upcoming improvements that we might want to wait for that would make doing some of this easier. And so this is a hard problem but it will help so many people. We really need somebody to help with it. The other thing that will help people discover relevant first issues for them is something that is planned to being done but not right away. And that is to get topic pages. And so issue for this is 1-2-9-0-7-4-0. And the idea behind topic pages is it puts all of the relevant information all together so it's discoverable and you have context for understanding things. So a topic page would have recent news items, a sticky post that describes the current priorities for example an initiative like a multilingual initiative. It would show people who are active in their issues that are current priorities and if the leads of that initiative have tagged things as being good for new contributors it can have a special like new contributor section these issues for that initiative. And so it's not just an issue picked out at random and you don't understand what the priorities background of the thing is. It's putting everything all together. So that will also really help people be able to find their own first issues. If they find their own first issue the next thing that mentors do that we can automate is have instructions on the issue for how to work on the issue. People can have a problem, Google for it, find the issue as part of some site they're building and then they're like great you know what I'm already doing this for this project I can also help fix this issue but they're looking at the issue page and there are no instructions on that page for how to work on the issue. So I have a couple of different ideas for how to help that. One is 2013222 and this would add some metadata to an issue that would say these are the remaining tasks that need to be done in order to complete this issue it could track whether or not they're done but still say what they all needed to be and since it knows the tasks it can include automatic links to instructions on how to do the tasks. That will be really helpful for people who are looking at an issue page and say they want to help they'll see what there is to do and instructions for how to do it. There's a little bit more context that is needed also on an issue and another different approach but essentially this would also help with that problem so another approach is it 2193871 and this idea is to use context and put blocks on issue pages that would say something like this issue status is active it is possibly in discussion or discussion is done and waiting for a patch here's how to make a patch so it can get more information about lots of different things and then put that information on the page where people want to see it. Part of the context that people need when they have an issue is impossible for a new contributor to open up an issue page and say this would be a good use of my time or this is not a good use of my time they don't have that context. Experienced contributors who are mentoring or working at the sprint can help people pick issues to work on because they have more information so we should figure out how to say that information and just put it on the issue. So 2572061 is add a dismissible notification when somebody goes to a core issue while in whatever phase of release it is just scared so I made this issue like yes so the idea is there is a first time that you go to an issue and that issue is in the core project and we have dismissible notifications I think we have seen them before on Drupal.org maybe the profile thing terms of service the security thing but there might be or not but the idea is your first time you open up a core issue and you get a notification and it says something like core is currently in well okay so actually I think what I changed the words to be was like depending upon the phase of the release certain issues can be worked on or something got to work on the wording and then it has a link to a docs page which is about the release phase release cycle of Drupal which hopefully is updated with the current release phase and then that probably has a link to the docs page which explains what's allowed to be committable during that so like if we had this for the beta it would have said depending upon the things can be workable depending upon the release phase go read this thing and it would have gone to the page that said here's the release cycle we're currently in the beta here's another docs page which explains which things are committable in the beta and then they would have found that awesome flow graph which explained which things are workable and they would have learned about beta evaluations and documenting the issue and everything so the idea here is something to make it discoverable but not annoying on every single issue but I would also be up for annoying on every single issue so I would be really keen to get some help fine tuning the idea here alright if they find an issue that they decide is worthy of investing their time in and working on we can also alleviate some repetitive work from mentors by making it super easy for those contributors to get in an environment for them to do their work so automating the setup having it be the tools that experienced contributors like have kind of congregated around by setting them up super easy we've changed our mind over many many years about what that should be and there's two different needs there's one for what do we need on the sprint day when we Wi-Fi is an issue and there's also what do people need long term after the sprint day if they're at home and they have great Wi-Fi what should they be using all the time but I think we're ready to come back and look at this and think about it some more so that's 23509 and then the other thing that is part of my vision for the future is to remove a barrier not just to new contributors but to remove the barrier to becoming a mentor and there are a bunch of people who cannot travel to a Drupal Con and so we want to continue the documentation that we've done in terms of getting everything out of people's heads about how you pull this thing off and putting it on Drupal.org because like everything else it makes it discoverable and it also allows for more improvements because now anybody who has a good idea can edit it and improve it so we still have a few things to kind of document about the how do you have a sprint at Drupal Con so we want to have the open mic conversation I have some things, some topics I would like anything, any idea that's popped into your head since we started that would be great but also I don't know how we measure the success of the mentoring program like if we make a change and it isn't making it better or not so we need some ideas on how to measure success and the idea here is to free up mentors from these repetitive manually tasks but what are we freeing them up for like people say sometimes mentors want to do real mentoring like what the heck is that so open mic while we have the conversation I'm just going to leave some links up here one to evaluate our session and the other one for the notes because anybody can edit that Google Doc doesn't have to just be that if you could say your name and your Drupal.org name that would be great Hi my name is Anna, Drupal.org is a Kalata, I'm a first time mentor and actually have received a scholarship I guess or grant to attend Drupal Con because of me trying to be a mentor and I guess I was wondering are there any models in open source communities in other communities for automating this whole onboarding new contributors anything that we could use as a guideline or are kind of like we going to be the example once we figure this stuff out I don't know if there's any patterns that we can look at for automation of things I don't even think I've asked myself that question before so we should find out I know we are one of the most successful open source projects in terms of getting people involved and a couple of times this summer I went to not Drupal Conferences and talked to people from tiny open source projects, Unix distributions WordPress, Docker like just tons of people and when we talked about mentoring mostly they had questions for me now what we have looked at though that other open source projects are doing better than us is their new contributor documentation and so that issue that I talked about that needs some help has some research already on it on what other projects are doing and some samples and then some ideas to just take what they're doing as really well and do that so I know we've looked at the documentation of other open source projects but I don't think we've looked at automation that's a good idea to do Brian Gilbert, realitylooper on Drupal.org I think from my experience being a mentor at several Drupal Con's now the freeing up time is probably so they can attend the conference because this is the first time I've been to a session for about four Drupal Con's so I think that would help people be more willing to be a mentor although I was doing things that were probably more involved than some of the regular mentors but I just had an idea and I've already put it in the Google Doc of we could potentially automate the booth which would free up a lot of time aww but that's the birth of the humans I know but if you make it really funny I don't know alright it's an idea anyway it doesn't have to be done but that's one thing that could you know motion sensors it wouldn't so like hey you so earlier I was talking about how one time after Drupal Con I sat down with Boyan and we went through the thing about the new contributor task document I'm pretty sure that was the day after I sat down next to Brian and Brian and I had led mentoring for the first time and he was sitting down next to me and all he did was tool me up like he'd be like watching me do something and he's like no no no there's an app for that like we can automate that and we can automate that that's what I love about Brian changed my life well well the bold I would extend Brian's suggestion and we can not only automate the booth we can automate the whole mentoring process and Kathy has talked about that that the issue page needs to contain some links maybe to how people can work on that issue but I think that there is a lot of work done on that direction and there are a lot of links like contributor links first time contributor links and we have links to better evaluation phase what needs to be done my personal problem with that is that if I want to read all this first of all I need to click I don't know 100 links on one page so and I really need all this information because I need to be able to to write better evaluation I need to keep open 15 docs at one time I think so I think first of all we can borrow a user interface if you work with the editor on an issue you keep being on the same page always opening in pop-ups so it's much better for me at least and that's the first point and the second point what if we can make interaction with the same editor or some other tool like because better evaluation is basically a wizard so it's a series of questions that I as a reviewer needs to answer and next step is based on answer to the previous step so this is pretty a wizard so I click on several places and end up with ready better evaluation I'm intrigued and that's not a big deal I think in terms of developing very cool so that actually reminds me of one of the things I tried to work on for I think for LA was to get conditional fields because adding extra fields to the mentor sign up form or sorry just the conference sign up form was something that the DA didn't want to do and I did some work with Jay Perry about that but I don't know where it ever got to so that could be something that's integrated but it's also a really good thing that the extra time that we free up for mentors could go towards my name is Kalpana Goyal K Goyal on Drupal.org so in my previous session I said like participants can add mentor to their D.O. page so that's just a small token but what else can be done so companies recognize the value of mentoring because we are all volunteers spending time not working on issues for ourselves but helping other people working on their issues so what can be done so the recognition is much more wider than just the D.O. profile page also I have been saying that why DA always for all the Drupal cons provide mentor t-shirt I think that is just a expense that can be eliminated not a big deal but just an idea and thought I wanted to share the third thing I want to say that mentoring does really good job for novice issues but what about mentoring mentors on the major and critical issues so those are not just limited to the top core contributors but overall to the community so we cannot we can say that contributors are not or participants are not just limited to novice issues or writing issue summaries or doing manual testing or re-rolling the patch but much more and maybe we can encourage them to come and repeat contribution because they will gain support by working on some more critical or major or important issues. Yeah I think there is a post on groups.drupal.org about making like picking a color and just saying this color is mentor t-shirt color and then people can just bring that shirt with them whenever they go to a camp and I think that is especially useful for camps who have a small run of shirts just so their mentors can be identifiable. So the purpose of the t-shirts we mentioned when the DA started giving them to us is that they are a different color than any of the other con shirts or the volunteer shirts and at the Friday sprint what we have is we have maybe two to 300 people in a room and we need some way of visualizing identifying which of those people are wanting to answer your question. T-shirts are the best way I think to do that. We did something in Bogota where instead of the DA paying for shirts Bluehost brought black shirts that were very mildly logoed. It was very small, mostly black and we got green painter's tape and mentors took turns putting designs on the back of each other's shirts so they were black with huge neon green designs on them and that worked out really well but I think in terms of the benefit that we get from it I think it's totally worth the expense to have a specially colored shirt at a Drupal Con. I also think that some people their first mentor T-shirt that they wear at other places is recognition and a badge of honor for them at the next con. They can show up with a mentor T-shirt from a previous con and be like I've mentored before and people can recognize that they have mentored before too. It's like putting on your Drupal.org profile on the mentor except you wear it. So that's pretty good. I think one of the well I mean Justice here we could let me know if I'm right or not but if we think back about one of the purposes that the Drupal Con mentored sprint has served in the past was the general sprint room where there would be leaders in their area so maybe you know media I don't know what the heck people worked on before there was composer right rules but then also initiatives with inside Drupal core so there were people who had maybe a team so like one Uber experienced person who was blessed by trees and then they probably had active contributors that they dealt with normally and these are like the super skilled people who are working on the really interesting issues right and those people in the past when approached by new people who are like oh my god you're trying to think who I can use as an example oh my god you're a hay rocker like I want to help with CMI I can envision that it may have been some thoughts that passed through Greg's head like I don't have freaking time to teach this person how to make a patch and I'm going to explain to them where we are and what our priorities are and I'm going to invest my time in them and they're going to work on a thing not get it done won't post their broken thing on the issue leave and I will never see them again and what happens to initiative owners or other people who have big projects is they have this experience over and over and over again and even though they as humans want to help each individual because they have this pattern they learn that they don't get their return on investment their time is better spent being focused and this I think this was especially true many years ago and one of the things that the core mentoring program has done both through the office hours and at cons we take people who have never done anything before and we teach them the basics we make sure that they understand how to change issue statuses so they don't go into somebody else's like super critical issue and totally set it wrong we make sure they know the basic things for whatever they're going to end up doing so like maybe they're going to be doing QA testing for UI changes so we help them do that and make before and after screenshots and so they even know that that's a thing to do so that they can identify which issues need that so that they know to put their before and after screenshots in the issue summary so they know not to screenshot their whole entire computer screen and to crop it and to draw arrows and that they need we teach them those things so that when they go to join these initiatives or work with these people that they really want to work with they are not annoying they actually know what to do so you could walk up to to Gabor and you could say hey I want to work on an issue and he could say you know oh what do you want to do and he'd be like oh great we just had this patch posted on this issue it makes a change this form can you do before and after screenshots on it and that person does it and Gabor doesn't need to sit down and teach them how to do it so if you think if you consider that that was part of the purpose that's I don't know like that's what we were doing we were getting people ready so that they could join the group that would organically integrate them and first have them work in pairs on a major and then have them work on a critical and I would say if our community is failing at getting people involved in the real issues I don't necessarily think that's a problem with the mentoring program I think it's a problem with the people we are picking to lead initiatives and if we pick people with a different perspective to lead initiatives then that would be solved I don't think we need to solve it with mentoring we don't need special mentors who mentor like the cool things now what Mr. E said in his keynote was four features or initiatives or whatever is that one of the lessons that he's learned is that you need a diverse cross-functional team to lead and I would hope that one of the qualities that would people who are picking these teams would look for is that you need somebody who's going to be thinking about mentoring not mentoring new contributors but mentoring inside their group and the other question that you had was how do we recognize mentors I think we have the shirts which they get, we have their profiles sometimes we take a big picture at the end of the day that's pretty sweet because you can show it to your friends there could be a blog post like a wrap up blog post is something I think that I've done a lot I could use somebody else to do that but those can list the mentors and then that can go out on Drupal Planet that could be great I don't know if part of your question was how do we get people's employers to recognize the benefit to the employer of people doing mentoring and I think if that's a question I think we should think really hard about that maybe put it specifically in the Google Doc and get a lot of people's different opinions about that I don't think we do a particularly good job right now of having like a letter to your boss about over or left are we ten minutes over great I don't think we have like a letter to your boss this is why you should fund your employer fund your employee to contribute to core the best thing we've got I think in terms of that is the blog post that I wrote on the black mesh blog a while ago about strategies for companies funding core but it's still not really the benefits to the company so I think we have a need for that we could do a benefits for funding mentoring but I actually don't know if there is no way man let Alina go one thing that this is not Alina I'm not Alina I'm Jess I'm XJM I'm Drupalate Release Manager core mentor mentor mentor how many did we get three one thing that Kalpana has pointed out in the past is that we need to make sure that people who mentor contribution on an issue also get credit as contributors for that issue on Drupalate.org we have this new functionality that allows us to surface issue credits for non-patch contribution for reviews and other kinds of contribution on the issue that goes on someone's contributor profile it can go on their organization page and there's all kinds of work under development so that organizations get credit on Drupalate.org for the way that their members contribute and so one thing that we can do right now is when you're mentoring contributors on an issue or when you're mentoring other mentors about mentoring contributors on an issue make sure that mentor also posts a comment on their issue and says I am helping so and so work on such and so on Drupalate.org and it's not if your name you actually right now post an issue comment yourself because I as a core committer can once that issue is going to be committed to core just so long as you have one comment on that issue somewhere check a little box and then your organization and your user profile will receive credit for that issue because of the mentoring work that you did. So I think we should add that to the instructions then for Friday to tell our mentors that's super good idea and in terms of benefits to the employer that will only like that will give recognition to the mentor which will be nice we need to make sure that those people know how to attribute their time to their company if they want to so if they are being paid to be there on Friday they could attribute that effort to their company and then the company would get a benefit from it. I'm Eric on DDoDo Sutors on the new documentary card gave me an idea would it help if we in our wisdom as community or mentors whatever decide that a certain subject is not focused that certain subject doesn't have enough people working on it let's say UX we want to have more UX people in the community being active getting active would it help to make for example a UX card to starting tasks and then by that way attracting well make surfacing a subject for new contributors yeah I'm not sure I have to say that initially I thought these cards were a terrible idea and I really didn't want to do them but Andrea was like they're freaking awesome and I trust Andrea like we don't have to agree on everything and if she sees value in it and wants to like make it be done I'm like fine good luck and lots of people like these so are they being used they are being used in the fact that we are printing them and handing them out I don't know how useful people are finding them one of the super great things about having Alina on the team in the last year is that she's brilliant and she's one of the things that we've automated that we left off of the presentation was the mentor feedback so we sent on a survey and and then people answer and then we can evaluate things I think we could do the same thing with the participants of the sprint if we had a list of people who had participated in the sprint and we could send them a survey and we could ask them did you use the sprint card did you find it useful we might maybe also ask mentors at the end of the day whether they have people seeing using it that's a low tech indication so I kind of think maybe like we haven't really talked about measures of success of mentoring yet but that could be something that maybe we would want to measure what we want to invest our energy in is like adding more things to this I think UX people who have never contributed to CORE before are still going to go through the steps that we already have and so if we're talking about the sprint day I don't think anybody could get through these steps and another one that depends on these like this is already a ton of stuff to do so and then now you're talking about somebody's second sprint experience so they've done this and now they're ready to do something else and so I don't really know so we should think about it yeah hi I'm XJM again so I just wanted to respond to a couple of things one question that Kathy asked or was it Alina one of you asked earlier was so what are we freeing up our time to do if we take these things that we shouldn't be doing that a computer could do for us and make sure that people can get the information by themselves I think one thing that a lot of people think of when they think of mentoring is of doing like pair programming and pair review collaborative like one on one or one on three small exercises I think because of the scale of our sprints at Drupalcon and the scale of nitpicky things people have to learn we lose some of that because mentors become in some ways like crowd herding sort of like high level task selection management helpers and have less opportunity to share their individual knowledge and experience with someone and also they lose some of the opportunity to learn from that that new person that they're mentoring as well because it should go both ways so that's my hope for the future I think Val's suggestion about the interactive issue summary evaluation is huge like the beta evaluation is like a particularly it's right exactly it's like an extreme specific example but the questions that you have to answer for that are always relevant I think that I believe that symphony has some github integration that covers some of the kind of metadata about an issue that we care about for for issue evaluation of Drupalcon we should look at that we should look at how they do that and we should try to do something similar so that people have at Dreadator is always a first good step to prototype stuff but you know eventually it should also be part of the functionality on Drupalcon.org one of the nice things about the new maintainers of Dreadator they're refusing to put any new features in it so they're like no, we should be fixing things on Drupal.org because we want our tools to be available to everybody not just people who knew about the secret thing you have to download and I think that's actually a really good thing I will say that one challenge for this kind of functionality and I also like Kathy's suggestion about a notification that this issue is filed against Drupal8.org.x which is currently a candidate, here's a link to what that means is beautiful and mind blowing but what challenge for that as well as for the other issue evaluation is that Drupal.org issues like core is a significant audience but there's also thousands of contributed modules and themes and all kinds of distributions all kinds of other projects that all share the same like the same node type the same field set and so it makes it easier to introduce things in a way and we have this problem with change records too there's a lot of customizations to how change records work that we would like to add that would make them more helpful for Drupal.org issues that aren't necessarily relevant for other projects or that it's hard to make them generic enough custom settings per module makes a feature harder to implement but more tolerable by contrived who doesn't want to have to mess with stuff just because core does they do I mean we come up with that with the issue tasks problem too Neil Drum said they have their own rules okay so one more from Brian or sorry I have two more things okay the session just ended but there is a 30 minutes break we're two minutes over three minutes over there is a 30 minutes break 15 minutes now we can take all time go ahead so have you guys been out in the exhibition hall you saw that thing on the floor that has my name and Kathy's name and who was ever in big letters and people keep tweeting at me about it we should have something like that that's not about patch contribution we should have that of mentors that information is like at triple con portland we did the same thing on the mentor booth the thing of the core commit message name tag cloud thing we're so far past that mentors are the people that we should we don't need any new contributors we have 3,000 of them that's kind of well so so wait did you really think a tag cloud of mentor names is a good idea yes how do we get the data no I think that I think that including mentors we need to make sure that mentors are included in that contribution information mentoring is a first class kind of contribution it is as important to resolving an issue through the comment attributions but I also would love to have a like here are people who have mentored it at triple con barcelona and see their names there that some that's the kind of like it unless they prefer not to be listed like having their user name is like that's fantastic they're part of this in the same way that speakers are like important value part of that so are the mentors the sprints are amazing for people and then that helps the two things that are most dear to my heart that and I forgot to note down who actually raised them in the q&a number one is getting both mentors and credit new contributors up that next rung of contribution so that they go from working on the simple task to working on something that's more difficult I think that that's another place where I would love to see mentors mentoring more is like okay you've mastered the basics now let me show you what I do what I work on and here's how I get involved and and and the way that the area that I work on also depends on me and also I think that definitely depends on having having people work on what matters at sprints making sure that whenever we recommend tasks for people we really are picking something that is something that is going to be included as much as best as we can anticipate is part of what's most important to whatever initiative or project or you know Drupal core final beta that they're working on at the time that's all Brian Gilbert reality loop again I think one of the things that we should be trying to tell companies like I see a lot of people when we're at the mentor booth are you going to be here on Friday no I'm going home if they've been sent here by their company I think it needs to be potentially today I think to say that that's part of the conference as one of the days specifically in the date range or something yeah it used to be that Drupal con dates on the site only included Tuesday Wednesday and Thursday and over the years we've gotten them to include Monday and Friday on the dates on the site but still a bunch of people are leaving on Friday and their flights are at 5 and you know they don't get up until 11 and they have to leave this print by 2 so they just don't come I'm even seeing people who are leaving Thursday night yeah so yeah I wonder if there's some messaging we can ask the events people to use when they advertise to companies somehow or campaign to them to yeah and I think someone else in the crowd said it the value to companies is that they're getting more experience there's a lot of companies who have people working with Drupal who've never contributed to call never done a contribution even this is how it's going to get them started so I think it has a lot of value as a company owner myself so right I think I think we have a little bit more experience with thinking about the value of working on issues but I don't know if we have as much experience with thinking about the value of having other people help other people work on issues now I say that but that's my job right so there are some companies that don't just see the value of paying a core committer full time to review and commit and work on issues but do see value in not directly working on issues all the time but helping other people work on issues so if we and part of the value that black mesh gets from having me is I'm uber visible and since I'm very visible then our name is very visible too so if we're looking to maybe take some of that benefit and give it to all of the mentors that we might want to consider giving every mentors companies name visibility somehow and we mentioned that as part of the comment attributions but maybe there's something we can do a little bit more I don't know if we have any statistics on what's the drop off on people who mentor across multiple conferences but that's somewhere a tag cloud might help that type of thing reality loop although it's my username but as a company we run the local mentoring and meetups in Australia our whole team is here to mentor at the conference I don't even know that we get much out of it in value for the company but to me it's an open source project if you don't contribute to it it's not going to continue to exist yeah you know you have a microphone you're giving the session you don't have to queue up you get to interrupt the people not wait in line so hi I'm Alina Ali Mack is my username I'm gonna if you've made it this far into the recording you can't see me but I am taking off my operational slash planning mentor hat including on my mentor mentor hat one of the things that I've had difficulty with as an occasional contributor to give you an idea what that's like I have a modest like 20 commits commit mentions but I don't work on Drupal all the time I pretty much only work on it at sprints and at Drupal cons and other Drupal events so there's that kind of difficulty I experience in ramping up to fill my brain back with issues that I can mentor others on because I know them better because I've noticed that that's a really helpful thing is whenever I know an issue more more deeply I can then be a better mentor towards a person who works on it for the first time yes and I want to give a shout out to Emma Maria who is the component maintainer for Bartek for being a really great person who is also a mentor and kind of combining both roles but that's she does that but other mentors are not component maintainers or are not teams or are just occasional contributors like me I think it would be helpful for us to be somehow connected better with the teams and the component maintainers to have them give us a run down of issues that we could become more familiar with I don't know how I imagine this or envision this I'm just saying that it would be great to have more integration I definitely think getting more involvement from maintainers would help occasional contributors and occasional mentors be more effective I suspect part of why we don't get more component maintainers or components around work why we don't get more core maintainers in the front room on Friday is in part because they think we don't need them we already have 60 people we're going to have like 75 people you don't need us you've got plenty of people over there so we could tell them that we need them directly so we could email them and say we need you and this is why we need you there may be other I think this would make an incredibly good section in the Q&A Google Doc to flesh out I think we can have a lot to think about and I think Tim has some thoughts I have some thoughts on that wait give a little bit of background I helped start mentoring with Jess and I haven't mentored since Munich because after Munich I became paid to work on core so I get to come to Drupalcon and I'm basically required to not mentor I just wanted to say that there's other reasons that core maintainers aren't mentoring it's because we're here to sprint ourselves there's a huge amount of pressure on experienced contributors to core to get the criticals done or get whatever is critical in their project done there's a lot of pressure to do that I just wanted to point that out it's like I miss mentoring but it's my job to not mentor at Drupalcon basically maybe we can bring instead of bringing the core maintainers to the mentors we can assign mentors to core maintainers that works too I mean mentees of course that might work but with each as the cycle grows longer the issues get harder and you need to have known about that issue for three months to have all the background information blah blah blah and it's terrible and it would completely soul crush anyone who already wasn't working on that issue soul crush is us too it's pretty bad I love to think of more ways to get people to what Brian was saying with companies somehow convince them that being a mentor is very important I get to take half day of mentoring I think we should think about this some more list of all of the blockers and then brainstorm if there's anything we can do even if you think sure on the day you have to work instead of on the day why don't you go through your issue queue and pick out five issues tag them novice update the issue summary with the remaining tasks and then we'll use those but even the part of the day that somebody would take to do that is they're still under pressure to just be working on the things that they have to work on so it's going to take a lot of thinking we should probably be done very soon very soon I will be quick well Tim needs to get set up oh you're not next well Donna needs to get set up I think there is kind of controversy here from one side Cathy said that one of the things that we have achieved is that we have offloaded part of the work from core maintainers and to become more effective we need to work with core maintainers just more so the question is what if we try to work with core maintainers before the day before the Friday to not to not bother them on Friday what we try to do with the core maintainers this time and failed by the way alright okay so can I have the last word you can totally have the last word I don't think it's an either or thing we either take these people and bring them to mentors or take these people and bring them to core maintainers like you said we can brainstorm some way that will satisfy all of us combined good alright thanks now it's all yours