 Hello, everyone, and welcome to this session. Three steps to your first open source PR. My name is Dewan Ahmed. I'm a developer advocate at Red Hat. I'm based out of the beautiful New Brunswick, which is in the Atlantic region of Canada. I love everything cloud native with a focus on DevOps and GitHub tools. Besides work, I like to play pool and ping pong, and I'm also a freelance carrier coach. That means I help students and new grads to start their career into the software industry. The primary audience of this talk is an early professional who lacks employment experience and is daunted by the minimum number of required experiences in job descriptions. However, if you're an experienced professional and you just lacked open source experience and you'd like to get started with open source, I think you can get some value out of this talk as well. In terms of agenda, we'll start with understanding open source projects, the value of open source, outline why you should contribute to open source projects and three steps to your first open source PR. I'll end the session with some PR-press practices and we'll have time for some questions and answers. So open source is a term that originally referred to as open source software or OSS. Open source software is code that is designed to be publicly accessible. Anyone can see, modify and distribute the code as they receive it. Do not confuse open source with free software as the focus is not on pricing. I've added a link into the resource session which goes much more in detail on how open source is different from free software. Now what are the values of open source? Because the source code is freely accessible and the open source community being very active, the open source code is actively checked on an improved upon by PR programmers, not only from one company, but across many companies, as well as individual contributors. Think of it as a living code rather than a code that is closed and becomes stagnant. Next, transparency. Do you need to know exactly what kind of data are moving out there or what kind of changes have happened in the code? What happened in the latest release? Look no further, the code is open. You can look under the hood yourself and see exactly what happened within the code base. Property code relies on single author or company to gate keep. That's why the reliability could be an issue. Since open source code outlives the original authors because it is constantly updated through active open source communities. It also lowers the cost. That means if you're getting a product that is based on open source project, most of the code is basically free of cost. So what you end up paying is for security hardening and interoperability. Now with open source, there is no vendor lock-in. Freedom for the user means that you can take that open source code anywhere and use it for anything at any time. And lastly, the existence of active open source communities means that you can find help, resources, and perspectives that reach beyond one interest group or one specific company. Open collaboration is one of the core essence of open source projects and communities. Now, this is a question for you. Why you should contribute to open source projects if you're an early professional or even an experienced professional. The first point is very obvious. You'd like to gain experience. Now for those folks who are not into an employment, it's very difficult to gain employment experience. And the point which I mentioned at the beginning of the talk, entry-level jobs requiring many years of experience, it's difficult to gain that many number of years of experience unless you have lots of co-op or internship experience. One thing to keep in mind that experience does not necessarily mean employment experience. You can very well use open source project experience as the number of months or years of experience under your belt. So open source projects can give you that valuable experience. Second point is you can build new skills. Most of the open source projects are very friendly with first-time contributors. That means if you're a Go programmer with basic-level Go skills, you can start contributing to a project and with the mentoring of senior engineers, you can improve upon your Go code skills. Now Go code is just an example here, but you can have any type of skills which you can build upon working with senior engineers in the industry. Lastly, you can also build confidence when working on open source projects. Imagine if you landed a job at a company whose product is built upon that open source project, you would already be familiar with the code base. You probably would be much faster at code contribution than your other peers who just started who have to get familiar with the code base. So open source project experience would give you confidence. This is the first step of the three steps of getting your first open source PR. You have to learn Git. Now, whether you're software developer, UXCY designer or project manager, most of the stuff that happens in open source projects are happened via Git. So learning Git is an essential skill. In the resource section, I've added a link on how you can learn Git, but you can choose any medium of your choice on learning Git. One of the open source project I know sent out tweets based on Git workflows. The second point is choosing an open source project. Now, there are three things to consider when choosing an open source project. First is you have to consider the programming language. Now, this is especially true for code contributors. If you have a preference of language, you can filter out open source projects by that. And if you don't, you can start with anything and switch to a different project if that is not something you'd like to keep learning on. Second point is area of interest. Now, there could be a lot of different open source projects based on types or areas of interest. There could be projects geared towards front end or back end or security or machine learning. Now, if you have a strong preference for any of these, it might make sense to choose a similar open source project because you'll be just be more passionate in order to contribute to those projects. The last point is the size of the project. Now, established projects might have a large code base which could be daunting for first-time contributors. But it is also true that established process have a standardized process of first-time code contributors. That means those projects would have labels that says good first issue. And once you identify the issue, there'll be other peers in the community who'd help you make your first code contribution. So if the first project you're part of has a large code base but is an established project, do not be disappointed, do not be scared. Open source community is very collaborative and very welcoming to help you make your first code contribution. Let's do a quick exercise on how you can narrow down a good first open source project for you. Good first issue.dev is a website which lists a lot of open source projects and their open issues which are for good first time, which are good for first-time contributors and you can filter out these projects by programming languages. What you see in the screen is filtering by go programming languages and it shows the number of issues that are open. So this could be your first step for filtering out open source projects based on programming languages. If you have heard about CNCF, Cloud Native Computing Foundation, this is the landscape and it has a number of open source projects as you see, but what I was mentioning in terms of area of interest, you can filter out projects by that. My specific area of interest is DevOps and CI CD. So let's see if I can find projects based on that. So I see continuous integration and delivery. Once I filter that, the first project I see that is Argo, this is Argo CD's repository. If you click on issues, you can filter out issues based on labels. Typically, established projects have a label called good first issue. Let's see if this project has that label. So here I see that this good first issue label, it says it's good for newcomers. So once you filter that, you can find out issues that are good for first time contributors. One other thing I wanted to show you is when I selected Argo, it also shows me the stack. So I can see the code basis primarily go. That means if go is the programming language of my choice and CI CD is my area of interest, Argo could be one of my target open source project. So here's how you can filter out a good first issue starting with an open source project based on a language and an area of interest. Let's see what could be your next step once you find a good first issue. Once you find a good first issue, you can go raise that first PR, but there are some steps before that. Here's my suggested approach. The first thing is you have to commit some number of hours every week. Whether it's one hour, whether it's 20 hours, commit to that number of hours and block your calendar every week so that you can start contributing during that time. Most open source projects have weekly meetings. It might also be a good idea if you don't have any other meetings or classes during that time, try to attend those community calls. These are the times where you can introduce yourself, ask for help or get guidance on the issue you're trying to tackle on. The second point identifying good first issue is something we just demoed how to filter issues based on that label. The third point is you can discuss on communication channels which could be Slack or Discord on the requirement of the issue. Once someone acknowledges that you can take up that issue, you can assign yourself that issue. Be committed and professional. You can have one hour or even 10 minutes commitment per week, but let the community know about your level of commitment and stick to that commitment. Be professional in updating the issue on where you are and if possible, provide an estimated time of fixing that issue. It's very natural for you to get stuck or feeling completely lost when you're tackling your first issues. You can discuss on Slack or other communication mediums on the implementation. One helpful thing at this point could be studying existing code base, how other classes or how other features were implemented in the same code base. Feel free to ask other senior engineers. However, keep in mind that most open source contributors volunteer their time. That means they might have other commitment. Before you raise your first PR, you might need to sign the contributor license agreement, CLA or DCO depending on the type of open source project. This basically means that you're allowed to contribute to that open source project and the project is allowed to redistribute your work. When raising a PR, you can follow the standard procedure. You can fork the original repo, work on your feature branch on your own repo and then create a PR against upstream repo. Lastly, have patience. As I mentioned, most open source maintainers or contributors volunteer their time. So having some patience will go a long way. Now open source contribution is more than writing code. Open source community don't only have software contributors. Open source is a diverse community consisting code contributors, project managers, UX, UI designers, Q engineers, developer advocates, technical writers and more. It's important for us to understand all these different types of roles because combined we succeed. And it's essential to also know that if you're a non-code contributor, your contribution is just as valuable. If you're a junior UX UI designer or if you're a developer advocate, you can help open source projects just as much as a software developer. If you'd like to write a blog about you, that open source project or create a video to promote, those contributions count as well. Now, this is a list from Curtis Einzman and a tweet that he posted a while ago. Here, some of the PR best practices. We read code more than we write. That's why code quality matters. Poorly, we can code, creates PR trends which results in delayed delivery and can block other team members. Step number, point number two is when you're taking on task, take on small task first. In case you're taking on a large task, feel free to break down the larger task into multiple smaller tasks. Tip number three is ensure that your local different environment is ready. Now, this is very important. Pull down the latest code, ensure your local build and tests are passing. This will save you time and headache when you're coding. Step number four is read the existing code. If you're getting stuck implementing your own feature, understand how similar features were implemented. Step number five is plan your code. Write skeleton interfaces, classes and methods for the code structure. Step number six, don't try to write perfect code on the first go. Write a lot of ugly code. Think about refactoring later. Once you have the draft code ready, you can focus on refactoring. This is where you can use decent names and you can segment your code into small functions, finalize the class structure. Tips number eight is perform manual tests so that you ensure all the classes are working properly. Cover basic functionality and don't rely on catching granular edge cases on this step. Your unit test cases are there to catch those edge cases. Step number nine, prepare and review your own PR. Set yourself to a high standard and leave some feedback for yourself on how you can improve upon that PR. The last point is listen to feedback. Fully understand a teammate's perspective before addressing their comment. Even if you think that their comment is wrong, understand it's likely due to a lack of clarity in your own code. These are some of the helpful resources for you to get started. I hope you found value from this talk. I welcome any questions you might have. If you'd like to connect with me, my LinkedIn and Twitter handles are there at the bottom left corner of the screen. Thank you. So I'll cover the question that's being asked in the chat. Can you go into a bit more detail about manual tests versus unit tests? So great questions then. Thank you for the question. So manual test refers to as when you're just doing some echoes and testing if your feature or that specific code box is working as expected. And what I was highlighting with unit test is edge cases. For example, if you have a remote edge case where you're worrying about the logic how to catch all those edge cases, you shouldn't worry about that when you're just writing the basic functionality. You'll just go into a rabbit hole trying to get those edge cases. So once you have all those unit test cases in an automated fashion, you can catch edge cases. But manual test is mostly to test the basic functionality in a much quicker way. Surya, I think that's the only question we had, right? From the chat. Yeah, that's the only question in the chat at the moment. So I think if you want to discuss more you can go to the breakout session and talk to the speaker. And yeah, thank you very much Devan Ahmed once again. I would also like to tell the audience that we are having a break for half an hour. And