TL;DR
I made a program that finds, among your starred repositories, the issues that are most likely to be a good choice for making a contribution. For a quick start, check out the How-To on the GitHub project page.
Why would one need it?
Developers are obsessed with open source development nowadays. Everyone wants to give back to the community, to get some new skills and experience while working on the most widely known software products. Imagine getting invaluable insights from experienced engineers all over the world: pretty exciting, right?
However, people struggle hard to find appropriate tasks to work on. If you are new to the project, it is most likely that the maintainers won’t let you work on some big, fancy feature, lest you miss a plenty of details and corner cases. Everyone agrees that one would better start with the easiest tasks, learn the ropes, get some trust from maintainers, and then proceed to harder ones.
So, how do you find these easy issues to work on?
Some time ago, GitHub started listing appropriate issues, e.g., https://github.com/golang/go/contribute. You can access this list from the header of the Issues page. This is how it looks like:
Although it is pretty accurate, it sometimes lacks the appropriate labeling or misses some items.
My usual "let-me-make-a-contribution" day used to look like this: I was looking through my starred repositories and jumping to this “new contribution” section, or was scrolling the issues list manually. That was a very monotonous and time-consuming task, so I used to get bored quickly by this process and would give up. That is when I decided to automate it.
Solution
First, I needed to work out the rules of the game. I did some research and came up with the following heuristics:
- An issue should not be closed.
- Assigned means assigned, don’t waste your time on it.
- An issue should be marked with an “easy” label or something similar.
- Old issues are likely to be outdated; if it remains unsolved for too long, maintainers are likely not interested in it and probably less interested to help you during the process.
Furthermore, it turns out that every repository uses its own set of labels, and it is rarely just “help wanted”. There are multitudes of them. I looked through all the labels in my starred repositories and other popular ones and came up with a final list of ~60 labels. If any of your repositories have different labels, create a pull request or contact me — I will add it as soon as possible. As I set boundaries, it was the time to create the program itself.
I built a Kotlin application, which looks through the list of starred repositories and searches for the issues with predefined labels, sorts them and has them printed to the console. The current way of distribution is a Docker image — people are more likely to have it installed than Java ;)
As the labels list grew, I noticed a drastic decrease in speed and an increase in the consumption of API usage limits. The first edition of the tool was searching for issues with all given labels, although 95% of them had never been used in that repo! That was my “AHA!” moment, so I added an additional call to fetch all the labels from the repository and intersect them with my list. I got a significant improvement of the performance, and utilized less of the API limits.
On a daily basis, the tool works fine as a guide to the world of open-source contributions, it will also help you to achieve your Hacktoberfest goals. To try it, go to the project page and follow the instructions. If you lack starred repositories - I have some advices for you as well.
If you have something to say — do it in the section below, or in the dedicated feedback issue.
Top comments (0)