 Please welcome Julie Pichon and she's making a talk about how to contribute to open source Thanks a lot. Hi everyone Thank you for coming here this afternoon. I hope you're here because you think that open source is awesome like I do First time I created this presentation about just a few years ago. I kept hearing people who are considered to be very bright And I have a lot of respect for what would tell me. Oh, there's no way I could possibly ever contribute to open source and I Had only a couple of first time contribution in a couple of projects or not that much, but I still thought You know you're wrong and I hope I can show you that it's not that difficult and and Just maybe plans a seed of an idea that yes, you too can contribute to open source So let's see what we have in the audience at the moment who's already contributed to open source before maybe a patch or a translation or a bug report Okay, cool. So So Maybe you should consider using the Q&A session as well for sharing your own tip for people who would like to become open source contributor for the first time ever, please feel free to and In the meantime, I'm going to describe the process for contributing for the first time It's a short session. It should be around 15 minutes Because really contributing to open source is not that hard and I hope this is what I can show today So Normally, I start this talk by giving people a handout So I thought I would check how big the room was that I was speaking in and after a few moments of panic that had no relation to printing I decided not to bother this time. So you're getting a PDF It's a tiny URL.com slash EP dash open dash source and it's a summary of what I'm going to talk to you about It also has a few projects that have a good reputation for being Being friendly to new contributors. Some of them are in Python. Some of them are related to Python Some of them are not And there's also a link to a transcript if you prefer reading to that whole listening thing A tiny bit about myself as I said I have a few patches in a few projects. I was kind of First time contribute serial first time contributor where I would make a contribution to a project and then run away in happiness for a while And then about 18 months ago I joined Red Hat and now I get to contribute to open source every day Which is pretty cool and it also means I've learned a few more things about open source communities that I hope I can share With people who are hoping to to make their first step as an open source contributor Okay, so Who is this talk for it's for people who love open source and would really really like to give back But they're not sure how to do that. They're not sure how to start They're not sure if they're smart enough or if their skills would be valued And my goal today by standing in front of you is to help you make the jump from a 0 to 1 Contribution or maybe plus one if you raised your your hand earlier So let's clarify something very important first Everyone can contribute You do not need to be a genius to contribute. I am most definitely not a genius all kind of skills are valued and All at all levels as well. You don't need to be a super mega hardcore developer You don't even need to be a developer at all And you definitely don't need to have ten years of experience in whatever technology in order to be able to make a meaningful contribution And So I'm going to tell you Where you can start I'm going to First I'm going to tell you about what I like to call a wonderful shortcut and then we're going to see how the workflow usually Works like so who is familiar with open hatched at work Well, that's very few people I hope if you forget everything I mentioned today, please just remember those guys because they are absolutely Absolutely wonderful Open hatch is an organization whose mission statement is actually lowering the barrier to entry In open source project for newcomers and they do a lot of wonderful work and they are very friendly people The way they do that is that They have in person workshop in the US They go to universities to teach students how to contribute and they also have This website where they try to bring together a lot of small Burgs the small tasks that are good for newcomers help requested help wanted also people who are willing to mentor people who are starting out and They also classify all that stuff by project and by language So sometimes if you want to start learning a new language and do it in a useful way You could do worse and go to open hatch.org and Pick an open source project that's in the language you're considering learning Okay So now the way it usually works Even if you've used open hatch you might want to find the contributor guidelines for the project you're interested in contributing to That should The reason it's important not every project has them But I think for your very first ever contribution you want to find a project that has contributor guidelines Because it means they've thought about it and they care they care about new contributor coming to help them And what reading the contributor guidelines will will give you is that it's going to give you a sense of direction You probably have an idea of the kind of contribution you'd like to make but you don't know where to go to do that The contributor guidelines will tell you it should also give you an idea of what matters to the project and Maybe also some idea of what to watch out for maybe they have very strict guidelines for how to format your patch So read them. Don't try to remember it all. It's just giving you a general idea of what's important to the project So here's an example that's from the open stack contributor guidelines I'm gonna use it as a Python example through the presentation, but It was on my very first contribution to open source ever So they have a lot in the week he's a the care and it's a complicated contributor process, so it's good that they try to to document it Otherwise that's how the process usually looks like for contributing Even if there's no contributor guidelines most projects kind of follow the same workflow So first you read the guideline if they exist Otherwise you just go to the bug tracker to find something to walk on or maybe you already have an idea because You found a problem in a project you like and you would like to help with fixing it So find something to walk on then you build a software and Then you find the bug fix it and submit the patch. It's easy peasy, right? So we're gonna go through a bit more details for each of these things. We've done the computer contributor guidelines bit So no the bug tracker This is a short Extract from one of the open stack bug trackers and it's about bugs that are That have the low hanging fruit tag a lot of project especially when they get larger They start marking bugs that would be good for new contributor with a special tag It might be low hanging fruit or it might be bite size or easy peaking or No, love and you learn that stuff by reading the contributor guidelines because this is where they will document it So have a look through this task for a first bug for a first contribution to a project usually having a very small Contribution is good because you have a lot of other things to learn which we're going to come back to and Before you come with your seven new features that refactor have the entire project You also need to build a bit of trust with the existing community and just pick up the conventions that are not necessarily documented anyway So you know what you want to work on so if it's a big project you also know which components you need to build now So you need to find the instruction for how to build it usually it's on the project page or Maybe it's gonna be in the contributor guidelines If you can't find them in my opinion if a bug is marked as a low hanging fruit or whatever new common tag is There's kind of an implicit mentorship offer in that That is if you come back to the bug and ask a question saying I'd tried a B and C But I can't figure out how to do D to build the software Can you help me people will expect this kind of question if it's if it's a bug for newcomers? So don't hesitate to ask Something else you might find is that maybe It's documented, but you don't understand all the steps So now would be also a good time to go back to open hatch because they have this concept of training missions Whereas they explained some of the tools that open source developers maybe forget They had to learn in the first place because it's a good nature now So just use open hatch as a stepping stone learn when you what you need to and then you can come back to to building the software So once you've done this build a software from source you can try to reproduce the bug that You picked for yourself and and fix it In my case That was my first bug in open stack ever it was a one-liner. It wasn't marked as a low-hanging food, but it could have been Just kind of Focus on code in this talk because I'm a software developer and that's what I'm familiar with But it doesn't mean that other types of contribution are not valued or welcome on the contrary So please don't interpret this example in this way So that's what a low-hanging foot might look like in open stack as well You'll see the tag in launchpad and you'll also it might even they might even tell you which file The the bug is actually located in so you don't have to learn the entire architecture of the project Just to figure out or to fix maybe a typo or something very simple So another price for low-hanging foot if you're not using them in your project, maybe consider doing it And It's time to submit your patch. Maybe, you know, don't do it just yet You want to make sure, you know, it's tested and all that but also you might want to come back to the contributor guidelines because this will tell you what your patch should look like and Maybe even one what command you should use to format it some projects are very picky But which gate command you used format your patch and then the contributor guidelines should tell you where to send it as well If they don't tell you where to send it usually attaching it to To the bug report is a safe bet Yes, so congratulations, you've made your first open source contribution it wasn't that difficult, right? So take time to congratulate yourself because that's pretty cool You know the real next step which I didn't mention in In in the contributor process is that you will have to wait Sometime quite a bit of time And then one of three things might happen Maybe your patch will be accepted straight away because you picked a very simple Contribution or rights is not much that could go wrong Maybe you'll get some feedback and if it makes sense to use and take it into account and submit a new a new version of the patch and just interact with the community and The third response that is probably just as likely that you will only hear silence It will sound like your patch is lost in the hit area and you're not quite sure what happened don't be discouraged and After a couple of weeks, it's usually okay to start pinging people and asking is this normal? What's happening? Should I do something different? In my case, I was lucky took about four days for my patch to to be merged But I really want to come back to the fact don't let yourself be discouraged if you don't get an answer Instantly the one rule I think of all open source project saver is that there's never enough people to help There's never enough time to do everything that needs to be done and the healthy project knows They know that they need new people they are rooting for you to stay because a healthy project needs new blood to stay alive If you do get an answer and it's not very nice Don't be discouraged and don't stick around either. It's just not worth it There's a lot of communities out there that would really like to have your help on your skills if people are just a bit Nasty, there's no point in staying there But really most people are nice my experience in open source has been that most people are nice and because you'll have read the contributor guidelines and you'll have done all you can To do things properly. They won't be any dragon. It's It's it's going to be okay. Oh Oh Yeah, something else I learned later on when I just started in open source I thought you weren't supposed to talk to anyone until you had like 17 patches accepted and you had proven yourself as Someone who's totally awesome technically, but it turns out that's not true It actually helps if you try to interact with the community as you're starting to contribute And it's gonna make the process a lot easier both for you and for the people who are Reviewing your patch if they know you and they know you can take feedback with a coming upset And it's just a lot nicer for everyone basically I had forgotten about the fact that it's open source communities It's not just open source. So Yeah, try to involve yourself With the community as well maybe idle on ISE and chat with people read the mailing list And if there's a meetup close to where you are Ah Talk to people Okay, so I Spoke too fast again if you forgot everything reminder open hat.org or some people very friendly if you have any question you can send them email They're they're a really great bunch who are entirely Dedicated to helping newcomers find their way and is there any question already or any tips to share for people who already have a lot of some experience contributing to open source from Can you come to the microphone maybe? Thank you. Thanks for your talk This might be a bit of an advanced topic, but do you have tips for people who ask you Where can I learn about how to collaborate on github because I find get Utterly confusing and I'm a long-standing developer So do you just mean how to learn how to use github itself or yeah, because for example nobody tells you that in most Projects after you clone the repository you should branch. I Had to find that out on my own. Yeah, I would hope people would describe that kind of information in the contributor guidelines I don't know to what level of details and information the open hatch folks going to in the training mission but I think they have stuff about that and the The way it usually walks in open source and I agree it would be useful because people usually just tell you if you don't know Get here as a good tutorial, but that doesn't necessarily tell you about the culture that the project is using so if You contributed to a project that expected this and they didn't do it I would say help them improve their documentation by adding it to it or filing a bug about this because that would be helpful I agree. Yeah, I have to admit it was kind of a rhetoric question. So If you have contributing guidelines, not only describe well, we use github, but Put in the actual commands you have to use to make your first Pull request. Yeah, a lot of people learn about your project, but also about github at the same time So that's that's a lot to taking Thank you. Hi Yeah Thanks for the talk and From my first-hand experience, I would say a very good way to get started is also to attend the sprint and just to talk to people Which are sitting next to you. It's the easiest and the fastest way to get started So everybody's invited to sprints after the conference if you're staying here for the weekend Yeah, I second that recommendation usually you have core contributors of the project You're interested in attending the sprints as well And it's very cool to get jungle advice from someone who's been working on it for years and years and things like that So yes, come to the sprints. It's gonna be it's gonna be cool Okay, if questions come to your mind later, feel free to find me and I'll try to answer as best as I can Enjoy the rest of the conference