Hacktoberfest 2022 was my first real exposure to contributing to other people's code in production repositories — not toy projects, not university assignments, but real codebases with real maintainers who would actually review and either accept or reject my work.

Four pull requests merged. Two projects contributed to. Here's what actually happened and what I took away from it.

Finding the Right Projects

The hardest part of Hacktoberfest isn't the coding — it's finding the right issue. The tips everyone gives ("look for good-first-issue labels") are correct but incomplete. What I found actually worked:

• Filter GitHub by label:hacktoberfest and label:good-first-issue together
• Look at the repo's recent activity — a repo with commits in the last week is maintained; one with no commits in 8 months will let your PR rot
• Read 3–4 merged PRs before opening your own — understand the maintainer's style, how they give feedback, what they care about
• Pick issues where you can actually understand the codebase in under 30 minutes of reading

What I Contributed

Project 1: A Python utility library — Fixed a bug in a string processing function where edge cases with empty input weren't handled. The existing code assumed non-empty input and threw an unhelpful IndexError. My fix added a guard clause and a corresponding test. The maintainer approved it with one round of feedback: they wanted the error message to be more descriptive. I updated it, and it was merged.

Project 2: A documentation site — Added two missing code examples to a section on API usage. The docs explained what a function did but showed no examples of calling it. I added working examples with comments. This PR was approved with no changes requested — documentation contributions are often easier to get merged than code changes.

What Code Review Taught Me

Getting feedback from a senior maintainer on code you wrote is different from a university grader. Maintainers care about:

• Consistency with the existing codebase — matching the style, naming conventions, and patterns already there
• Not breaking existing tests — run the full test suite before submitting
• Minimal diffs — don't touch things you don't need to. Every extra line is a line they have to review and justify merging
• Clear commit messages — "fix bug" is not a commit message. "Fix IndexError on empty string input in process_text()" is.

What I'd Do Differently

• Comment on an issue before writing code — check that no one else is working on it and that your approach is the right one
• Start with documentation before code — it's easier to get merged and teaches you the project structure
• Set up the local dev environment completely before picking an issue — running into environment problems mid-contribution is frustrating

The Value of Open Source Contribution

The t-shirt (Hacktoberfest's reward) was not the point. What I got from 31 days of open source: practice reading unfamiliar code, practice writing code that other people will maintain, and an understanding of what professional code review looks like. These are things you can't get from personal projects alone.

I've been following both projects since. Seeing my code still running in a maintained repository two years later is quietly satisfying.