 Welcome to our talk, becoming OpenStack Developer while Outreach. This talk is going to be presented by all the participants. I'm Aya Yautava and I will participate as an intern. Hi, my name is Richard Pioso. I'm an industry engineer. My name is Dmitry Tansur. I'm an OpenStack Developer and Outreach mentor. My name is Ilya Yatongov. I'm also OpenStack Developer and also a commenter. In this internship, in this talk, we're going to tell you about the Outreach program, what is it all about and why we decided to participate in it. Excuse me. Can you hear me? Thank you. So we're going to tell you about the Outreach program and why we decided to participate in it. We're going to share our experiences and lessons learned. And finally, we will think about why this program may or may not be good for you. Much like in medieval European trade guilds, as well as probably today's science, the software engineering profession seems to benefit from some sort of apprenticeship before one can fully attain the professional fluency. Other than that, Red Hat builds its business on open source and therefore it's one of the strategic goals of Red Hat to help building, promoting open source and growing open source engineers. One of the, or maybe the main focus of Outreach program is to promote diversity. Right. Promoting diversity is a core value of OpenStack, Dell EMC and Red Hat's cultures. Not only does it, not only is it the right thing to do, it also produces superior software and business results. On top of that, we are open source engineers ourselves. And this is in our direct interest to promote and grow the culture we enjoy and being part of. So what is OpenStack? OpenStack is a large, well-established and highly collaborative open source software engineering project. At OpenStack, we value quality engineering practices, mutual respect and continuous learning. The goal of the OpenStack project is to produce free and open cloud management and infrastructure software. The first reference on the slide provides a bit of OpenStack history. And the second reference defines the OpenStack way, which is it's for opens. Open design, open development, open source and open community. If we look at Stacklytics, which is the bottom reference, you can go ahead and obtain interesting statistics about the current development cycle, which is named STYNE. Outreach is a project running under the software freedom conservancy organization. The idea behind outreach is that it brings together the open source projects that seek contributors, the mentors and the interns to build free software. The focus of outreach is to promote, ensure and help out groups of people, typically underrepresented in the industry. The way how outreach works is that the interns get on board of a typical large and well-established open source project and start working on some feature or on some part of it. Each intern typically gets a mentor that is a person experienced in this software and in this community, sometimes more than one. And this is a paid internship, therefore the intern has the ability to focus on this work. There are many reasons why to become an outreach intern for those who have little or no experience, it's a chance to try out different parts of IT related fields like programming, documentation, design, and to see if they are a good fit for that. Also for those who have some little experience, it's a way how they can start contributing to free and open source software that they have tried before for variety reasons and all of them can learn and work with people from all around the world and in the projects that are not available locally. And finally, it also can help to get a job. It can help to build a digital portfolio that can be shared with prospective employers, which is not always possible when working for other companies that cannot share their work with the outside world. So why would you become a mentor in outreach? Well, first of all, to contribute back to the communities that helped you grow initially, because community is really about contributing and contributing not only the code, but also helping the community grow and helping grow in a healthy way. And mentoring new members is an essential part of a growth and mentoring a diverse community is essentially part of its health. It also helps you personally to grow professionally and personally because you learn things better when you explain them. And working with newcomers helps you looking at your project from competing new angles, seeing what is hard, what is easy, what is complex, what is straightforward. And of course, you get more people to work on your project as well as a benefit. How it all began a little about me. So I'm a software engineering and I have experienced building enterprise information systems in C sharp and Java, but I always used free and open source software for my personal needs. And when I decided apply for outreach, I had to decide how to select the project. And so I decided to try something new, something that I haven't done before, but it had to be in familiar programming language because many projects required some proficiency in the tools used. So for me, the best chance is very with Python. And another criterion was we have mentors in the same or similar time zone. So so that I don't, if I get stuck, I don't have to wait for way too long when they come online. But this was like nice to have. And if I couldn't find matching project, matching all my criteria, I would drop this. Then open stock project, match all my criteria and I started applying. I had some issues with my initial ticket, like the long story short is that I didn't in the final submission, there was no code submitted. It was just documentation updates. So I wasn't able to really show my programming skills. Another different thing when applying was transparency in seeing that there are other people supplying. So I was able to see how many there are, how they are doing, but generally I decided not to pay attention to that, but focus on my application. And speaking about successes, apart from me being accepted, it was still good that despite my challenges with the initial ticket, there was a dedicated list of tickets for outreach applicants that they could start using. So a few words about open stack itself. It's not an easy project to contribute to. It's huge. It has a lot of code and a lot of projects comprise open stack and they all interact in non-trivial ways. The development workflow takes time and effort to learn. And of course, it's hard to just completely impossible to run open stack at home, for example, on your laptop. And on the social side of things, as it always is with big projects, the core team is overwhelmed, they have their own priorities, don't always have time for reviewing your patches. So code reviews can be really slow, days, weeks, months. And feedback, there are always differences in the way feedback is given or received. Some people are more polite. Some people are more direct. Some are way too direct. Some people are just burned down and they cannot express themselves very clearly and particularly newcomers are prone to taking this feedback personally, which also takes some work to come over. The outreach program rules is that every cycle starts with a so-called application period. During the application period, the prospective interns are supposed to work on a project of their choice on a ticket, I would say, of their choice to prove themselves and to get the feeling of the work they are signing up for. Mentors are supposed to provide the interns with those test projects. After the test project is done, it is in the power of mentors to rank the participants and pass the outcome to the organizers for the formalities and budgeting and things. With OpenStack, apparently it was difficult to find this isolated, more or less trivial tasks to offer to interns. But other than that, it's hard to fit the development workflow within the application period with OpenStack because of long reviews and all these social things. It's also important and hard to make sure that the work you are proposing to do is aligned with the upstream community goals because if it's not, then it won't attract any attention for the reviews. As mentioned, code reviews in OpenStack projects are very demanding and they question every single bit. So the way I handled it, first of all, I didn't take it personally. I remembered that I am not my code and reminded that myself regularly. But I shouldn't go to the other extreme. I still need to take responsibility for the code I have written. I still need to engage with the feedback and work with the team to make the code the best as it can be. Another thing that helps is to recognize that code reviews are an essential part of programming. When I'm working on code reviews, I'm still being productive. And it's not like the only productive time is when I'm actively writing a new code. And the last thing about code reviews is it was a great chance to learn many new things that otherwise wouldn't come up. And even if the things I learned didn't end up in the final submission, they still can be handy in the future. The next thing about learning new things as the domain was very new to me was asking questions. And I needed to find the balance when I'm asking questions too soon and when I'm trying to figure out my it myself for too long. If I spend too much on the questions, then I'm wasting too much time. And the last thing is working from home remotely as outreach is a remote internship. It's an important part of that. And people need to be prepared for that. It helps that the person is a self-starter and it also goes together with motivation why you are working on the project. Are you excited about it? And that's why it's very, very important to choose the right project at the very beginning and also it helps if there's a dedicated place to work, a room or a corner room, a local library. And still working remotely communication is very important. So regular conference calls helped a lot as well. So I'd like to present a case study. Industry is heavily involved in open stack and influential in standardization efforts. The standards body in this story is the distributed management task force, the DMTF, which creates open standards for managing IT infrastructure. One of its newer and evolving standards is Redfish. A RESTful API for simply and securely managing converge hybrid IT in the software defined data center. The DMTF Redfish Forum, which performs the standards technical work, was interested in promoting Redfish in the open source community. Separately and in parallel, OpenStack's ironic project was implementing support for Redfish to provision bare metal servers. Its developers, including Aya, were facing challenges and found the standard specifications and related documentations, documentation not always ideal. So for example, there was confusing or lacking detail, don't figure. And the industry vendors, including Dell EMC, are contributing to both Redfish and Ironic. They introduced the DMTF Redfish Forum to Ironic and the Ironic leaders to one another and established a collaboration among all three communities. In the trenches writing the code was Aya. And like many young engineers, she may have felt hesitant to reach out to the technical experts, those that had authored the Redfish standard. But now, as a result of this collaboration, they were working alongside her towards a shared goal. Aya's experience has been fed back to the Redfish Forum about what helped to clarify and improve the technicalities of the standard. Also, what helped set up the ties between the three different communities and she with them. And also, it's taught and what taught Aya how to negotiate intricate and complicated technical issues with the community and with fellow engineers. Through Aya's successful internship in three communities, industry, a standards body, and an open source community, tore down silos together and jointly furthered one another's goals. So if you have who tips how to be a better mentor, first keep you in turn, always busy, always challenged, always keep in touch with your intern. Make sure they never get stuck, especially for a long time, no longer than one night. Have them keep focusing, focused even in case of, for example, slow reviews when it's very easy to lose motivation and to lose focus. Have them do their own planning, encourage small steps and recognize small successes and make sure they recognize their small achievements. Another important thing, help them network with the upstream community, introduce them to other community members, introduce to the team leader, points to a few contributors that can help them as well. Make them involve, make the interns involve in cold reviews of other patches. It's a great way to overcome fear of feedback and of course to learn the project itself. As a mentor, you have to understand the different psychological settings, help the interns overcome the biases, help yourself make sure you're not biased, help grow this unbiased setting in the community. It's helpful to see yourself, you and your intern as colleagues or co-researchers other than some master apprentice set up because in the end it has to be fun. We think that when we deal with the prospective interns, it seems that when the intern is genuinely interested in the technology, not just as a prospective work, but just for the sake of it, it's a good sign. Another good sign is that when they come prepared and well understood, well understand in the project they are signing up for and why that project might be a good match for them. And finally, one can't be to essential about the way how open source community works because as Dmitry mentioned, some feedback, some code review can be harsh. The code can be abandoned or reshaped in any possible way. And therefore it's good when the intern is prepared for such kind of development. So I'd like to encourage you to come join us. We've had experience with the internships and we found them to be mutually beneficial and useful. If you're someone who's new to the field and intrigued by getting involved in a respectful open source community, please join us. If you're part of the community and interested in building the team and getting more helping hands involved, please join us. If you're a vendor or involved in a standards body, you can go ahead and have your products and standards specifications verified. So please join us. And there are a couple of references up there. The first one is refers to outreach communities or communities that have been involved in an outreach. And you can go ahead and find those communities if you're interested in joining us. And you're also encouraged to go ahead and propose the addition of a new community to the Outreach Internship Program. And the second reference for OpenStack lists or basically describes OpenStack specific involvement in outreach. So please come join us. If anyone has any questions, we're reviewed. And they were sponsoring together with that with Victoria, an analysis of the gender diversity of OpenStack. So one of the results we have, and we were analyzing all of the outreach interns, was that if someone is mentored, the time they remain contributing to the community is higher that it compared to the average of the community. So it seems that if someone is mentored, it will remain for a longer time. So we are talking around 18 months in average or in media, I don't remember the numbers. It compared to the usual average of the community. And these are great numbers. Of course, we are talking about different populations because in outreach, they were like 40 people and we are talking about thousands of developers. Right. You know, OpenStack. So we need some scientific approach to this. But those are the first numbers and those were quite interesting here. And the question I have for you is, can I just interrupt you if you have any questions? We are all the time, so, basically, question? Sorry, we are... Can you move it outside? Yes. That's okay. Thank you. Thank you. Squidule is kind of busy, so... That's okay. Thank you very much. Thank you very much for your question.