Method
How we decide what gets listed
We scanned 4,000 issues carrying a beginner or help-wanted label and listed 443. Here is exactly what happened to the rest.
- 2,268 not startabledead project, too vague, or an umbrella issue
- 1,177 already takensomeone has a pull request open — GitHub still shows these as unassigned
- 112 held backcleared, but capped so no single project floods the board
- 443 listed todayyou can start any of these right now
Why issues were rejected
| Reason | Issues rejected |
|---|---|
| Repo not viable — archived, unlicensed, or no recent commits | 1,251 |
| Already taken — assigned, or an open/merged pull request references it | 1,177 |
| Not enough context to start — empty or template-only body | 770 |
| Stale or blocked — no activity in months, or an umbrella/tracking issue | 118 |
| Label farming — a contribution playground or star-farming repo | 112 |
| Not a real, open issue (bot-authored, locked, or actually a PR) | 17 |
The gates, in order
An issue must pass every one of these. No score can rescue a failure.
1. It must be genuinely takeable
Nobody assigned. No open pull request referencing it. No merged pull request that should
have closed it. No unexpired claim in the comments. This is the check other tools
don't do — GitHub's own no:assignee filter misses every issue where
someone quietly opened a PR, which is the most common way an issue is really taken.
2. The project must be alive
Not archived, issues enabled, pushed within 60 days, at least two different people committing in the last 90 days, and an OSI-approved licence. A repo with no licence isn't legally contributable, so we exclude it regardless of how good the issue looks.
3. The issue must still be relevant
Activity within 120 days, no blocking labels, and not an umbrella issue with a long task list hiding weeks of work behind a friendly label.
4. There must be enough to go on
A real body, not an unfilled template. Enough context that you could open the file and start.
5. The repo must not be farming contributors
Projects that label most of their backlog "good first issue" are farming for stars or contributors, and the label carries no information there.
Then we rank what's left
Ranking weighs maintainer responsiveness most heavily — whether outside pull requests actually get merged, and how fast maintainers reply. An issue you can start but whose PR will never be reviewed is still a wasted evening.
What we can't check
Coordination that happens off GitHub — a Discord thread, a maintainer's private plan — is invisible to any tool built on the API, including this one. We verify every listing within 24 hours, and every row says when. That's an honest ceiling, not a perfect one.