The hard part of a first open source contribution is not Git. It is picking an issue that is still real: labeled for newcomers, on a repo that merges PRs, and not already claimed in the comments.

I built Help Wanted because GitHub search dumps you into that mess. This is how I would look for a good first issue in 2026, in order.

What a good first issue actually is

A good first issue is a task a maintainer marked as a reasonable first contribution. The scope should be small. The description should tell you what is wrong, where to look, and what “done” means. You should not need the whole architecture in your head.

Common labels:

Label	What it usually means
`good first issue`	GitHub’s recommended beginner label
`good-first-issue`	Same idea, hyphenated
`beginner-friendly` / `first-timers-only`	Explicitly for newcomers
`easy` / `starter`	Lower complexity, not always first-timer only
`help wanted`	Maintainers want help. Difficulty varies.

If you only remember one distinction: good first issue is about onboarding. help wanted is about backlog. Both can be useful. Only one is aimed at you.

Method 1: Start on Help Wanted live hubs

This is the method I want you to use first.

Help Wanted is a live index of labeled issues from active GitHub projects. The product is the language hub, not a static list of repos:

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

Open the hub for the language you already write. Filter by difficulty if you want something smaller. Then read the issue, not just the title.

Why an aggregator of active labeled issues beats raw GitHub search

GitHub search is complete. That is also the problem. A query for label:"good first issue" is:open will happily return:

Issues that have been open for years on repos with no recent commits
Issues someone already claimed in a comment, with a half-finished branch nobody merged
Labels that were applied once and never revisited
Projects that stopped reviewing pull requests

Help Wanted starts from labeled issues, then keeps the ones tied to projects that still look active, and scores difficulty when we have enough signal. You still have to read the thread. You should not have to wade through a graveyard first.

If you already know the kind of project you want, browse beginner-friendly projects and jump from a project page into its open issues.

Method 2: GitHub search (with 2026 filters)

Use GitHub when you want a specific repo, org, or language that is not in a hub yet. Start narrow.

Open issues labeled for beginners in JavaScript:

label:"good first issue" is:open language:javascript

Python, some stars, recently pushed (so you skip abandoned repos):

label:"good first issue" is:open language:python stars:>100 pushed:>2026-01-01

One repository:

repo:facebook/react label:"good first issue" is:open

Useful operators:

is:open so you do not read closed work
language: for the stack you can actually patch
stars:>100 as a crude “someone else uses this” filter
pushed:>2026-01-01 (or a date from the last few months) so the default branch is not a museum
label:"help wanted" if you want a wider net after you have one merge

GitHub will still show stale and claimed issues. Treat search as a second pass, not the default.

Method 3: Go to a project you already use

If you already depend on a library, start there. You will understand the product, and maintainers notice people who hang around.

Read CONTRIBUTING.md and the code of conduct.
Filter the Issues tab by good first issue.
Join whatever chat they use only if you have a specific question. Do not announce yourself and vanish.

For the Git workflow after you pick something, use the first pull request guide.

How to tell an issue is worth your time

Not every good first issue is a good use of a Saturday.

Age and activity. An issue from last year with no comments on a quiet repo is usually stale. Look at recent commits, recent merged PRs, and whether maintainers still reply.

The comment thread. Read all of it. If someone said they are working on it last week, pick another. If someone said that six months ago and went silent, ask once, then wait a couple of days.

Clarity. You want: the problem, a file or area to touch, and what success looks like. Vague issues are fine if the maintainer is responsive. They are a trap if they are not.

Your actual skill. Match the language you write. A docs fix is a valid first contribution. A framework you have never opened is extra time, not extra credit.

Help Wanted’s difficulty score is a hint, not a promise. The issue body and the repo’s review speed matter more.

From issue to pull request

Once you have a candidate:

Comment that you want it. One short note, plus a clarifying question if the issue is fuzzy. Do not claim five issues.
Set up the repo. Fork, clone, branch. Details are in the first pull request guide.
Keep the diff small. Do what the issue asks. Do not reformat the file.
Open the PR against the issue. Link it (Fixes #123). Describe what you changed and how you tested it.
Stay for review. First PRs get comments. That is the job.

If you ignore contribution guidelines, you will redo the work. If you disappear after review, the issue stays open and the next person has to unwind your branch.

Seasonal path: Hacktoberfest 2026

October still concentrates a lot of first-time contributors. In 2026, Hacktoberfest is not a “open four PRs, get a shirt” contest the way older years were. Confirm the current rules on the official site before you plan around swag.

What did not change: maintainers still want useful patches, and they still reject spam. If you want a merge during that rush, pick a real issue the same way you would in March. I wrote that up in Hacktoberfest 2026: find a good first issue that will actually get merged.

What this looks like on GitHub and in interviews

You do not need a cinematic origin story. Merged pull requests show up on your GitHub profile. They are concrete work you can point to in a screening call: the issue, the diff, the review, what you would do differently.

If the reason you are doing this is a job search, read how to build a developer portfolio through open source after you have one merge, not before you have an issue.

FAQ

What is the difference between a good first issue and help wanted?

good first issue (and close variants) means the maintainer thinks a newcomer can finish it. help wanted means they want extra hands. That second label can be a gnarly bug. Start with the first label unless you already know the codebase.

The issue looks claimed. Can I still take it?

Not immediately. If someone commented that they are working on it recently, leave it. If the claim is old and there is no PR, you can ask the maintainer whether it is free. Do not open a competing PR to “speed things up.”

Do documentation-only pull requests count?

Yes. A docs fix that lands is a real contribution: you used the workflow, survived review, and improved the project. It is a weak portfolio on its own if you never touch code, but it is a valid first merge. Skip drive-by typo PRs on files you did not read.

How do I know the project will review my PR?

Check the default branch date, the last few merged PRs, and how long those reviews took. A popular repo that ignores pull requests is worse than a smaller repo that merges weekly.

Should I comment before I write any code?

Usually yes, unless the issue already says “no need to ask, just open a PR.” A comment saves you from duplicating work. Keep it short.

Start here

Open helpwanted.dev, or a language hub for Python, TypeScript, or JavaScript.
Pick one issue that matches a language you know.
Follow the first pull request guide through review.

Every maintainer you will hear from started with a first merge. Make it a small one on a repo that still answers.