October is when a lot of people decide this is the month they finally contribute to open source. That energy is useful. A pile of unreviewed, unasked-for pull requests is not.

This post is for the second outcome: a good first issue that a maintainer still wants, on a repo that merges, so the work can land. If you only need the general playbook, start with how to find good first issues and the first pull request guide.

What Hacktoberfest 2026 is (and is not)

Hacktoberfest is a yearly October event around open source. For 2026 it is run by Major League Hacking (MLH) and DEV with DigitalOcean.

The important change: they are not counting pull requests the way older years did. The 2026 edition is built around community events (“Fests”) and open-source / open-weight AI, plus a global online track. Swag, badges, and participation rules live on the official site and have moved before. Do not plan around a prize table you saw on a blog. Confirm the current rules at hacktoberfest.com and the FAQ.

What that means for you as a contributor: October is still a good time to make a first merge. It is a bad time to treat random repos as a ticket machine.

Why spam pull requests fail

Maintainers already live with noisy issues. AI-generated PRs made that worse, which is a large part of why Hacktoberfest moved off PR counting.

These usually get closed:

A README typo on a project you do not use, with no other change
Whitespace or formatter diffs that touch files the issue never mentioned
Duplicate PRs on an issue someone already claimed
“Fixes #123” that does not fix 123
PRs with no tests, no description, and no sign that you read CONTRIBUTING.md

A closed spam PR is not a contribution. It is extra work for a volunteer. If your goal is a merge, do less, on purpose.

How to pick an issue maintainers actually want

Use the same bar you would use in February.

The label is real. good first issue (or a close variant) from the project, not a label you invented in your head.
The repo is alive. Recent commits, recent merged PRs, a maintainer who still comments.
The thread is free. Read every comment. If someone is actively working on it, pick another.
The task is specified. You can name the file or area and what “done” looks like.
You can finish it. Match the language you write. A small, correct patch beats a heroic one you abandon.

Drive-by docs typos fail this list. A documentation change that the issue asked for, on a project you read, is a different thing. That can be a clean first merge.

Start on Help Wanted live hubs

Do not begin with a GitHub search for hacktoberfest and a hope. Begin with live, labeled issues on active projects:

All languages: https://helpwanted.dev/
Python: https://helpwanted.dev/language/python
TypeScript: https://helpwanted.dev/language/typescript
JavaScript: https://helpwanted.dev/language/javascript

Use the homepage filters for difficulty if you want a smaller first patch. Then open the issue on GitHub and read it like a spec.

The longer version of this workflow, including GitHub search operators, is in how to find good first issues in 2026.

Ship a reviewable pull request

Once you have an issue:

Comment that you are taking it, unless the issue says not to
Fork, branch, keep the diff on-topic
Link the issue from the PR (Fixes #123)
Describe the change and how you tested it
Answer review comments

The mechanical Git steps are in the first pull request guide. During October, review queues get longer. Patience is part of the patch.

This also belongs on a resume

A merged pull request is public work. It shows up on GitHub. In an interview you can talk about the issue, the constraint, the review, and what you shipped. That is more useful than a private tutorial repo.

One merge is a start, not a portfolio. If you are doing this for a job search, read how to build a developer portfolio through open source and keep going on the same project after the first PR lands.

If you are here for Hacktoberfest itself

Go to hacktoberfest.com for events, hosting, and whatever participation path they are running this year. Then come back here for the issue.

The useful October habit is the same as the rest of the year: one labeled issue, one focused PR, one repo that still merges.