Contributing to open source projects: let's get us all started

Have you always wanted to contribute to Open Source but do not know how to get started? Are you preparing to participate in Hacktoberfest? Well, look no more, because in these series you will learn how to do your first contribution to open source.

In this first part of the series, we will cover:

1. Motivations to contribute to Open Source
2. How to get started with your contributions
3. What to look for in an Open Source project
4. Getting ready to contribute

Why contributing to open source?

I am a long-time open source user and contributor. So much of my work relies on open-source software. Also, belonging to open source communities has definitely opened many doors and opportunities for me in the past. Some reasons you might want to contribute to open source are:

• It can be a rewarding experience: knowing that you helped fix a pesky issue or improve the documentation for the libraries that you use can be quite satisfying and benefit a bunch of folks.
• It is an excellent way to learn new skills: from improving your version control skills to working collaboratively with other developers, technical writers and designers, you always acquire new skills (or sharpen your existing ones).
• Being part of the community: contributing to open source helps you build relationships within the open-source community
• Find mentors and mentor others: as you work on open source projects you often need to explain how you do things and discuss the best solution to a problem.
• Going beyond the technical skills: not only it allows you to improve your coding or technical skills, but it also allows you to work on essential people skills such as effective communication, conflict resolution, leadership and organisational skills.
• Working in the open: in many cases, we do not get the chance to share what we work on in our day job due to NDIs or other circumstances. Or maybe you are looking for a career change and want to build an online developer presence. Contributing to open-source gives you a chance to showcase all of the skills mentioned above in an open and public manner.

How to get started with open-source contributions

Right, so far, I only focused on the "why you might want to contribute to open source". Contributing to open-source can be pretty daunting, mostly if you have never done it before.
And to be accurate, there are many steps involved, from choosing the best project to contribute to, selecting an item to work on to submitting your contribution.

So let's break this into smaller pieces.

Finding the right project

The most straightforward way to find a project is thinking about the libraries you use regularly. And head over to the project's repository.

Some items are a good indicator that the project is welcoming and accepting contributions. Head over to the project's repository and look for:

• License: make sure the project has an open source license, if you cannot find this, then the project is not open source. This should be as a LICENSE file in the repository.
• Contribution guidelines: if the project repository is in GitHub, look for a CONTRIBUTING.md file. This should either contain the detailed process to set your development environment, how to run the tests and build the documentation. As well as any conventions for submitting contributions.
• Code of conduct: having a Code of Conduct is critical to keep the community interactions safe and friendly for us all. It helps set ground rules for contributor's behaviours and also outlines mechanisms to report violations to these rules. Having a CoC is a good signal towards a project being inclusive and welcoming. But make sure there are also channels to report CoC violations.
• Communication channels: some projects will have mailing lists for folks to ask questions and receive guidance. Others have Discourse servers, Gitter or Slack channels. Keep track of these resources as you might need them to ask questions.
• Contribution workflow: check the number of issues open, Pull Requests and check the flow of discussions on issues. Spending some time doing this can be super valuable to get an idea about maintainers-contributors interactions.

Finding something to work on

This is perhaps one of the most challenging parts of submitting your first (or hundredth) contribution. But here are my top tips:

• Think beyond code: there are so many ways in which you can contribute to open source, apart from code. I often get folks asking me "I am not a developer but a technical writer/designer/else, can I still contribute?" and the answer is yes. The truth is open-source can significantly benefit from a diverse set of contributions, so make sure to think outside the coding box and think about how you can use other skills. Do you like organising events? Are you a great graphic designer? Are you an accessibility expert? Do you speak multiple languages? Think about how you can add value to the project while building on your skills and interests.
• Build from experience: if you are contributing to a project, you have used before you might have encountered something that could be better. Maybe the instructions for setting up your development environment are outdated. Perhaps some of their tutorials are not clear enough. Use this to your advantage - having a fresh set of eyes can be massively helpful to improve the contributor's experience.
• No contribution is too small: maybe you encountered a broken link in the documentation or the project Readme, consider submitting this as a contribution.
• Finding issues to work on: There are multiple ways in which you can find issues to work on. For projects on GitHub, you can head over to their Issues page and find issues marked as help-wanted, beginner-friendly or good first issue.

Something quite nifty I found about recently is that you can directly head over to the issues marked with these labels directly by going to the projects contributing page. For example, for JupyterHub, you would head over to https://github.com/jupyterhub/jupyterhub/contribute. Plus the Contribution guidelines are also made visible so you can access them directly!

• Beginners issues aggregators: there are some sites that you can use to find beginner-friendly issues across many repositories, programming languages and organisations.
  • GitHub explore
  • First Timers Only
  • Up for grabs
  • Good first issues
  • First contributions
  • Code Triage this allows you to subscribe to your favourite project and get a new issue in your inbox for triaging

You are almost ready!

Before getting working on an issue, make sure to have a quick check to make sure that nobody is working on this item already.

• Go to the issue and express your intention to work on it so that there is no duplication of effort

Sometimes folks commit to working on an issue, but it turns out they did not follow through (maybe their circumstances changed, I have been there, and it's ok).

• Head to the issue and say you would like to follow on it. Ask questions if you need to clarify any points or discuss implementations.

If there are no issues opened for the item, you plan to work on open an issue straight away and discuss the idea.

• Provide enough context, links and screenshots if this help support your issue.

Next steps

Hopefully, this will get you all started. If you want to get some practice on creating Pull Requests this resource by @kentcdodds is great. You can also make a PR to the First Contribution repository to get some hands-on experience.

Do you have any tops tips to get started? Add them as comments to this article, share your favourite projects to contribute to or examples to outstanding Readmes.

And do not miss the following articles in the series where we will discuss PR etiquette and efficient communication and contribution workflows.