How to find open source issues that are actually available
Most advice about contributing to open source points you at curated lists of "good first issues". Most of those issues are already taken. This is a short, practical guide to finding GitHub issues you can genuinely claim, written for first-time and early contributors.
Why most issue lists are dead leads
When an issue reaches a curated list or a blog post, it has usually been visible for days or weeks. In a popular repository that is an eternity. By the time you read it, one of three things has almost always happened:
- Someone was assigned. The maintainer gave it to a contributor, but the list you found it on never updated.
- A pull request is already open. The issue still looks free: it is open and unassigned. But someone has a PR up that says "fixes #123", and GitHub has quietly linked it. You only discover this after reading the whole thread.
- It went stale. The issue was fixed in passing, superseded, or the project moved on, and nobody closed it.
Beginners burn their motivation on exactly these dead leads: you pick an issue, set up the project, start writing code, and then find the comment saying someone else is on it. The problem is not your skill. The problem is that you were searching where everyone else already searched, days later.
What "available" actually means
Before investing time in any GitHub issue, check four things:
- Open. Obvious, but stale lists routinely link to closed issues.
- Unassigned. If GitHub shows an assignee, it is taken, whatever the thread says.
- No linked pull request. Look for "linked a pull request that will close this issue" in the timeline, and for the Development section in the sidebar. An open PR with a closing reference means the issue is claimed in practice.
- Fresh. The younger the issue, the higher the odds nobody is quietly working on it. An issue opened an hour ago in an active repo is a real opportunity; the same issue three weeks later usually is not.
open source feed automates all four checks. It discovers new issues in popular repositories (100 stars and up) within minutes of being opened, keeps only the open, unassigned ones with no linked PR, re-verifies them against GitHub on a schedule, and expires everything after two days. If an issue is in the feed, it was claimable as of the last verification pass.
A workflow that works
1. Search fresh, not curated. Speed matters more than curation. Watch new issues as they appear instead of reading week-old lists. That is the entire reason this feed exists; the RSS/Atom feed lets your reader do the watching.
2. Use the zero-comment signal. An issue with no comments has no discussion, no "can I take this?", no maintainer promises to anyone. Those are the truly uncontested ones, and the feed marks them.
3. Filter to your strengths. Start with a language you know and labels that match your level: "good first issue" and "documentation" for a first contribution, "bug" or "help wanted" once you are comfortable. Star filters let you choose between huge projects (more process, more review) and smaller active ones (faster merges).
4. Claim it properly. Comment on the issue first: one line saying you would like to work on it and how you plan to approach it. Read the project's CONTRIBUTING.md before writing code. Keep your first pull request small and focused; a tidy 20-line fix merges faster than an ambitious rewrite, and merged is what counts.
5. Move on quickly when it is gone. If a maintainer says it is taken, or a PR appears, drop it without ceremony and pick the next one. Fresh issues appear all day, every day. The feed's "not interested" button exists for exactly this.
Start with your language
Each page below shows only fresh, claimable issues in that language, updated every few minutes:
Or read how the pipeline works if you want the details behind the feed: polling cadence, verification, and why issues expire.