tl;dr
- 🔬 | You are working and you find something your favourite library is not able to do.
- 👷♀️ | You write some code to work around that limitation.
- 🙋 | Raise an Issue on the library's GitHub repository and explain how your code solves the problem.
- 🐵 | Engage with the library "owners" (called maintainers) to understand how to correctly add your solution.
- ✅ | Add your solution by raising a pull request (PR).
- 🍺 | Go get yourself a beer (and wait for your solution to get accepted!)
Hey friends, 👋
What if your entry into open-source is just a limitation away in a programming package?
OK, I'll be the first one to say that sounds confusing right now lol.
Still, hear me out.
The dev, who could be you, wants this hypothetical machine learning package to do something. Yet, the necessary function/method/class isn't there. So they write a snippet of code to tackle this issue. 🏗️
However, instead of keeping this gem to themselves, they think "hey, that could be useful for someone else". Generously, they decide to contribute that snippet of code to the open-source community.
This means that not only are you solving your own puzzle but also saving fellow devs from cracking the same code in the future. 🧩✨
What’s the big win?
You troubleshoot your roadblock, enrich your portfolio of work and lift the whole community. Pretty sweet deal eh?
Now believe it or not, this is actually how developers kickstart their open-source journey... and how you can get started too!
Afterward, you can visit quira.sh, which helps you discover open-source projects to contribute to. It matches projects based on your preferred topics and programming languages (here's a short playlist in case you are blocked)! 🫶
🎯 Step 1: You found a limitation!
You are working on a coding project or something at work, and you find a limitation in the library you are using!
Real World Example
In our team, Luke our Senior Dev needed to have a function that finds all the co-authors in a GitHub commit (and yes, you can actually have co-authors in a commit!). 🤓
Now, he is low-key in love with gitpython as the library is just extremely useful for his work. However this time good ol' gitpython did not have the functionality he needed. So, our friend Luke just found himself a limitation with this library!
✍️ Step 2: Raise an Issue = "Hey, I think there is something that could be improved here!"
Jump over to the library’s GitHub/GitLab page and raise an issue with your proposed solution. Be clear, concise, and polite: “Hey, I found this limitation and here’s what I think might help!” 💪
Real World Example
Luke went on gitpython's repository link and proceeded to open a new issue.
You can go about it the same way he did:
- Head to the library's repository
- Click on
Issues - Click on
New Issue
He went on to describe the issue, titled it and then posted it. 👇
🤗 Step 3: Engage and Adjust
After raising the issue or PR, be ready for discussions.
The maintainers (people that are "owners" of the library) are extremely likely to ask for more details and/or suggest changes. This is where you show how great you are at teamwork and collaboration! 🤝
Example
Luke's issue has been read by gitpython's maintainer who lets him know he is happy to receive his contribution.
🦾 Step 4: Raise your PR!
Raising your PR or Pull Request means that you want to contribute and add your changes into the library's repository.
They are called pulled requests because if your contribution is accepted, your request is "pulled" into the main project codebase.
If this is your first time raising a PR, I would strongly advise you to read this doc where every step is explained in detail. 🌟
Real World Example
Luke raised his PR with the changes he made into the document. ⬇️
Note: Speaking with the maintainer can look overwhelming at first but don't worry. Maintainers are in general very glad you are helping so if something they are asking you to change does not make sense, be sure to ask for clarifications!
For example, we can see below that the maintainer is asking Luke for some changes. 👇
💡 TIP: The right thing to "almost always" do is:
- raise an issue
- create a PR
Like this you inform the maintainers of the project about the issue and your solution. Only after you get their approval should you open a new PR.
The only times when it is better for you to skip raising the issue is when you are changing something that you think is either:
- quite insignificant (like a wording or grammatical error) or
- when you are very confident your changes will be accepted straight away.
🎉 Step 5: Go get yourself a beer
Once the back and forth has concluded, the maintainer will accept your PR - otherwise known as "Merging your PR"!
Now this is the moment where you shout: "I made it!" (warning, shouting something like this is quite cringy but do what feels right to you).
Give yourself a real strong pat on the back for contributing to the community. 🚀
Real World Example
After some discussion around some of the changes suggested by Luke, gitpython's maintainer merged his PR making Luke a very happy man that day. 💁♀️
After this you should be ready to start contributing to other projects with good starter issues. The cool thing is they are all put into quira.sh where you can filter by your language and topic of preference.
Your thoughts? 🤔
Have you ever fixed documentation or spotted a library limitation? Share your stories below! Let’s make the open source community stronger, together.
Keep slaying,
Your Dev.to buddy 💚
If you haven't yet, you could join our discord server if you need any help or have any questions. Also, here's a short playlist in case you like learning everything under 5 min. 🚀🫶
Top comments (4)
Great case study - props to you (and your own co-author Luke)!
haha I see what you did there ;) Thanks man!!
Nice post