 Can everyone hear me? Perfect. Morning. Thank you everyone for joining the last session before lunchtime. We'll try to make it nice and quick. The title of this talk today is teaches bread on the ones to chop wood and carry water in their open source journey. So we're hoping to focus on mentoring, particularly open stack flavoured mentoring. We're hoping by the end of this talk that you'll have a, we'll say, a good idea of the opportunities that are available to you as either a mentor, potential mentor or potential mentee. And we're hoping as well that you'll pick up a few tips from professionals such as Victoria here. Before we get started we should probably introduce ourselves. My name's Stephen, Stephen Finooken or Stephen Finn on IRC. I'm a software engineer at Red Hat and as you can tell from the photo I'm also an Egypt for Choosing to spend the last year of my life working on a broadcast house that's consuming all of my time. So it's been nice this week to be thinking of something other than asbestos. When I'm not risking my life and limb working on houses I tend to write a lot of code. I've been involved in OpenSec since 2015. Most of that time I've been working on Nova but I've also worked in SDK in OpenSec client. I've messed around with Cinder and stuff. Apologies in advance for anyone here that I've, whose project I've broken at some point over the last few years. All right and hi everyone. I am Victoria Martinez-Elegrus. I'm a senior software engineer at Red Hat. I have been involved with OpenSec for a couple of years now. Actually my first contribution was in 2014. My first summit was of OpenStack Summit in Poland. And that was because of, well, basically I got involved with an outreach internship which we are going to be talking about in a couple of minutes. The picture I have on the screen for me is very, very important. It has a lot of emotions for me. The person in the middle does Flavio Percoco. He was my mentor for Google's number of code. And it was for the OpenStack Summit in Austin. And, well, after my initial contribution, as I mentioned, to the dashboard, I have been jumping around different projects within OpenStack. I have been contributing to SACAR project. I have been contributing to Trove. And nowadays I find my home in the OpenStack Manila project which is a shared file system as a service. Which, well, I continue to contribute and mentor and will get people involved. All right. So let's start by talking a bit about the history of mentoring within the OpenStack community. And, well, I like this part a lot because I kind of follow the process in its beginnings. As I mentioned, I started contributing to OpenStack. Thank you to an internship which is nowadays known as O-Richie. That's the logo in the middle. Back then it was the O-Rich Brown for Women. I was the first cohort of mentees that the OpenStack community has. And after that, I continue to get involved with this project, sorry, with this program by doing some mentoring test. Then I joined as a coordinator for the program. Nowadays there are super nice people taking care of. I just gave a step back. But, well, I have been involved with the program since then. This program saw the participation of so much people from the time I did it. Which was 2013 till now. We got more than 50 mentees from all over the world. Contributing to more than 15 projects within the OpenStack community. Also participating in the Google Summer of Co, which is the logo in the top left. That's another really good internship that aims to get the students to contribute to open source projects. We have a brief participation. We have been trying to participate since then again. But, well, we are looking always for coordinators that are willing to step in and to help with mentoring activities. Those are not the only internship or mentoring programs that you have within the OpenStack community. The OpenStack community has participating in so many other efforts such as some internships or co-operation programs with US universities. Some of the universities that participated with us already was Northeastern University, Oregon State University, North Dakota State University and Boston University. Apart from that, which are the long internship efforts. We also participated in other efforts which are for only one day or two days. Great Hope Acceleration is an example of that. That's a conference that happens once a year. We usually participate in the open source day. This is a really nice event that we are going to talk a bit more later. That basically helps people that maybe has a background in a technical background, but they are not really familiar with open source. So we help them to get involved with the community and to look for a way for them to contribute. Other efforts that are not on the slide, but well actually I think they were mentioned in it, are like the option training. That's an event that has been running in OpenStack for a while. Usually it's training for people that again has a background in technical background, but they are not very familiar with open source contributions and the speed mentoring. Probably you said that in the schedule for this summit. Now for moving to some other topics and some more details on our experience of mentoring. Perhaps one of the first questions that we can think about when mentoring or when talking with people that is willing to mentor, like why you would mentor. And actually we see a lot of benefits, not only for the people that you are getting involved, but also for yourself if you want to mentor. Perhaps the most obvious reason for mentoring is that you are empowering willing contributors. It is no news that when people want to get involved with open source sometimes it is not so straightforward. It's not so simple for them to join. Usually they have to face processes, tools, maybe some language barriers, sometimes some issues. And if you are willing to mentor someone, basically you are allowing them to get easier to the actual contribution part. And help them understand better and follow the processes in an easier way. And this usually it's a great thing for them because it's like you not only help them to success on what they want to do, but also you connect them with other people that maybe willing to help them. Also well foster diversity in the community. OpenStack has been historically a community that has been pretty diverse. I'm talking about geographical diversity, cultural diversity languages, time zones. Like it's a worldwide community, but most of us are here because we are working in a tech company or we are in an organization that use OpenStack or some project within the opening foundation with a technical background. With mentoring we allow people that maybe are in the school or maybe they don't have a background, a technical background to actually learn about it and to make their first contribution. This is also the third reason I can mention. Because of this diversity, because these different views that we bring up in the community, we get really fresh ideas, really diverse point of views. And sometimes it happened for us that we have been working for so long in a specific task or a specific problem. And we would get a new comment saying, hey, have you thought about this or have you thought about that? And it's for us like, yeah, it's a good idea and thank you so much. And that's how we make them start contributing and getting involved with the community and stay with the community as well. Now let's talk about personally, you as a person, you as a professional, you get a lot of understanding of the project you are mentoring. Usually when you have to teach, at least for me that was my experience when I had to teach about something, when I had to share my knowledge about something, that actually took me to the next level of actually understanding what's going on. And it helped me to work on my teaching skills on how I communicate ideas. That's something that is not minor and I think it's something that you have to consider when taking on mentoring. This is a learning experience for yourself as well. And because of this great synergy of feelings and learning and well community that we usually have on these experiences, we are training the next generation of the open source maintainers. I have many cases in which we had interns working with us for, I don't know, three to six months. And after the internship finishes, like they say, okay, I want to continue contributing to this because I love the community, I love the people working here, I'm very excited about what I'm doing and I really want to get a full-time job in order to continue doing this. Fortunately, we had several cases in which this happened and nowadays they are maintainers of the projects that they contribute to. We would love to see this happening more often, but well, definitely something that we can discuss better afterwards, but that's our goal as well. And last but not least, this has to do with diversity again and getting people from other areas that is not in the tech field. We can recruit people from a variety of places, a variety of backgrounds. Sometimes it is not that easy to get people involved and there is a lot of offering for jobs within the communities and actually getting diverse sources of talents help us to open source community to grow. All right. Let's quickly move to what's our involvement. Again, as I mentioned, I started as an intern, continue to be a mentor and then coordinator for RITI, then I also participated in Google Summer of Code, also participated in several open source days for Grace Hopper celebration and last but not least, and I'm going to take more time. I want you to share experience, some internships with, well, actually projects with the US universities. So I, in case the size don't indicate that, I have a lot less experience with the mentoring stuff than Victoria does. We're going to these two mentorship programmes in a little more detail in a moment, but in summary I've worked with two universities over the course of the past two years, North Dakota State University and Boston and Northeastern universities. For anyone that was at the open stack or the Copersack SDK slash OSC session earlier this week, you've probably heard me talking about this and in particular you've probably heard me stalling the virtues of getting students to work on the kind of projects that we've got them to work on over the course of the past year. There's a couple of things that we've learnt from doing this. In a strange kind of twist of fate, we're actually going to focus on these two topics instead of, let's say some of Victoria's more extensive background here. The reason for this is intentional and it's because the two internship programmes were so similar but we were able to make some changes because of them being quite close together and observed the differences, the impact that those changes made. I'll run through those now in a moment, but that's the basic idea of where we're going through this. Looking at those two programmes in a little more detail, both of the programmes involved four students from Research University, the first one obviously North Dakota, the second one being Boston and the Northeastern. They both ran for three months but the key measurable metric that came out of that was what actually got landed as a result of these mentorship programmes. This might not seem like a whole lot of patches but when you consider that the amount of work that goes into onboarding a new person in OpenStack, this is a fairly decent return on investment over the course of a very short internship period of three months. That's whatever, nearly 150% increase in delivery and more importantly the amount of stuff that was left over at the end of the mentorship was significantly decreased, which for us showed that the students' ability to actually finish out patches, see them through, was massively improved between the two. We decided that we'd analyse what we did differently over the course of the two mentorship programmes. Because all good things come in threes, I've broken this down into three categories or themes of things that we did differently or things that we think you should focus on over the course of a mentorship and we're going to run through those at the moment. The first of these was your goals and objectives. I think this is probably the most important aspect of this, particularly when it comes to OpenStack. As anyone here that's either operated or contributed to OpenStack will know, it's a massive beast. There's an awful lot of stuff going on. There's a lot of prerequisite knowledge needed just to start contributing, whether it's getting involved with the IRC, whether it's getting Garrett set up, deploying DevStack and spending weeks trying to debug why it doesn't work, even we'll say in the case of students getting used to working with Linux and virtual machines, this kind of thing. While you may wish to say we want to go and add mega feature X to whatever your project is, that's probably not going to be a realistic in the kind of time spent that you typically have available for a mentor or an intern. Instead of adding feature X, we found that if you constrain your scope and you think more in terms of add this little feature to the SDK or to the project, add another feature, add another feature and build it iteratively, it tends to give you a nicer feedback loop and it means that the students feel like they're actually making progress and you as a mentor, you feel like the students are making progress and you're helping them out basically. The other thing that's kind of important to note is, we'll say, your objectives and your goals should be very clear from the outset. We made this mistake in the first round of mentoring. We said, OK, these guys are going to work on OpenStack SDK and as anyone that's ever worked on OpenStack SDK will know, there's fewer layers in an onion, like it's a very complex beast, partially as a result of its heritage being two projects munged together and partially as a result of the fact that it has to obscure differences between all the APIs of the various OpenStack services. By basically ensuring that you're very clear in your own head about what the students or the interns should be working on, you'll make your own life easier and you'll make their lives easier. They have something to work towards. Finally, on this point, I mentioned about even the inability to, or the inexperience with things like Linux, make sure you try and set up the right tools and decide on what you're going to use ahead of time. If that could be something as simple as deciding to use Google Calendar to set up monthly or weekly meetings with them, we'll go into that in a moment, using Jitsie, BlueJeans, Google Meet, whatever you want for video covers in, providing a DevStack instance to try and help them avoid having to deal with all of that, even things like setting up an IRC bouncer, if you have an IRC ZNC instance or something, give them access to it, tell them to use IRC Cloud, that kind of thing. On the second kind of theme or category, communication, we found that communication is ultra important, especially at the beginning of the project. This kind of makes sense when you think about it, but it's something that we found people can often kind of skip over. Expect these things to be very high touch, especially at the beginning of the project. All of this knowledge that's in your head, you need to somehow get it out of your head and transfer it into the students or interns head somehow. So that's usually going to involve talking with them very often. Ideally at least once a week and occasionally more. You might need to schedule one-to-ones occasionally. You might need to schedule, I would say, ad hoc things if the folks are stuck at some particular topic. You should try and write down as much of the stuff that you're doing as possible. So I said earlier about having clear objectives and goals. Write those objectives and goals down. If you've done some research to figure out how the guys should work on this particular area, write that down somewhere, how you came about that information. You can use a blog, you can use etherpads, you can use Google Docs, whatever works, just make sure it's written down somewhere. And then a final point, trying to get everyone involved in your own internal conversations and then if possible try and get them to start talking to the community. If you've got people working on Cynder, if you've got people working on Manila, whatever, you may be acting as the mentor for these students or interns, but there's a good chance that there's multiple other people in that community that are more than happy to help whether it's with reviews, whether it's with just general feedback, point them to documentation on coding standards, whatever it is, get them involved and then also make sure that the students and interns are talking to you. You can often go into a meeting, you have four interns there and one of them is doing all of the talking. Try and drag in those additional people, make sure that they're not keeping quiet because they're stuck or they're embarrassed to talk. These are all really important skills. As anyone that's contributed here knows, sitting quietly in your corner and working on your own thing isn't very productive, you're much better to go and write your specs, try and kind of build advocacy for features or bug fixes, this kind of stuff, regular communication is really important. And then third, the final point is kind of the general process stuff. The key point here is feedback. So remember that these students and interns, they're in the same position that you probably were whenever you started your career. And there's going to be stuff that you'll have learned along the way that is generally going to be useful to impart upon them. So give them feedback if you think they're doing stuff that's really good. Let them know if you think they're doing stuff that they should possibly improve on. Make sure you let them know about that. Especially if you're mentoring students from a university perspective, there's a good chance that professors or lecturers will come looking for this feedback afterwards. So ideally you don't want to get to the end of the three month or six month period and have to be given this negative feedback that such and such didn't get engaged or they struggled for too long because they weren't giving that feedback over the course of the internship. You also need to make sure that you set aside time for this stuff. I said earlier about setting up at least weekly meetings, particularly at the beginning. But remember if they're submitting code or even documentation fixes, you're going to need to spend some time doing reviews. You can obviously lean on the broader community to do this, but as a mentor, you're the first person that they're going to reach out to for this. So make sure you set aside an hour or two a week. The flip side of that is that you don't have to do everything for them and it's probably not healthy for them to have their mentor as a crutch. Try and set some limits if needed. If you have a student or an intern that's reaching out to you on a regular basis or worse expecting you to write code for them, try and push back on that or do push back on that and make sure that they are learning from this process and you're not just doing everything for them. Finally, stay professional and remember that these folks are potentially your future colleagues, future friends, and it would be nice to be able to work with these guys in the future. Again, they're in the same position that you were in at some point in the past and try and show them the same compassion and decency that you would like shown to you in their position. So these are just a couple of the key, we'll say, learnings and points that we took out of these. But there's a lot more, I'm pretty sure anyone that's in the audience, probably if you've ever been involved in this, have your own ideas. Feel free to catch Victoria or I after this and we'll be happy to discuss it in a little more detail. All right. So those are great tips for sure. I really share some of them. And it sounds good. It sounds easy. Now it's like, okay, how do I get started? As mentioned, we're getting back to this slide again. There are so many efforts available in the opening for community that you can actually join. Our reach perhaps for me is the more familiar one. We are going to cover that quickly now. The US University is one as well as a very good opportunity as well. And a great hopper celebration for those that may be kind of the four right now to spend three months or more mentoring. It's a great way for you to have your first experience on mentoring. So I'm just going, all these slides has a lot of information. The goal of this was for us to leave some reference so you can check. So I'm going to quickly cover this, but you can get the slides later and check them out. O'Ritchie has currently a round happening right now. We got two interns working for OpenStack, one in Manila, one in Neutron. And this internship goes from May to August. But there is going to be a next round, which is going to be by the end of the year. The applications usually start on September, October, and the internships go from December to March for the next year. Applying as a mentor is not complicated. Basically, you need to think about a task that can be done in a three-month period and apply yourself as a mentor. Commitments, well, I'm going to refer to the advice that Stephen mentioned. This is very flexible. You're going to probably pick whatever works best for you. But we advise that you keep communication fluent and you have meetings regularly with them at least once a week and you help them to get connected with other people in the community to actually fulfill their contribution. All right. Going to go over the university universities. Usually, we get notifications about these internships on the majorities in OpenStack annals. And, well, these internships vary depending on the university. It can be from one semester to two semesters. And these internships work differently to Ritchie in the sense that normally we work together like with several mentors. It's not you mentoring one person only, but a couple of mentors say three or four mentors mentoring a group of three or four people. And finally, the Grace Hopper Celebration Open Source Day. This is an event that usually happens September to October. I think this year is going to be September from 2020 to 2023. Registrations are not open yet, but we are still looking for a mentor for this event. This one works very similarly in the sense that you have to think about a task that your mentee has to work during that day. You will need to get something for the event and prepare for a program with this person and do a really quick onboarding to the community, to the tools and to the issue that you want them to fix. Last but not least, this is also an open question for you. There are other opportunities that we know. Do you know any other one? If so, please let us know. But we have been looking again into Google Summer of Code, for instance, into also the season of docs which is very similar to Google Summer of Code, but obviously focus on creation for docs. Hacktoberfest has an internship, but we are researching on these ones. We want to learn more and we want people to help us to participate in this. If you are interested, please let us know. With that, I think that's a wrap up. I don't know if there are questions or comments or I think we have four more minutes. If not, you can catch Victoria and Eli anywhere in the corridor for what's left of this week. The question was, I spoke about the worst case scenario where you'd have an intern or a student that would expect them to write the code for you. What would be strategies for avoiding this? In my case, and I'll let Victoria speak to this in a moment, in my case, it was pretty much discussing it with the student, discussing my expectations around what I expected from them, providing written material where possible and basically just any time I was asked to write code, pushing back on it, points in the right direction and stuff. Don't do it. It was my solution. I'm sure there's probably a clever strategy. I ran into that a couple of times as well. It's hard to push back. You have to be quite strong on that. Something I have to... Something I tried was to actually pair a program with this person. I would say, okay, we can code together. I'm not going to write a code with you. But we can work together and I can follow what you're writing and we can think together on how to get this done. Usually, sometimes, the first time you do that is hard because you actually need to be very clear on what needs to be done and try to encourage the thinking on the outside. But after they get used to the workflow, it's a bit easier and they actually learn how to do things. One other key point on that is... I didn't mention about communication between mentors, but that's also important. Artem was one of the other mentors in both of those programs. It was only after the first program wrapped up that we actually discussed this and we both realised we'd had the same observation, but we'd never communicated that with each other. We were careful to do that then in the second one. That way, we can give consistent feedback to the particular student. The question was whether there'd be a particular type of feature or bug that should be preferred. How would you go about choosing your work, I guess? The biggest thing is to constrain in the scope and choosing sensible features. Adding some feature that would take you six months to do isn't viable, obviously, for a three-month internship. It still isn't really viable for a six-month thing. We'll say you want to add this feature, try and think of the minimum viable products. What would you do, APIs? In general, though, choose something that's somewhat interesting, that's comprehensible for somebody that's not playing inside baseball that isn't knee-deep in neutron code and stuff. It's somewhat exciting. Something that they could see is usually beneficial. I must? I agree. What he's saying is that it's generally more interesting to work on new features as opposed to bugs. It depends, like, how do you want to clarify it? We'll say close in the open stack client gaps. That's arguably a bug, arguably a feature. It's somewhere in between. I think those were quite useful because they were very visible. You could run your tests and stuff and you could see actual API responses and stuff. Fixing off by one errors and stuff is probably less meaningful. Bug fixes can be interesting. It's very subjective and probably up to your own experience and verdict on it. Usually wish list tasks like enhancements to something that already exists that we often say, maybe this would be great, this would make usability better, this would make, I don't know. This would make this feature way better, but we don't have enough time to work on that. Those usually are great candidates for these kind of tasks. Open stack client again. Perfect example of that. Everyone likes it. Nobody wants to do it. We're at time, so we might wrap up there. Feel free to grab us afterwards if you have any questions and enjoy what's left of the summit. Thank you.