While searching for my first software engineering role, I wanted experience beyond personal projects. I wanted to understand how real production software is built and maintained.
Open source was the best place to learn, so I started looking for a project where I could make a meaningful contribution.
Finding the Right Opportunity
Like many beginners, I first targeted highly active repositories. One of them was cal.com, where I raised an issue and implemented the fix immediately.
Unfortunately, another contributor's pull request was merged before mine.
Instead of getting discouraged, I decided to look for an issue that better matched my experience and where I could genuinely help.
Eventually, I found the Express Release Status website, a React-based project. One issue caught my attention because it had been opened by one of the maintainers and the requirements were clear.
Working on the Issue
The task was simple on paper: make the Express release timeline clickable.
Instead of jumping straight into coding, I first explored the project structure to understand where the timeline was being rendered.
After locating the relevant React component, I looked at how navigation was already implemented across the application. Rather than introducing a different approach, I wanted my solution to match the existing codebase.
I found that the project used React Router's Link component for internal navigation.
So instead of creating a custom solution or using HTML anchor tags, I followed the same pattern.
The actual code change was surprisingly small. I modified only the lines responsible for rendering the release timeline and wrapped them with the existing routing component.
By keeping the change minimal and focused on the issue, the pull request stayed clean and easy to review.
Practices I Followed
This contribution taught me a few habits that I still follow today:
- Understand the codebase before writing code.
- Follow the project's existing patterns instead of introducing your own.
- Change only what is necessary.
- Keep pull requests focused on a single issue.
- Respect the review process and respond to maintainer feedback promptly.
Getting the Pull Request Merged
After opening the pull request, the maintainers requested verification before merging it, which I completed.
The pull request then remained open for almost 2–3 months.
During that time, I politely emailed the maintainers to follow up. They responded kindly, and after the review process was complete, my pull request was finally merged.
Seeing that merge notification felt incredibly rewarding because it was my first contribution to a real production project.
What I Learned
This experience taught me that open source isn't about writing the most code—it's about writing the right code.
Small, focused pull requests are easier to review than large ones.
Reading and understanding an existing codebase is just as important as writing new features.
Most importantly, patience matters. Reviews can take weeks or even months, but persistence pays off.
Top comments (0)