6 PRs to open-source greatness with Hacktoberfest

A 4-week roadmap for data engineers to ship real code, earn recognition, and level up fast

This mini-course is part of the Level-up data engineering playlist. Click here to explore the full series.

Check my Git Playlist to read more about using Git in Data Engineering.

It’s October. You’ve got 30 days, one GitHub account, and a shot at turning open-source contributions into career fuel.

This month isn’t just about a free T-shirt. It’s a chance to prove you can ship. To take bugs, docs, and features that annoy thousands of people every day, and fix them. To leave fingerprints on projects other engineers rely on.

By the end of the month, you could have:

• 6 merged pull requests with your name on them

• Maintainers who know you, not just your username

• A GitHub profile that screams “I build things that matter”

And maybe even a story to tell at your next interview about the open-source code running in production because of you.

This mini-course is your roadmap. Each week, you’ll get exact instructions: what to fix, where to contribute, and how to brag about it online so the right people notice.

All you need to do is follow the plan, ship the work, and hit publish on a brag post once a week.

By October 31, you won’t just finish Hacktoberfest. You’ll finish with proof that you can deliver value in public.

Quick disclamers

These mini-courses are usually only for paying Data Gibberish members. But, this month, in the spirit of spreading the word, I’m giving this one for free.

I’ll try to update this mini-course every week throughout October and share my PRs with the community.

---

Hacktoberfest 101

Hacktoberfest is a month-long celebration of open-source. Every October, thousands of developers from all over the world contribute code, docs, and fixes to public projects.

The idea is simple: you open pull requests, maintainers review and merge them, and you get credit.

For you, it’s not just about swag. It’s about practicing how to deliver value in public. Each contribution is a line on your GitHub profile that says: I can find a problem, fix it, and get it accepted by strangers on the internet. That’s senior engineer energy.

Here’s how it works:

• Register first. Sign up with your GitHub or GitLab account at hacktoberfest.com. Do it before October 31.

• Ship in October. Pull requests (or merge requests) must be created between Oct 1, 10:00 UTC and Oct 31, 23:59 UTC. Anything before or after doesn’t count.

• Target the right repos. The repo needs the hacktoberfest topic, or your PR needs the hacktoberfest-accepted label.

• Quality matters. Spammy PRs, like fixing random commas, get flagged and ignored. Maintainers are quick to spot low-effort work.

Your target: 6 accepted PRs.

That’s enough to complete Hacktoberfest, earn the digital badge, and, if you’re among the first 10k finishers, grab the T-shirt.

But here’s the part that matters more: six merged PRs prove you can deliver useful code on a deadline.

Week 0: set yourself up

Step 1: sign up

• Create a GitHub or GitLab account if you don’t already have one.

• Register for Hacktoberfest at hacktoberfest.com.

Step 2: set up your tools

• Install Git and configure it with your name and email.

• Add your SSH key to GitHub so you can push without errors.

• Make sure you can fork and clone a repo, make a branch, and push changes.

Step 3: pick your “home” repo

• Search for active projects with the hacktoberfest topic.

• Look for issues labeled “good first issue” or “help wanted.”

• Choose one repo in your lane (ingestion, orchestration, data quality, engines, or metadata). This is your “home project” where you’ll go deeper over the month.

Example GitHub searches you can paste right now:

topic:hacktoberfest language:Python label:”good first issue” org:airbytehq

topic:hacktoberfest (dagster OR prefect OR mage-ai) label:”good first issue”

topic:hacktoberfest (”duckdb” OR “clickhouse” OR trino) label:”help wanted”

Mine is Meltano.

Step 4: bookmark your “opportunistic” repos

• Pick 2–3 other repos where you can grab small wins (doc fixes, error messages, configs).

• Star them, fork them, and keep them ready.

Pro tip: If a repo doesn’t have the hacktoberfest topic, ask maintainers politely to add the hacktoberfest-accepted label to your PR. That counts.

---

Week 1: fast wins + setup mastery

This week is about shipping two PRs and building muscle memory with GitHub + your chosen repo. By the end of the week, you’ll have code merged and your first brag post live.

