Throughout my time contributing to oss, I've gotten a lot of questions about how can someone get started with oss and how can they make changes to codebases that look big. My most common answer to them has been to just do it.

I know it sounds cliché but that's honestly the most straightforward answer for it.

Let's take me for example. Currently, I don't know much about Javascript and it does look daunting to me in its current state with all of the frameworks, libraries, tools and whatnot. I'm still curious to know what Wasm is even though I've just started learning Node.js. Does this daunting feeling stop me from learning? A bit but also, not so much now.

A big reason for that is having been through the process of entering a new field and learning from it. I've learnt to embrace this initial overwhelming feeling of anxiety and started to embrace it as part of the learning process.

Maybe you can relate to past experiences of when you were starting out in something new and you were feeling anxious and nervous but then you persisted enough to learn something fruitful.

Being able to relate helps quite a lot as you now understand that this feeling is going to be there and there's no two-way about it. You have to learn while facing this feeling simultaneously. The good news is that as soon as you start to make progress, the feeling starts to fade away and it fades away pretty quickly.

So, for the rest of this blog, I'll go through a sort of self-interview where I'll mention questions that I've been asked about oss and then give my answers to them. While reading, keep in mind that what worked for me may not work for you but the advice and tips would most likely help.

Q) How do you get started contributing to cncf projects and what background knowledge is required to contribute?

- This is project specific. Each project will have its own set of requirements that you will need to know before contributing to it. These requirements include the programming language being used in the repository, the background knowledge needed to contribute to said project and so on.

Of course, all of this can be learnt on the go and even the maintainers recommend doing so for most of it. This aspect of oss is similar to software engineering in general, where you'll have to know and understand different tech stacks quite fast depending on the requirements of the org you'll be working at.

Q) What is the very first thing you do when contributing?

- The very first thing would be to look at the docs, especially the README.md file. Reading this file is important as it answers a lot of the questions you might be having in your head. Going through the README tells you a lot about the project and how it works.

A lot of the time It gives you enough background information for you to get started with contributing to the project. It also has links for further documentation and community channels for the project.

Be sure to read this readme and further related documentation so that you know enough to work on the project. You don't have to read everything but enough for you to get started.

Q) How do I choose among so many different projects?

- Try to work on a project to which you can relate. A project in a known field definitely helps. For example, I started out with Cloud Native projects since I had an interest in containers and containerized technology.

This helped me in my contribution journey as I was inspired to know more about the tools I was working with and being able to contribute to these tools made me happy to do more. So, look for a project in a known domain.

For eg, if you're into webdev, look at React, Npm etc. If you're into Containers like I am, look at Kubernetes, Prometheus and so on. There are tons of different projects to choose from.

Even if you don't know much about the domain but feel like going with your gut then I'd suggest you do so. You can always learn on the go. Just pick one that you feel inclined towards.

Q) How do you contact maintainers and ask them good questions?

- A very important thing to remember while contributing to oss is that most if not all maintainers work on oss outside of their spare time. So, even if they appreciate the work that you put in you will still need to be mindful of their schedules and ask for help accordingly.

Always try to ask your questions in the public channels. Sending someone a personal message makes them the only person that can resolve your query. Instead, ask on public channels. There are hundreds if not thousands of experienced people who can resolve your doubts.

Another thing to make sure is that you should always ask good questions. Good questions are questions where you've done your due diligent research and have made sure to understand all that you could about the problem from your side before asking.

This helps in showcasing the fact that you've thought about the problem and haven't just given up as soon as you saw something difficult. People answering would like this and hence would be more inclined towards answering your doubt.

Dontasktoask is a great site that teaches you more about how you should ask questions.

Q) How do I understand a new programming language quick enough to start contributing?

- Docs. Docs are your best friend regarding this matter. I think a lot of people don't appreciate how helpful docs are. Docs are amazing to get started with learning a language or tool.

There are detailed explanations for methods that are introduced by the tool and step-by-step guides towards building applications with said tool. It's a great starting point for someone who's exploring a new tool and wants to learn about using that tool in their workflow.

Once you understand how the tool works, you can get started debugging issues around the tool.

So, to summarize:

• Choose a project that you want to contribute to.

• Read the project's readme and also surrounding docs that give you a fair overview of what the project does.

• Get started contributing by working on issues and asking for help when you feel like you've hit a dead end.

This is it. Hope you liked the blog and got something of value.