Contributing to Open-Source Walkthrough Part 1

(Check out Part 0 if you haven’t yet!)

Choosing an Open Source repository

A reason why many beginners find open source software (OSS) development difficult is because they decide to work on a project like React or Node.js, that everyone knows about, where the code base is pretty robust and people are always competing to work on issues. It’s not easy to work on a project where there are more contributors than issues to work on. On a good note, for less popular projects, the reverse is often true. Less but still popular repositories are often overlooked, but can actually be a great introduction to open source. They’re often easier to contribute to, easier to make a sizable impact on the community, and you might learn more from working with the codebase.

These projects that I’m talking about can still have up to hundreds of thousands of users. Since I’m primarily a Javascript developer, I will find possible projects by looking at popular and semi-popular npm packages.

I just Googled ‘top npm packages’ and already found a list of the top 1000 most depended on packages to pick from.

Project List Criteria

My criteria for filtering possible projects to work on is that they:

1. Must have been published within the last couple months (means the project is relatively active)

2. Have few open PRs or have recent merged PRs (This is a good indicator of how active a project is. If open PRs aren’t being read or no PRs are being merged to master, then it’s probably not worth it to spend your time making a PR, as your PR might not even get looked at. There are many active projects, and choosing the right project will improve the overall probability that your PR gets merged in).

You can tell from the ratio of open to closed PRs, how recent the last PR was, and the number of comments on each PR, that if you make a PR to this repo, a project maintainer will probably review it and help get it merged.

3. The project has >X downloads/week (More downloads on a project means more users, which can mean you’re making a bigger impact. Personally I set my baseline to 100k)

4. Sound interesting or familiar to me (working on an interesting project or one I can relate to is a good motivation factor)

5. Has a few “good first issues” or “help wanted” tags on their Github repository (This means the project is beginner-friendly and has issues for people new to the project, or to open source)

After an hour of looking around (it will take some time), I’ve come up with my list:

Preview of my list:

1. mathjs
2. sequelize
3. codemirror
4. prismjs

….

I‘m not going to paste my entire list of projects here because a good project for me might not be a good fit for you. You should come up with your own.

I decided to go with mathjs as the project seems to be well maintained and math is an area of interest of mine.

Choosing an issue

There are quite a few issues that are available to work on, but I chose #1442 since it looks relatively simple, and it’s my first time contributing to this project.

Here, I ask to fix the issue, so that maintainers (such as josedejong) and others will know that I’ve begun to work on it. It’s important to be polite since it’s ultimately up to them whether your PR gets reviewed/merged or not.

Note: Usually I find it easier to work on issues in increasing difficulty for a project. As I work on more and more issues, I become more familiar with the codebase and more confident in tackling larger issues. If I ever commit to an issue that I realize is too difficult or time-consuming for me to find a solution to, it’s important to give it up so others can work on it. I would simply make another comment like, “Someone else can take this issue, I’m no longer working on it”.

In Part 2, I will begin work on the issue (available now).