A live repo can still have issues that will never merge. This is about the issue, not the project: is this thread specified enough, unclaimed, and still on a maintainer’s radar?

Project health is a different check. How to hunt is a different check. Git is a different check. Here you already have a candidate and you are deciding whether to spend a weekend on it.

Specified vs wishlist

A mergeable issue is a job, not a vibe.

Look for:

Repro steps a stranger can follow
Expected vs actual behavior
A file path, function, or error string — some handle on where

A wishlist is the opposite: “would be nice if we supported X”, “maybe refactor this”, “UX feels off”. No steps. No expected vs actual. No file. You can write a patch. You cannot prove it is the patch they wanted.

If you cannot describe the change in one sentence tied to a path or a failure, skip it.

Claimed threads

Read the comments before you write any.

“I’ll take this” from three months ago with no pull request is not a free issue. It is a stalled claim. Maintainers often wait for that person. Sometimes they forget. Either way, your PR lands in a thread that already has an owner in someone’s head.

If the last “I’ll take this” has no linked PR, leave it. Find a thread nobody has reserved.

Competition

Eight people asking to be assigned is not demand. It is a queue.

You are not first. You will not be first. The maintainer will either assign someone else, ignore the pile, or close the issue as stale while you are still writing tests.

If the thread is a waiting room, walk out.

Maintainer replied in the last ~30 days

This is a heuristic, not a statistic.

Open the issue. Find the last comment from someone with write access — a maintainer, a listed owner, not another first-time contributor. If that reply is older than about a month, the thread is cold. Your work will sit.

A recent maintainer reply — even “please add a test” or “yes, that’s a bug” — means a human might review what you send.

No reply from maintainers at all? Same skip. The issue is a message in a bottle.

Leftover labels

Labels lie longer than comments.

needs reproduction on a thread that is already a design debate is leftover. Nobody is waiting for your stack trace. They are arguing about the API.

good first issue on a 40-comment architecture fight is leftover. The label was true once. It is not a size estimate now.

Read the last few comments, not the sidebar. If the conversation left the original bug, the label did not come with it.

One issue, one comment, then work

Do not claim five issues. Do not spray “I can work on this” across a label search.

Pick one. Leave one short comment: you are taking it, and you will open a PR. Then work.

Five claims is how threads die. One comment plus a PR is how they close.

After you pick

If the issue passed the checks above, start from issues that are already filtered for contribution — not from a random GitHub search.

FAQ

How do I tell a specified issue from a wishlist?

Specified has repro steps, expected vs actual, and a file path or error to grab. A wishlist has a desire and no test. If you cannot write a failing case from the report, it is a wishlist.

Someone said they would take it months ago. Can I start anyway?

No. Treat an old “I’ll take this” with no PR as a live claim. Your patch will conflict with a person the maintainer still remembers. Pick an unclaimed thread.

Eight people asked to be assigned. Is that a popular, easy issue?

It is a crowded one. Popular is not mergeable. If assignment comments outnumber technical comments, skip it.

The issue has `good first issue` but the thread is a design debate. Should I still try?

No. Trust the comments, not the label. good first issue and needs reproduction stick around after the issue has moved on. A design debate is not a first patch.

Should I comment on several issues so I have a backup?

No. One issue, one comment, then work. Backup claims are how you become the stale “I’ll take this” on someone else’s board.