This is a project health check. It tells you whether a repository is still worth your Saturday. It is not how to pick an issue, not what a beginner label means, not GitHub search, and not git.

A dead GitHub repo can still look alive: stars, an open issue tracker, a README that says contributions are welcome. Health is whether someone still merges. Stars measure attention. They do not measure a review queue.

Once the repo looks alive, pick a ticket with how to pick an issue that will get merged. Finding labeled work is how to find good first issues. The week-1 map is how to contribute to open source. Stay here until you would actually fork.

Stars are not health

Star count is a popularity contest. People star READMEs, assignment writeups, and tools they used once. They rarely unstar a project that went quiet.

A high number does not mean:

Pull requests get reviewed
Issues get closed
CI is green
A second person can merge if the owner is away

A low number does not mean the project is dead. Plenty of small libraries merge every week. Use stars only as a crude “this is not an empty experiment” floor. Help Wanted’s project list already applies a modest one. After that, ignore the badge on the Code tab and look at merges.

Last merged PR, and last push on the default branch

Two different clocks. You want both.

Last push on the default branch means the branch moved: a commit landed. That can be the maintainer pushing their own work, a bot bumping a lockfile, or a merge. It is necessary and not sufficient. A repo can push for months and never accept an outsider patch.

Last merged pull request means reviewed work landed through the PR queue. That is the clock you will wait on. If nobody has merged a PR in a long time, yours will not be the exception.

Where to look, on that repository:

Insights → Pulse. Pick a window (a week or a month). Pulse shows commits to the default branch, pull requests opened and merged, and issues opened and closed. If the merge count is zero in every window you try, stop.
Pull requests, merged filter. Open the Pull requests tab. Switch to Closed and filter to merged, or use the merged view in that list. Sort by recently updated. Read the dates on the last few merges, not the open count.
Code tab. The latest commit date on the default branch is last push. Use it to confirm the branch is not a museum. Do not treat it as last review.

A project that merges its own maintainer PRs and ignores everyone else will look fine on Pulse until you read who the authors are. Spend thirty seconds on the merged list. If the only merges are the owner’s, treat review as unproven.

Review latency: open PRs with no maintainer comment

Merges in the past do not guarantee a review in the present. Open the open pull request list.

You are looking for maintainer silence, not for whether a particular issue is claimed. Scroll the oldest open PRs. For each, check whether anyone with triage or commit access left a comment after the author opened it. Bots, CI, and the author’s own pings do not count.

If several PRs have sat for months with no maintainer comment, review latency is the health problem. Your first contribution waits in that same queue. A pile of open PRs with recent maintainer replies is a different picture: busy, not dead. Slow is survivable. Silent is not.

Do not confuse this with reading one issue thread. That filter belongs to how to pick an issue that will get merged. Here you are grading the review desk, not the ticket.

CONTRIBUTING.md, code of conduct, license (Community standards)

GitHub’s Insights → Community page is a checklist: description, README, contributing guide, code of conduct, license, and the usual templates. Presence is a signal. It is not a guarantee they will review you.

What the files actually tell you:

CONTRIBUTING.md (or equivalent) — they wrote down setup, branch rules, tests, how to open a PR. Missing or fighting the README means friction. Present means someone thought about onboarding once.
Code of conduct — they named a behavior bar. Useful if you need to know how reports work. It does not mean the project is kind, fast, or staffed.
License — you need one before you copy code. A missing license is a reason to walk away, not a style nit.

A complete Community checklist on a quiet repo is paperwork. An incomplete checklist on a repo that merges weekly is still a repo that merges weekly. Use the files to decide how annoying setup will be. Use the merged PR list to decide whether to start.

Issue tracker: are bugs closed, or only opened?

Pulse again: issues opened versus issues closed in the window. Then open the Issues tab and sort closed issues by recently closed.

A healthy tracker closes things — bugs, duplicates, “fixed on main,” “won’t do.” It does not have to close as many as it opens. Backlogs grow. What you do not want is a graph that only rises: reports come in, nothing is closed, and the last successful close is old.

