Finding an Open-Source Project Worth Your First Contribution

You find a repository with a "good first issue" label on something that looks approachable. You read the issue, read the linked file, write a careful patch, and open the PR. Then you wait.

A week passes. You check the tab once a day, then once every few days, then you stop checking as often because checking and finding nothing feels worse than not checking at all. Four months later you notice the tab is still open. No comment, no review, no closure — just a PR sitting in a queue you can't see the size of. You close the tab yourself, quietly, and move on to something else.

Nothing about that story is unusual. It's also nothing you could have known from the label, the star count, or the README. The label said "good first issue." It said nothing about who reads issues, how often, or whether an external PR has ever actually been merged there.

So before you spend an evening on a patch: what could you have checked beforehand — in ten minutes, by hand, on the repo's own issue and PR history — that would have told you something closer to the truth?

Lesson

A label is a claim a project makes about itself. A merged PR is a thing that actually happened. Those are different kinds of evidence, and only one of them tells you what happens after you hit submit.

"Good first issue" is metadata someone attached, possibly months ago, possibly by a maintainer who has since moved to other work. It doesn't tell you the median time between opening a PR and getting a human response. It doesn't tell you whether the last five PRs tagged that way were merged, ignored, or auto-closed by a stale-bot. In the worked example later in this post, the open "good first issue" search on a genuinely active project returned zero results at the moment I checked it — while real external contributions, unrelated to that label, were being reviewed and merged in under three weeks.

That gap is the point. Labels are marketing, even when nobody intends them that way — they're a snapshot of intent, not a running log of behavior. Issue threads and merged pull requests are closer to a running log: timestamps, who commented, what they said, how long it took. Reading five of those by hand takes less time than writing the code for your first PR, and it tells you more about what happens after you submit it than any badge on the repository.

Checklist: five signals worth checking by hand

1. Time-to-first-response — but separate bot from human. Open the repo's most recent issues and note who leaves the first comment and how fast. Many projects run triage bots that reply within minutes with a template — label suggestions, a request for more info, a note about backlog policy. That speed is real, but it isn't review. Scroll past the bot comment and find the first comment from an actual maintainer account. That gap — sometimes minutes, sometimes days — is closer to what you'll experience once your PR is up. Check the commenter's role badge (MEMBER, CONTRIBUTOR, or nothing) if the platform shows one.

2. External-PR merge behavior. Search merged pull requests filtered to something like an "external" label, or scan recent merged PRs and check whether the author is listed as a core team member. For a handful of them, note the opened date and the merged date. A consistent multi-week gap tells you more than a single fast example — and a single fast example tells you almost nothing on its own.

3. Maintainer activity and release cadence. Look at the commit history on the main branch and the release/tag list. Are there commits in the last week? Do releases land on something like a monthly rhythm, or is the last tag from a year ago? Cadence is a proxy for whether anyone is actively steering the project right now, not just whether it once was.

4. CONTRIBUTING.md promises versus automation. Read the actual contributing guide — it's often not at the repo root. Note what it asks for (an issue first? explicit maintainer sign-off before you write code?) and whether a bot enforces that ask, or whether it's just a suggestion. Then look for a case where a maintainer overrode the stated rule for something small, like a typo fix. That tells you whether the written policy is rigid or whether maintainers use judgment.

5. Issue-triage patterns. Look at labels on the newest issues. Do they get sorted into categories (bug, enhancement, priority) shortly after opening, or do they sit unlabeled? Systematic triage is a weak but real signal that someone is actively managing the queue, not just occasionally glancing at it.

None of these, alone, tells you what will happen to your specific PR. Together, they tell you more than a badge does.

Proof

Checked at: September 2, 2026 — a nine-issue and six-PR hand sample, drawn from the newest open items, so it is right-censored where responses had not arrived at fetch. This is a point-in-time reading, not an endorsement of any project named below.

Worked example: cli/cli, GitHub's official CLI ("gh is GitHub on the command line," per its README).

