A good first issue is a label a maintainer put on a GitHub ticket. That is the definition. It is not a difficulty score, a merge promise, or a task that is small in the language you happen to write.
This page is what that label means, what the nearby strings mean, and how to tell when the badge is leftover. It is not a hunt. Hunting is how to find good first issues. It is not GitHub search operators. It is not a week-1 map or a git tutorial. Those are how to contribute to open source and your first pull request.
You do not need a taxonomy. You need to stop treating a colored badge as a contract.
The actual definition
GitHub ships a default label named good first issue (spaces, three words). The official description is blunt: it indicates a good issue for first-time contributors.
A person with triage access clicked that label. GitHub did not score the ticket. An algorithm did not certify it. Nobody promised the task would stay small, stay unclaimed, or still match the code.
GitHub uses that specific string in a few product surfaces, including a repository’s Contribute page. That is why the spaced name matters. Many projects never use the default. They invent a hyphenated twin, an easy tag, or a home-grown effort scale. The intent can be the same. The string is not.
A useful first issue, when the label is honest, has a small scope, a place to look, and a definition of done you can finish without the whole architecture in your head. The label is how a maintainer claims that. The thread is how you check.
The strings are different
GitHub search matches the label name exactly. good first issue is not good-first-issue. help wanted is not easy. If you query one string, you do not get the others.
| Label | What it usually means |
|---|---|
good first issue | GitHub’s default beginner label. A maintainer thinks a newcomer can finish it. This is the string that feeds the repo Contribute page. |
good-first-issue | Same intent, hyphenated. A custom label. Search for the default will not return these. |
help wanted | Maintainers want extra hands. Difficulty is unbounded. Onboarding is not the point. |
easy | Lower complexity, in that project’s opinion. Not reserved for first-timers. Easy on a compiler is not easy on a docs site. |
E-easy | Common on Rust projects. An effort tag (E- = effort), not GitHub’s beginner label. Mentoring may or may not exist. |
docs / documentation | Type of work, not difficulty. GitHub’s default is documentation; many repos use docs. A docs ticket can be a one-line fix or a rewrite of the architecture guide. |
first-timers-only | Reserved for people who have never contributed to open source. Stricter than good first issue. If you already have a merge, leave it. |
good first issue is an onboarding tag. help wanted is a backlog tag. You can close a help-wanted ticket as a first PR, but the label did not say you should.
Do not memorize a giant query. If you want operators, that is a different post. If you want a list that already collapsed the common beginner strings on active repos, use a live hub.
What the label does not mean
It will merge. A label is not a review SLA. The repo can be slow, overwhelmed, or polite-and-dead. Whether a patch lands is a property of the project, not the sticker. For that filter, read how to pick an issue that will get merged.
It is unclaimed. Labels do not clear when someone comments “I’ll take this.” Read the thread. A claim from last week is a stop. A claim from last year with no pull request is a question you ask once, then wait.
It is still accurate. People apply labels in a burst of cleanup and never revisit them. Code moves. The file named in 2023 may not exist. The bug may already be fixed on main with the issue left open. The badge does not expire.
It is small in your stack. “First issue” is relative to that codebase. A first issue on a language you do not write is still a new language. A first issue that needs the project’s custom build, a hardware device, or a week of context is a first issue for someone else.
The label is a hint a volunteer typed. Treat it like one.
How to verify in the thread
Open the issue. Read the body and every comment. You are checking whether the label is still true, not whether the title sounds friendly.
Recent maintainer reply. You want a human with triage or commit access in the thread, recently — not only the original report and a drive-by “same bug” from 2024. A bot that auto-labeled it on open does not count. If the last maintainer comment is years old, the label is archaeology.
Scope. A file, a function, a page, a failing test, a specific sentence in the docs. “Improve the UX” is a wishlist. “Add a sentence to CONTRIBUTING.md explaining how to run tests” is a first issue. If you cannot point at where the change goes, you do not have a first issue. You have a slogan.
Repro steps, or a done-state. Bugs need a way to see the failure. Docs and copy need a before/after. Features need a one-screen behavior. If the ticket is “we should support X” with no acceptance line, it is a roadmap item wearing a beginner badge.
Not a three-year-old wishlist. Sort the dates. An issue opened in 2019, labeled once, never touched, on a repo that has since rewritten the module, is not a first issue. It is a fossil. Skip it even if the badge is still green.
If those checks fail, pick another ticket. You are not being picky. You are refusing to spend a weekend on a sticker.
Then go look at live issues
I built Help Wanted so this check starts on a live index, not a gist of famous names. The product is the hub, not a frozen gallery.
- All languages: https://helpwanted.dev/
- Python: https://helpwanted.dev/language/python
- TypeScript: https://helpwanted.dev/language/typescript
- JavaScript: https://helpwanted.dev/language/javascript
- Projects: https://helpwanted.dev/projects
Open a hub in a language you already write. Open one issue. Run the thread checks above. Then comment on one.
How to hunt, filter, and skip graveyards: how to find good first issues. Which projects are even a reasonable first home: best open source projects for beginners. This page will not re-teach that.
Related
- How to find good first issues — how to hunt
- How to pick an issue that will get merged — competition, claims, review speed
- How to contribute to open source — why, which lane, week-1 plan
- Best open source projects for beginners — living project index, not a logo list
FAQ
Are good first issue and good-first-issue the same thing?
Same idea, different strings. GitHub’s default is three words with spaces. Plenty of repos created a hyphenated label instead. Search is exact, so a query for one misses the other. Read the label on the issue. Do not assume the hyphenated form is a synonym GitHub will fold in.
If it has the label, will my pull request merge?
No. The label is a maintainer’s guess that a newcomer can attempt the work. Merge depends on whether the repo still reviews, whether the issue is still real, and whether your diff matches the request. Check recent merged PRs on that repo. The longer version is how to pick an issue that will get merged.
What is the difference between good first issue and help wanted?
good first issue (and the hyphenated twin) is an onboarding tag. help wanted means they want help, period. That second label can be a gnarly bug, a design debate, or a feature with no spec. Start with a first-issue label unless you already know the codebase.
The issue is three years old and still labeled. Is it still a good first issue?
Usually no. A leftover label is common. Look for a recent maintainer reply, a still-valid path, and a done-state that matches the current tree. If the last activity is a 2021 thumbs-up, close the tab. The badge did not update itself.
I write Python. Can I take a good first issue on a repo I cannot run?
Not as a first contribution. “Good” is relative to that project, not to your résumé. Match the language you already write. A docs issue still needs you to install or at least read the thing you are documenting. If setup is the actual work, it is not your first issue.
Start here
- Open helpwanted.dev, or a language hub for Python, TypeScript, or JavaScript.
- Pick one labeled issue in a stack you know. Read the whole thread with the checks above.
- If the label is still true, comment and follow how to find good first issues into a small PR. Week-1 map: how to contribute to open source.
The badge is a hint. The thread is the issue. Use the one that is still real.