What to Do When a Good First Issue Is Already Taken or Not Beginner-Friendly

If an issue on Good First Issue turns out to be claimed, stale, or harder than its label suggests, use the Report a problem with this issue option on the issue card and pick the reason that fits: Already taken, Not beginner-friendly, Stale or invalid, or Something else. That report is the site's built-in feedback loop, and it keeps the listing accurate for the next contributor. Before you invest time in any issue, verify its current state on GitHub — the listing shows a snapshot, not a live lock.

Why this happens

Good First Issue aggregates issues that maintainers have tagged as beginner-friendly, and the page notes it indexes 139k beginner-friendly issues across 241k repositories. Those numbers move constantly. An issue can be:

• Claimed by someone after it was indexed but before you opened it
• Re-tagged or re-scoped by a maintainer
• Left open long past the point where it's still relevant
• Labeled beginner-friendly by a maintainer whose bar differs from yours

The site's own difficulty and friendliness scores are signals, not guarantees. For example, a card might show Difficulty 1/5, Under an hour, Newbie friendliness 98/100 for a simple typo fix, while another shows Difficulty 2/5, 1–3 hours, Newbie friendliness 78/100 for something like a NaN-return bug in a modeling library. The second is still a "good first issue" by label, but it asks more of you.

What to check before you start

Run this quick pass on the issue card and the linked GitHub thread:

1. Open the GitHub issue. Look at the comment count and the most recent comments. A card showing "1 comment" may already contain a claim.
2. Check assignees. If someone is assigned, treat it as taken unless the assignee has gone quiet for a long stretch.
3. Scan for "I'll take this" comments. Even without a formal assignment, a recent claim usually means someone is working on it.
4. Read the last activity date. The cards show an opened date (e.g., "Opened Sep 27, 2026"). An issue with no movement since then is a candidate for the Stale or invalid report.
5. Read the actual task. If the description assumes context you don't have, it may be mislabeled as beginner-friendly — that's exactly what the Not beginner-friendly reason is for.

How to report it

On the issue card, click Report a problem with this issue. A short form appears with these options:

Select one, optionally add detail, and send. The report is a signal to the site, not a message to the maintainer — it won't notify the project or change the GitHub issue itself.

What to do next

• If it's taken: move on. Don't comment asking to be next in line; that adds noise. Pick another issue from the same technology filter (JavaScript, Python, Go, or all categories).
• If it's not beginner-friendly: use the difficulty and friendliness scores as a filter and aim for cards showing Difficulty 1/5 and a high friendliness score.
• If it's stale: report it and skip. A maintainer who hasn't touched the issue in months is unlikely to review your pull request quickly.
• If you're unsure: check whether the card shows a maintainer response time, such as "Maintainers usually reply within 1 day." A responsive project is a better bet for a first contribution than a fast-looking issue in a quiet repo.

The site also offers a project-level shortcut: "Or pick a project: the ones most likely to merge your first pull request." If you keep hitting claimed or mislabeled issues, starting from that list is a more reliable route than browsing individual cards.

The short version

Reporting is the correct action for a bad listing, but it doesn't unblock you. Verify the issue on GitHub first, report the mismatch, then move to a card with a low difficulty score, a high friendliness score, and recent maintainer activity.