Bot vs. human. Issue #14317 was opened 2026-09-02 at 06:01 UTC; a bot commented at 06:05 (~4 minutes) suggesting labels. Issue #14308, opened September 1, got a bot reply in about 3 minutes — its backlog template states plainly that the team is not committing to implement the request and that external contributions aren't being sought without a "help wanted" tag. On the human side: #14253, opened August 24, got its first maintainer (MEMBER) comment on August 28 — about 3.9 days later, asking for a screenshot. #14223, opened August 21, got its first MEMBER comment on August 28 — about 6.7 days later. Across the nine newest open issues at the time of the check, bot-comment median latency was roughly 3.5 minutes; human maintainer comments appeared on only 2 of the 9.

External merges. The "external" label marks PRs from outside the core CLI team; 920 merged PRs carry it. #14154 (opened by scarletkc) went from open on August 15 to merged September 1 — about 17 days, credited as a first contribution in the v2.99.0 release notes. #13787 (kofuk) ran roughly July 3 to July 16 — about 13 days, with a review comment reading simply "Thanks LGTM." #13886 (kobihikri) ran July 15 to July 21 — about 6 days.

Activity. v2.99.0 released 2026-09-01, following a roughly monthly cadence — v2.98.0 on August 20, v2.97.0 on July 31, v2.96.0 on July 2 (full release history). Trunk commits landed September 2, September 1, August 31, August 28, August 27, and August 26.

Written policy vs. exceptions. The CONTRIBUTING guide says the team accepts PRs for issues tagged "help wanted," and asks contributors not to open PRs without that tag or explicit acceptance criteria — external PRs against core issues won't be accepted otherwise. Yet #13940, a typo fix, got a bot warning about the missing help-wanted issue and a four-day auto-close notice — and maintainer williammartin approved and merged it the same day, July 22. The project's own triage doc says tiny, obviously-mergeable fixes like typos mean review, test, and merge. Automation sets the default rule; a human made the exception.

Triage. The newest open issues carry labels like needs-triage, enhancement, bug, and priority-3 (#14317, #14308, #14297) — a pattern, not a promise.

Contrast, no verdict. jqlang/jq shows 117 open PRs, the oldest sorted by creation dating to #458 from 2014 and #1103 from February 2016. That is a dated fact, not a judgment — years-open PRs can reflect real design disagreements rather than neglect, and this article draws no conclusion about jq either way. Its absence from the checklist above means nothing about the project.

A few things worth saying plainly: the names here are illustrations, not recommendations. Past responsiveness is not a prediction of what will happen to your PR. cli/cli is staffed by GitHub employees, so its latencies are not representative of a volunteer-run project — treat that difference as real, not a footnote. No project here is called friendly or unfriendly. Maintainers are people with variable time and energy, and the numbers above describe a queue, not a character trait.

Try it tonight

Before you write a line of code for a project you're considering, spend twenty minutes on its issue tracker and PR history instead. Read five recent issues and note who responds first — bot or human — and how long it takes. Find four merged external PRs and note the gap between opened and merged. Time the first human response, not the first automated one. That's the whole exercise, and it's cheaper than a four-month wait.

If you're trying to decide whether to depend on a project rather than contribute to it, the evidence you'd gather is nearly the same — just aimed at a different question. See oss-signal-assess-new-github-repo for that version, or browse the rest of the open-source signal series.

FAQ

How long should a first PR take to get reviewed?

There is no fixed answer. In the sample above, external merges landed in roughly six to seventeen days, but a hand sample is not a distribution. Judge each repo from its own recent threads, not from a number in this article.

Are good first issue labels useful?

In cli/cli, the open good-first-issue query returned zero results at the time of this check, while real external PRs were being merged. The label is a claim a project makes about itself; issue threads and merged PRs are things that actually happened. Some projects do maintain these labels carefully — verify per repo.

Is cli/cli a good first project for me?

That framing does not have a yes-or-no answer here. cli/cli is used as an illustration, not an endorsement, and it is staffed by GitHub employees, so its response times are not typical of volunteer-run projects. Your constraints — time, skill, interest — decide, not this article.

---

Disclosure: this is a first-party piece from the ranex.dev open-source signal series. Ranex has no affiliation with cli/cli, GitHub, or the jq project. Research and drafting were AI-assisted; human review is required before publication.