 My name is Arnoldo Melo, I'm a senior principal software engineer at Red Hat, and I'm Brazilian, I work from home in the Brazilian Northeast, you can see a focal of my backyard. So I've been working with the Linux Karma since 1998, a long time ago, and during this time, lots changed in this community. People came and people went, and the number of developers grew, and there are places where Linux has been implied as well. I started working with networking, and doing changes to the TCP IP stack to make it use less resources and scale better. And nowadays, I maintain the Linux observability tools, which is something that I will talk a little bit more in this presentation, as it is a way for you to learn how the various projects work by inspecting its internals. The interesting part that I've learned all those years while working with others is that you interact with people from lots of places, and the way that they think and how they expect things to work is different across lots of places. We have to try and observe how other people interact when working in these communities, see how they interact, and see how they submit patches, see how the reaction happens, and how they react to that, and learn from reading those conversations. It's one of the great aspects of open source that everything is discussed in public, so new comments can come and see how features were implemented, but was the interaction of the developers, and from there I learned a lot from the process. Where to start? Well, you can be working for some company, and then somebody will tell you where to start, but if you are interested in getting to an open source community, the best advice I can give is try to find something on your computer or in your smartphone that you don't like, that you would like to work in some other way, something which is not working. So, after that, you should try to locate the source code in the usual places, Google, GitHub, and then you can look at the source code, and if you know about that specific language that is used to implement that project, then you can already start to find where that thing that you want to fix is implemented. Another advice is to use observability tools, such as profilers, tracers, and the buggers, so that you can see what are the main functions and what are the main sequences of events that lead to that function, and just by looking at it, and especially looking at it when what you think is broken is happening, may help you in pinpointing where to try to work on your things. And when doing that, you may find problems, all the problems, as no code is free of bugs, so consider trying to fix things as you learn about the project that will bring good will from the maintainers, from the developers involved in the project, for when you decide to submit your new feature or the fix you started this process with. How to submit your work? Projects have documented processes, you should look at the source code for them, and then you're going to find how to submit, where to send your patches, to whom, who should be on the CC list, and most projects by now have also a code of conduct that you should read and see how what's appropriate and how to deal with the other developers. And please try doing it in baby steps. The smaller the patch you send, the better. I mean, if there are multiple things to do to get to your fix or to your new feature, you should just try to write as small as possible patches that go on building and eventually get to your objective. Because this is easy to review by the maintainers and by the other developers, you just have to look at the patch which is small, and then you see, oh, this is okay, let me go to the next one. And it helps finding problems later. Using a process that's called by section, where you utilize tools to do a binary search. You know that the first version works, and now it doesn't work. So you go to the middle in terms of change sets, in terms of patches, and try there. And then you go on saying that this works, it doesn't work, and you get more quickly to what was the change, or this problem was introduced. But what if people didn't like my patch? Well, should read a response, try to clarify things, perhaps it was not clear. When you first submitted a patch and then with some clarification, it may become acceptable. You should affect problems. Sometimes you made a mistake, or it didn't consider some specific case. So you should read the problem that were reported and addressed on. And then it should resubmit. Usually you send a new patch set, a series of messages, and then on the cover letter, on the first message, you say that's the second version, and on the cover letter, you describe what were the changes that you made in relation to the first version that you submitted. It's all about making progress. Sometimes the maintainer will not process all the patches, accept all the patches that you sent, but then it can apply some of them and share it picking, so to say. Some more recommendations. You should discuss publicly. It's not interesting to send messages in private mode, just to one person. Sometimes the developer doesn't have time at that moment, and then somebody else on the mailing list may jump in and help you. And sometimes even have more information about that than the person you thought at first should be the one that would help you. Be patient. As I said, you sometimes people are busy with all this stuff, and then can reply as fast as you would like. Don't be afraid to ask questions. It's just try to formulate the questions as clearly as you can. This is an interesting process because sometimes all the people who are reading that conversation learn by seeing the answers to your questions. And also consider participating in conferences. With the pandemic, most of the conferences like this one is being done over the internet. And the good thing is that the previous conferences are available on YouTube and places like YouTube. So please consider as well looking for previous recordings for things that you have interest in. So with this, I pass to Kate. Hi. My name is Kate Karsha. I'm an associate manager at Red Hat on the core Kernel engineering team. I myself am new to open source, but my team is very active in the upstream Linux Kernel community. So although I'm not making direct code contributions, I learned a lot about open source by supporting a mix of engineers, some of whom are very experienced reviewers or maintainers like Arnaldo, as well as engineers who are new to the space and want to get more involved, more like myself. And as a manager of a team that is working in open source communities, and as a woman in tech who is passionate for diversity, equity, and inclusion, I'm always thinking about how can I help to make open source a more accessible place for everyone? A 2017 GitHub study found that 3% of developers in open source communities identify as female, 1% identify as non-binary, and the study didn't look at race or other diversity groups. There's a lot of work that we have to do here. And so today I'm here to share with you, whether you be a manager or an aspiring manager, or maybe an individual contributor that would like a window into the world of management, how you can help at through some strategies such as hiring, mentorships, and work assignments that helps to make open source a more open place for everybody. The first strategy that I want to cover is about hiring for potential. So let's think about what potential means. Potential means having the capacity to become or develop into something in the future. So hiring for potential means that we're hiring people for their capacity to develop the skills that they need to grow successfully in the role, rather than hiring for the experience that they may have in doing the work that's required by the role. By hiring for potential, we want in the pool of candidates that we consider for open positions. And this enables us to add new capabilities to our teams, and in turn, add new capabilities to the open source communities that our teams work in. Now you may be thinking, well, how could you hire somebody if you don't at all consider their experience? Hiring for potential doesn't mean that we don't consider someone's experience. It's just that rather than evaluating if they have experience of already doing the job or work required by the job, we're evaluating that their experience is indicative that they'd be able to come in and learn and develop the skills that they need to do the job. So one example of this is hiring for a specific programming language experience. In kernel development, we use C. So in our case, if we were hiring for potential, one way we could do that is instead of only looking at candidates that know the C programming language, we could instead consider candidates also that have an understanding of low-level programming concepts, such as control flow or data structures, or maybe comparable languages, such as C++ or Rust. And this enables us to open ourselves up to the possibility of bringing somebody onto the team who may have a different perspective or may have something unique to bring to the table. So in summary, hiring for potential enables us to bring more perspectives onto our teams and into the open source communities that our teams work in. It's about opening opportunities for people that may not have had that chance otherwise or may not have even known that that was an option to them. Now we'll say, of course, just because you plant a C, it doesn't mean the plant will grow. And so we have to give that plant water and we have to give that plant sunlight. So in this case, when we bring somebody on and we hire them for potential, that alone is not enough. We also have to come in and help them successfully realize that potential. And that's a good segue into the next two strategies that I'll discuss, mentorships. So something that's really important as a manager is supporting mentorships. And mentoring is a voluntary ongoing relationship typically between a more senior associate, the mentor, and a more junior associate looking for development opportunities, which is the mentor. And in these partnerships, the mentor will give advice and guidance and support to the mentor. And in turn, the mentor is able to learn things that they may not have otherwise had the chance to come across if they were just working on their own. Now mentoring is really important for newcomers. The mentoring is especially important for underrepresented groups in technology. So research actually shows that one factor, one success factor from minorities in corporate America is having a strong support network and mentoring. But even more so, this research went on to find that a truly effective mentoring is not just about not just about having technical guidance or given being given direction. It's really about having a quality relationship with trust, where the mentee feels safe to express fears and concern to the mentor. And so as managers, we actually play a very big role in terms of helping to cultivate these types of relationships and to support them. So I'm going to give some tips that that I sort of follow in terms of working with folks that are seeking to be mentees and then also folks that are going to be mentoring. So for newcomers that are looking for a mentor, one of the things that I encourage them to think about is finding someone that they feel like they can be vulnerable with. Going back to what Arnoldo had spoke about earlier and his idea of learning by trying. Well, of course, if you're going to be trying something, one of the best ways that you kind of figure out what works and what doesn't is to make mistakes. And so working with somebody as a mentor who you can feel comfortable with to make mistakes, that really gives you the space as a mentee to learn. So I really encourage folks that are seeking mentors to seek out people that they feel that they can be vulnerable with. For more experienced engineers that are mentors, one of the things that I encourage is that they lean into the importance of the role. Now, of course, it is an opportunity for them to solidify their own skillset because they have to have a very deep understanding to be able to explain these concepts. But also it is an opportunity for them to leverage their experience and their expertise to help forge pathways for new people to join open source communities. And then for both the mentor and the mentee, something I work with is making sure that folks have the amount of time that they need to really dedicate to these types of relationships. It is an investment of time on both sides. And so something that makes it successful from my perspective is making sure that people have the time to really invest into it. Moving on to the next strategy is thinking about helping newcomers to identify work that is going to help build their skills, but then also build their confidence. And this is actually something that I do in close collaboration with mentors. So a couple of tips that I have regarding this is one, for somebody who's just getting started, I tend to recommend not picking up work that's going to be in the critical path or is urgent or has a tough timeline. And the reason for that is because I like to give people the chance to really dig into concepts and build a strong foundation of understanding. And if there is a timeline or if there's stress attached to something, I feel that can kind of detract from that experience. That's the one idea. The next idea I have about making sure that we can help newcomers identify work assignments is that one of my work assignments that can be broken down into adjustable chunks of work. And the idea behind this is really helping people to break down work so that they can get feedback as they do it. And that feedback includes positive feedback. Positive feedback means that they accomplish something. Aggression is actually quite motivating as well. I find that this is especially important in the case that you're working with new college grads. So research actually shows that one of the biggest struggles that new college graduates have in adjusting to the industry is the fact that there's not a lot of feedback. In college, you take courses, you have a syllabus. That syllabus has deadlines and assignments and there's rubrics that those assignments are then evaluated against. In the industry and in open source, we have so much freedom. I have freedom to define what we do, how we do it, what success means. And that freedom is wonderful. We want to harness that freedom. But helping newcomers through that transition period where they're able to learn how to manage that is really important. And so having a mentor that is able to identify a project and help the mentee kind of break that down is certainly something that can use sort of the challenge and maybe missing some of that structure. And also it gives the mentee or the newcomer an idea of how to break down work. So in the future, if they independently pick up more ambiguous tasks, then they're able to do something similar on their own. So one thing that I recommend in this particular instance is that for all of the project work, it's good to think about what is your definition of done. But definition of done doesn't always have to be a piece of code. You may break down a project and maybe perhaps some of it is investigation. And as part of that investigation, your definition of done is having a documentation that explains what your findings were. So going back a little bit to what Arnoldo said again, his approach about progressing, taking baby steps, rinse, repeat, and grow. I think that this sort of strategy of breaking work down needs really nicely into that. But then also, I think that is a great strategy to use as a manager as well. Everybody you work with is different. Coming back to the plant metaphor, certain plants need more or less sunlight or water to grow. And if it's very sunny, you might need more water and vice versa. And what I'm trying to say is that we have to be adaptable as managers to what people need and how people learn best. And that might look different for everybody. So if a project isn't working, we can change it. And if the connection with the mentor is not there, we can change it. So in summary, managers too can help make open source a more open place by creating more opportunities for people to join open source communities, by helping to support mentorships that provide learning experiences in a support network, and by helping to identify meaningful work that helps to build confidence and skills. So closing out our presentation today, we come back to the heart of what we discussed. Open means having no enclosing or confined barrier accessible on all or nearly all sides. We believe that open source is healthiest when different ideals and perspectives are included, welcome, recognized, heard, respected. We believe that open source is healthiest when it's truly open. And so hopefully you're leaving this presentation with some ideas, whether you'd be an individual contributor or a manager, and how you can also help unlock all that open has to offer. Thanks for joining us today. Well, thanks everybody for coming today. I know we're running probably a little over schedule since we had some technical difficulties, but we really appreciate all the good conversation and thoughts.