If you're thinking about making contributions to other people's projects, get ready for the grind 🐱💻.
This week, I had one of my very first experiences contributing to someone else's repository as part of my school's open source course curriculum. Its not like I haven't opened a PR before in life. I have worked on both personal and hackathon projects (for example -> UI, API) with my friends and we had to contribute to each other's repos to work as a team.
But this time, it was a little different as I had to go through a procedure that is similar to how it is done in the real world. This lab was built on top of release 0.1 of the project we finished last week. The purpose was to find a classmate's repository to work on, and contribute a brand new feature to the existing project. The whole experience from finding a partner to successfully making the contribution was a series of steps, that had to be taken one at a time.
Finding a project 📂
I know you are expecting this to be the easiest part, and that's a rational thought. Why wouldn't I find a project if everyone in the class has one, right?
No Sir!
The crisis
This thought almost got me in trouble. Sure, I found someone who agreed to let me contribute to their project the first day of week. But when I actually sat down to coding a couple of days later, I saw that someone else had already merged a pull request for the feature I was planning to contribute, yayy 🥳.
Alright, on a serious note, I couldn't believe what I saw. All that time, I was under the false impression that if someone agreed to let me contribute, they'll keep waiting for me.
But the good part is it gave me a pretty valuable lesson early on in my open source journey.
Let me quote:
If you're not doing it now, someone else will do it b’for you.
Recovery
Open source is like a race. Everyone wants to get that PR merged, and I can imagine how crazy this competition would be in the real world. Lucky I get these lessons at the right time 😌.
Fortunately, I was able to find another repo to work on within 18 hours, when it was time to move to the next step!
Forking and Setting up the project 🍴
After I opened the markdown support issue for the new project, I quicky forked the repo and started reading the documentation to set it up.
Within the first 15 minutes of reviewing the project, I found several other issues other than what I was originally planning to fix:
I was able to open pull requests for 2 of these, 1 got merged), the other is still under discussion.
Anyhow, before I started working on the last issue, I had to first work on adding the markdown support, which was the actual meat of the matter.
Coding Time 🚀
The exisiting tool was able to process a text file and generate an html file out of it with not much features. The objective was to extend its functionality by adding support for markdown files with .md extenstion, and add at least one markdown parsing feature.
Examining
I started by examining the architecture of the program, and studying the coding style of the author. It took me a while, but I quickly came up with the structure I would follow to add the new functionality.
I chose a feature that would parse the lines starting with # like tokens as headings in html.
Implementation
The following enum helped me define the tokens:
// Markdown Tokens
enum MarkdownTokens {
H1 = '# ',
H2 = '## ',
H3 = '### ',
H4 = '#### ',
H5 = '##### ',
H6 = '###### ',
}
I tried my best to keep the code as modularized and elegant as possible.
All the changes eventually led to the following file structure:
For more details, feel free to visit my repo.
The big moment 🥁
After I finished testing my code locally with all kinds of inputs possible, it was time to finally create the pull request. There were some merge conflics, but I fixed them quickly as I have a lot of experience with those from my coop.
Again, I thought this was going to be a smooth merge. But when working with someone else, conflicts are bound to happen.
The author wanted some things to be done in a different way and we had a long converstion, which is still ongoing. I am hoping to come to a consensus soon. Once that is done, the code should be merged to the repository.
PR Conversation (Update)
After a long conversation on the pull request I opened, we decided to switch back to the old directory structure as the author preferred a more simplistic approach to files were organized.
I was also urged to use regular expressions instead of using the enum, as the regexp approach was more dynamic.
In order to align with author's preferences, I had to push another commit on my branch.
It took a little more convincing after that, before my PR was finally merged into the author's repository 😮💨.
And that my friends, is the story of my very first formal open source contribution (although not real real 😉).
Contribution to my repo 🤩
A couple of days after I finished working on my own pull request, someone opened an issue on my project asking if they could contribute to it in a similar way. I immediately agreed to the request and posted some general guidelines to follow while coding the feature.
There wasn't much for me to do in this process, except reviewing the Pull Request my friend opened on my repo, and adding comments for some issues I found in his changes.
The best part was that the contributor sent me a private message on Slack thanking me to allow his contribution:
I was glad my project helped someone learn new things 🙃
Learnings 📚
Here comes the most important section as the whole point of doing any kind of activity is learning something from it.
I certainly did learn lots of stuff.
Contributing to projects you don't own is a time-consuming process. Apart from coding your implementation/fix, you have to go back and forth with the owner to make sure they like whatever you did. You have to respect others' time and efficiently manage yours, so slacking is never an option.
Let me quote again:
Open source is a drag race where everyone wants to win. Start early and be the first one, or never finish.
Top comments (0)