Intro to Open Source - Lesson 3 - Ways to Contribute

Welcome to the third lesson in the Intro to Open Source learning path! In this lesson we will be discussing the many different ways you can contribute to open source. This lesson has been adapted and expanded from a blog post we wrote a few months ago.

There are many ways you can contribute to open source projects, and for the most part contributions will always be welcome. However, do keep in mind that different communities will have different guidelines on how to contribute, as well as on what to contribute. Some communities might even ask that you do not contribute, although that is quite rare. So be sure to check with the community before you start contributing to ensure that you are helping, and not wasting their time or yours. 

For a specific project, you can normally find contribution guidelines in the README.md file or in the CONTRIBUTING.md file in the git repository. Additionally, you can normally find guidance on how to contribute on the project’s website. 

Keeping in mind that different communities may have more specific rules around what types of contributions they accept, let’s discuss the normal types of contributions that most communities accept. We will discuss 6 types of contributions in this lesson: opening issues, triaging issues, writing documentation, attending meetings, reviewing Pull Requests(PRs), and writing code. 

For the first four types of contributions, we will not only discuss what the type of contribution is, but also how you can make that contribution. For the last two, as they are more code-centric we will be leaving that discussion for a later lesson after we have discussed what prerequisites you should have before you contribute code.

Opening Issues

A great way to contribute is to open “issues” on GitHub/GitLab, or whatever other platform the community is using. For example, Knative uses GitHub to keep track of issues. 

An issue is generally a discrete chunk of work, although it does not need to be a small chunk of work. This could be a bug, a feature request, a performance issue, or something else entirely. So, if there is a bug which is bothering you about an open source project you use, open an issue and report it! Similarly, if there is a feature you would like to see in that project but which does not currently exist, you can open an issue asking for them to add it.

This is a great way to contribute to a project, as it helps provide feedback to the maintainers of the project. Often, open source projects can have a hard time collecting user feedback, so providing it can be extremely helpful! However, keep in mind that there is no guarantee that the maintainers of the project will fix the issue for you. That being said, they will generally try to address your issue if it makes sense.

Triaging Issues

Open sources can get tons of issues, creating loads of work for maintainers to triage them. However, this means that this is a great opportunity for you to start contributing to the project, as you will be saving a lot of time for the maintainers and make a real difference to the project! So, what does it mean to triage an issue, and how can you triage an issue?

Triaging issues is the process of categorizing an issue across many different axes, such as priority, whether it will be worked on, what part of the project it impacts, and whether it is good for new contributors. On GitHub, this process is generally done by assigning labels to an issue.  As part of this process, you may need to ask the person who opened the issue to clarify various aspects of the issue. Once the issue has been clarified and correctly labeled it is now triaged, and it will be easier for contributors to find tasks to work on!

Writing Documentation

If you would like to contribute to the project by creating something, but aren’t sure about your coding ability or don’t feel comfortable with the technical aspect of the project yet, then writing documentation is a fantastic way for you to contribute! Every project needs documentation so that the users are able to understand the project and use it effectively and efficiently. However, the documentation tends to lag behind the new features, making documentation contributions a crucial part of the project’s success. Writing documentation is also a great way for you to learn more of the technical details of the project, as you will have to gain an understanding of how they work in order to write about them.

To write documentation for a project, the project will often have a “docs” repository, or a “docs” directory in the main repository. In either case, you will be able to find issues related to documentation in the relevant repository. You can assign these to yourself and then get to work writing up documentation of that new feature.If you are unsure about where you should be writing the documentation (e.g. which repository, which file), or of any aspect of the issue, you can always ask those questions on the issue itself in the form of a comment. It is often useful to ask the author of the feature you are documenting any questions you may have about how it works! 

Reviewing Pull Requests(PRs)

A more technically oriented contribution you can make is to review a Pull Request (PR). We will talk more about PRs in the next two lessons, as we discuss what you need to know to make a code contribution as well as how to make a code contribution, but suffice it to say that a Pull Request is a way of proposing a code change in a project. These are then reviewed by maintainers of the project to check things such as quality and correctness of the code, before they are merged into the project. As every change which goes into the project goes through the PR review process, these reviews can take up a lot of time for maintainers, so they will be very appreciative if you help review a set of changes.

To review a PR, you will generally look at the changes being proposed and leave comments on it. This article explains how to do this on GitHub, while this article explains how to do this on GitLab. While it is likely difficult to fully understand everything that is going on in the code if you haven't contributed much code to the project, you can still leave comments and questions about the code in an attempt to improve the overall quality of the changes. However, if you really don't understand the code, it is likely more useful for you to verify that the changes work. If everything works, leave a comment to that effect. Otherwise, leave a comment for the author of the PR letting them know that they need to fix something.

Writing Code

This is likely the most technically demanding type of contribution you can make to the project. This process is also more involved than the earlier types of contributions, so if you are interested in this please read the next two lessons in this learning path!

Attending Community Events and Meetings

Regardless of what other types of contributions you would like to make (if any), attending community events and meetings are an amazing way for you to participate in the development of an open source project. While some smaller projects will have a single meeting or maybe a few meetings every week, larger projects will have many meetings on different topics throughout each week - pick what is interesting to you or what meetings are related to what you are working on and go join them! This is your chance to both discuss what you and others are working on in that area, as well as to discuss what should be done in the future of that part of the project. It is also a great way to meet and get to know other members of the community!

Thanks for taking the time to read this and now you have understood the ways you can contribute to the open source community.! We hope to see you in the next lesson in this learning path, where we will be discussing what you should learn before contributing code!