Day 1–2: fork and run it locally

1. Fork your chosen “home” repo into your GitHub account.

2. Clone it locally and try to run the project following the README.

3. Keep a scratchpad open. Every time you hit a broken command, missing step, or confusing instruction, write it down.

Your first PR comes from this. If you found a missing dependency, add it. If a path was wrong, fix it. Then:

• Create a branch fix-setup-docs.

• Make the edit.

• Commit + push.

• Open your PR.

Congrats, you just shipped your first Hacktoberfest contribution!

Day 3–4: add a failing test

1. Find one open bug in Issues (labeled “bug” or “good first issue”).

2. Reproduce it in your local environment.

3. Write a failing unit test that shows the bug.

4. Push that test as a PR titled: “Add failing test for [bug]”.

Maintainers love this. You just saved them hours of debugging.

Day 5–6: patch something tiny

Now go back to the same bug (or a small one you noticed). Ship the fix.

• Fix the off-by-one, the null handling, the broken import.

• Keep the PR under 50 lines.

• Run pre-commit or linting (projects like Ruff/Black will complain if you don’t).

This is your second accepted PR.

Day 7: open an issue for Week 2

If you hit something you couldn’t fix this week, open a new issue. Include:

• Steps to reproduce

• Logs or screenshots

• Why it matters

That issue becomes your target PR for Week 2.

• End of Week 1 checklist

• 1 PR: fixed setup docs

• 1 PR: tiny bug/test fix

• 1 issue opened for Week 2

How to brag (copy this post)

Week 1 of Hacktoberfest is done:
Shipped 2 PRs to [repo].

Fixed local setup docs + patched a bug with null handling.
Opened 1 issue for next week.

Lesson: small, tested fixes get merged fast.

#Hacktoberfest

---

Week 2: small feature or connector hardening

Week 1 proved you can follow repo style and ship fixes.

Week 2 proves you can add something new that makes the project better.

Target: 2 PRs this week (1 medium feature + 1 quick win).

Day 8–9: Triage and claim your feature

1. Go back to the repo’s open issues. Look for something tagged help wanted or enhancement.

2. Drop a short comment: “I’d like to work on this for Hacktoberfest, can I take it?”

   • Maintainers love this. It prevents duplicate work.

3. Create a branch feature-[short-name].

Day 10–11: build the feature

Examples that count as “medium” but still shippable:

• Add a new config flag (e.g., -fail-fast, -enable-pkce).

• Improve pagination in an API connector.

• Extend schema/type coverage for a dataset (add enums, date formats).

Steps:

1. Write a failing test first to show the gap.

2. Add your feature/flag/config.

3. Update docs so others know how to use it.

4. Commit + push.

Open your PR titled: “Add [feature] to [component]”.

Day 12: ship a quick win

While your feature PR is in review, grab something small:

• Add a missing line to release notes.

• Fix an example config file.

• Add a “How to run locally” doc section.

Open it as a second PR. This gives you momentum even if your feature PR takes longer to merge.

Day 13–14: polish + follow up

• Respond to maintainer comments on your feature PR.

• Split it into smaller commits if they ask.

• Keep responses same-day to build trust.

End of week 2 checklist

• 1 medium PR (feature/config/schema)

• 1 quick PR (docs/tests)

• Maintainer interaction on feature PR

How to brag (copy this post)

Week 2 Hacktoberfest:
Shipped a new flag + updated docs in [repo].

Also added a sample config so newcomers don’t struggle.

Lesson: features get merged faster when you pair them with tests + docs.

#Hacktoberfest

---

Week 3: performance + reliability

By now you’ve shipped bug fixes and features. Great.

But senior engineers aren’t measured by features alone. They’re measured by stability and speed.

This week you’ll take on one medium PR aimed at performance or reliability, plus an optional “examples PR” to help newcomers.

Target: 1 medium PR + optional example PR.

Day 15–16: pick your performance target

1. Skim open issues for keywords: slow, retry, batching, flaky, memory, timeout.