An issue tracker that only opens is a support inbox, not a project. You can still file a careful bug. You should not plan a first merge there.

This is not a lesson in writing issues, and it is not “needs reproduction” as an issue-pick heuristic. Those are other posts. Here the question is whether triage still happens at all.

CI red on the default branch

Look at the latest commit on the default branch. GitHub shows a green check or a red X next to the SHA. The Actions tab shows the same workflows.

If main (or master) is red, one of two things is true: the suite is broken and nobody is watching, or the suite is flaky and everyone ignores it. Your pull request will fail the same checks, or you will spend the contribution fighting a build that was already on fire.

A yellow or missing status can mean they do not run CI. That is a different cost — you will not get a free smoke test — not automatically a dead project. Red on the branch you must target is the smell. Do not “fix CI” as your first PR unless an issue asked for that and a maintainer still answers.

One-maintainer bus factor

Open Insights → Contributors, then look at who pressed Merge on the last few pull requests. You are asking how many people can land a patch if one of them disappears.

A one-maintainer project is normal. It is not a reason to skip the repo. Many good libraries are one person who still reviews. The health question is whether that person is present: recent merges, recent comments on other people’s PRs, recent pushes that are not only dependabot.

What you cannot know from the graph: vacation, a day job, or a maintainer who reviews in bursts. Do not invent a percentage of “abandoned solo projects.” If the merge button has one name and that name has been quiet, you have no backup reviewer. Pick another repo, or wait until they are back — do not open a PR to poke them.

Help Wanted already biases toward active repos. Still verify.

I built Help Wanted so you do not start from a gist of famous names or a raw good first issue dump. The index keeps labeled issues tied to projects that still look active. The project directory is the hub for this check: browse repos, then open GitHub and run the list above.

Language hubs if you already know the stack:

All issues: 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

Bias is not a substitute for the PR list. Before you write code, open merged pull requests on that repo. Confirm a recent merge, glance at open-PR silence, and look at default-branch CI. Then start. The living project index is best open source projects for beginners; this page is the health bar those hubs still expect you to run.

How to find good first issues — how to hunt labeled work
How to pick an issue that will get merged — competition, claims, the ticket itself
Best open source projects for beginners — living project index, not a logo list
How to contribute to open source — why, which lane, week-1 plan

FAQ

Do stars mean an open source project is active?

No. Stars are attention. They do not move when a project stops merging. Check last merged pull requests, review comments on open PRs, and whether issues still close. A quieter repo that merges weekly is more worth your time than a popular one that does not.

Last push or last merged PR — which should I trust?

Both, for different reasons. Last push on the default branch tells you the tree is not frozen. Last merged PR tells you the review queue still empties. A repo that only pushes is a maintainer diary. You need the merge clock.

The Community standards checklist is all green. Will they review me?

Not because of the checklist. CONTRIBUTING.md, a code of conduct, and a license are onboarding and legal signals. They do not create a reviewer. Use them to see whether setup was written down. Use the merged PR list to see whether anyone is home.

CI is red on the default branch. Should I still open a first PR?

Usually no. Your branch will fail the same workflows, or you will inherit a broken suite. Skip it unless a current issue asks you to fix that build and a maintainer still replies. Red main is a health smell, not a beginner task.

Help Wanted already lists active repos. Why check GitHub myself?

The hubs bias toward projects that still look active. They do not watch every review queue in real time. Before you spend a weekend, open that repo’s merged PR list, scan open PRs for maintainer silence, and look at default-branch CI. Five minutes on GitHub beats a patch nobody will see.

Start here

Open helpwanted.dev/projects, or a language hub for Python, TypeScript, or JavaScript.
Pick one repo. Ignore stars. Check last merged PRs, open-PR review latency, Community files, issue closures, default-branch CI, and who actually merges.
If the desk is staffed, pick a ticket with how to pick an issue that will get merged and follow how to find good first issues.

A dead GitHub repo wastes your time even when the README is friendly. Run the health check before you fork.