My Open Source Journey — From Zero to Two Merged PRs

How I, as a computer science undergraduate, started contributing to open source and what I learned along the way.

· 3 min read

As a computer science undergraduate, I’ve always been curious about the open source community. Recently, I finally took the first step and started submitting Pull Requests to some open source projects.

Why open source

Open source isn’t just about writing code. It’s a way of learning, a channel to communicate with developers around the world. By reading other people’s code, I’ve learned a lot of things that classroom never taught me:

  • Code review culture: How to write code that’s easy to review
  • Project conventions: Every project has its own style and norms
  • Communication skills: How to clearly describe your changes and intentions

My first PR

My first contribution was fixing a bug for an AI code review tool. The issue was that the read_file tool would error out when handling directory paths.

# Before the fix
if os.path.isfile(path):
    with open(path) as f:
        return f.read()
# No check for whether path is a directory

# After the fix
if os.path.isfile(path):
    with open(path) as f:
        return f.read()
elif os.path.isdir(path):
    return f"Error: {path} is a directory, not a file"

This fix looks simple, but it taught me:

  1. How to reproduce a bug
  2. How to write a minimal fix
  3. How to write a clear PR description

Lessons learned

1. Read the docs first

Every project has a CONTRIBUTING.md that explains in detail how to contribute. Submitting a PR without reading it will most likely get you rejected.

2. Start small

Don’t try to refactor the entire project on your first attempt. Fix a typo, improve some documentation, fix a small bug — these are all great starting points.

3. Be patient

Open source maintainers are usually volunteers. They have their own jobs and lives. A PR might take days or even weeks to be reviewed. Don’t rush them — wait patiently.

4. Accept feedback

Code review is not criticism — it’s learning. Every suggestion a maintainer makes is the crystallization of years of experience.

Tools I use

  • GitHub CLI (gh): Command-line GitHub operations, insanely efficient
  • Claude Code: AI-assisted coding that helps me quickly understand codebases
  • VS Code: Daily development environment
  • Git: Version control — you have to master this

Next steps

I plan to keep contributing to open source projects, especially:

  • Rust projects (currently learning)
  • AI/ML-related tools
  • Developer tools

If you want to start your own open source journey, my advice is: find a project you’re interested in, read its docs, fix a small bug, and submit your first PR.

Don’t be afraid to fail. Every rejected PR is a learning opportunity.


This post documents my experience contributing to open source as a computer science undergraduate. If you have any questions or suggestions, feel free to reach out.