2. Reproduce it locally. Measure before you fix. (Logs, timings, or even a print statement with runtime.)

3. Comment on the issue to claim it.

Day 17–18: implement the fix

Ideas you can tackle:

• Add batching or vectorized operations instead of loops.

• Implement exponential backoff + jitter for API calls.

• Replace flaky time-dependent tests with frozen-time fixtures.

• Improve error messages with IDs + sample payloads.

Steps:

1. Add or update tests to show the improvement.

2. Push your changes.

3. In the PR description, include before vs after numbers or logs.

Day 19: optional example PR

Maintainers love good examples.

• Add a dbt pipeline, notebook, or DAG showing the tool in action.

• Keep it simple but runnable.

• Title: “Add example: [system] → [system] pipeline”.

Day 20–21: review + respond

• Check for maintainer comments.

• Break down big PRs if needed (<300 lines).

• Respond quickly to keep momentum.

End of week 3 checklist

• 1 medium PR improving performance or reliability

• 1 optional example PR (extra brownie points)

• Before/after logs included in description

How to brag (copy this post)

Week 3 Hacktoberfest:
Optimized retry logic in [repo].

Jobs now fail less often + logs are clearer.
Also added an example pipeline for newcomers.

Lesson: maintainers merge faster when you show before/after impact.

#Hacktoberfest

---

Week 4: Close strong + maintainer mode

Anyone can open a PR. Senior engineers finish the job.

This week is about two things:

1. Closing out earlier work by addressing feedback.

2. Giving back to the community with one opportunistic PR and some issue triage.

Target: 2 PRs this week (1 refactor/feedback + 1 opportunistic), plus at least 1 hour spent answering or triaging issues.

Day 22–23: revisit your old PRs

• Check every PR you opened in Weeks 1–3.

• Did maintainers leave comments? Tests to fix? Docs to improve?

• Pick one and refactor until it’s merge-ready.

Pro tip: Reply in-thread with a summary of what you changed. Keep it short and professional. Momentum matters.

Day 24–25: ship an opportunistic PR

Time to spread your wings. Grab a repo outside your “home project” and contribute something small but valuable:

• Split a long README into sections.

• Add a “Quickstart” that actually runs.

• Improve an error message with actionable hints.

This becomes your final PR for Hacktoberfest.

Day 26: triaging + goodwill

Spend 1–2 hours helping maintainers:

• Answer open issues with reproducible steps.

• Confirm bugs others reported.

• Suggest workarounds.

It may not count toward your 6 PRs, but it builds serious goodwill. Maintainers remember who makes their lives easier.

Day 27–28: wrap it up

• Check all your PRs are merged or marked hacktoberfest-accepted.

• Thank maintainers in comments when they merge your code.

• Update your brag sheet: 6 PRs, 4 posts, dozens of lessons learned.

End of week 4 checklist

• 1 PR from maintainer feedback/refactor

• 1 opportunistic PR in a different repo

• 1–2 hours triaging issues/answering questions

• All 6 PRs merged or accepted

---

How to brag (copy this post)

Week 4 Hacktoberfest:
Closed out my 6th PR with a maintainer-requested refactor in [repo].

Also shipped a quick doc fix in [other repo] and answered a few open issues.

Lesson: finishing strong builds more trust than starting fast.

#Hacktoberfest

Final thoughts

By now you’ve done more than just survive Hacktoberfest.

You’ve shipped six real contributions in four weeks. Fixed bugs, added features, improved docs, optimized retries, closed feedback loops.

You didn’t just touch code. You shipped work that other engineers now depend on.

And that’s the hidden prize.

Sure, you might score a free T-shirt. But the real win is what stays behind:

• A GitHub profile full of merged PRs

• Maintainers who recognize your name and trust your work

• Four brag posts proving you’re someone who ships value in public

This is how you grow into senior territory. Not by talking about impact, but by showing it. Repeatedly. Consistently. In the open.

Thanks for reading,

Yordan

PS: This is just the beginning. When you are ready for the next leap into your data engineering career, this is how I can help.