That question is the whole idea behind the first-timer view of the Porchlamp rankings. It ranks nearly 2,000 projects for someone sending their very first change.

What makes a project good for a first pull request?

Most of the score comes down to two questions.

Do people answer? This is responsiveness, 35% of the score: how quickly a person replies to an outside pull request, and how many reach a decision.

Is a first change easy? This is accessibility, 30%: open starter issues, and whether first-time contributors get merged and come back.

Governance, how much other software depends on the project, and review practice share the rest. They matter, just less when you are new.

Which projects come out on top?

In the 14 October 2026 snapshot, the first-timer view starts with llama.cpp, Meshery, open-design, stdlib and Ant Design.

Some projects climb a long way compared with the default view. open-design rises 63 places, because its strengths are exactly the ones a newcomer needs.

Two labels that look odd at first

"B (capped)" is not a poor grade. Only part of that project's evidence could be measured, so its tier can't go higher yet.

The rank-change column compares this view with the default one. It is the same data weighed differently, not movement over time.

A one-evening routine

1. Shortlist two or three projects in a language you already use.
2. Open each verdict and read the outside pull requests behind it. Did a person answer?
3. Choose the one that answers, and start with a small, well-described change.

A high rank tells you where answers are likelier. It isn't a promise about your pull request.

Try it

See the first-timer view: projects most likely to answer a first pull request

What made you choose the project for your first pull request?

That's the short version of what I found when I split the Porchlamp data by package ecosystem. The longer version matters more, because the gap is real but easy to over-read.

What "unanswered" means

A black hole, in this data, is a project that leaves most outside pull requests with no human reply, review or merge for two weeks.

Only projects that can fairly be judged are counted: licensed, maintained software with at least ten outside pull requests in six months. That leaves 4,297 projects.

Do npm and PyPI projects answer fewer pull requests?

On average, yes. The six ecosystems fall into two groups.

Maven, crates.io, Go and systems projects sit close together, at about 1 in 5.

PyPI and npm sit roughly ten points higher, at about 1 in 3 and 3 in 10.

Inside the first group, the gaps are too small to rank. Maven, crates.io and systems projects are within a point of each other.

In Porchlamp's 14 October 2026 snapshot, 33.8% of judged PyPI projects were black holes, against 19.4% of Maven projects.

What the split can't tell you

It is not a verdict on a community. An ecosystem here is just the registry a project was sampled from, and each average mixes very different projects.

Size isn't controlled for. Bigger projects go quiet more often in general. If the npm and PyPI samples hold more big projects, part of the gap is size.

Some review happens off GitHub. Projects that review on Gerrit or a mailing list are left undecided, so they aren't in these numbers.

How to use it when you pick a project

Start in the ecosystem you already know. Knowing the code helps a first pull request far more than a ten-point average does.

Then judge the project, not the registry. Even in PyPI, about two in three judged projects are not black holes.

Let the ecosystem figure break a tie. Don't let it rule a project out.

Look up a single project

Every verdict in the Porchlamp rankings, with a filter for each ecosystem lists the outside pull requests behind it.

Which ecosystem do you contribute in, and does its number match how long your own pull requests waited?

It's worth the five minutes. In Porchlamp's October 2026 snapshot, about 1 in 4 active GitHub projects let most outside pull requests sit for two weeks with no reply from a person.

A "good first issue" label shows what a project hopes for. Its pull request history shows what actually happens.

Step 1: Find pull requests from people like you

Open the project's Pull requests tab and look at recent ones from people outside the team.

GitHub tags some authors as "First-time contributor". Those are the closest match to you.

Step 2: See what happened to them

For each one, ask two things. Did a person reply, review or merge it? And how long did that take?

A search filter speeds this up. Paste is:pr is:open review:none sort:created-asc into the search box to list open pull requests that nobody has reviewed, oldest first.

A few old ones are normal. A long list going back months is a warning.

Step 3: Don't let stars decide

Stars measure attention, not answers. In the same data, projects with 50,000 or more stars were almost twice as likely to go quiet as projects with 1,000 to 10,000.

That doesn't make big projects bad. Their queue is just longer.

Step 4: Make yours easy to say yes to

Keep the change small. Link the issue it fixes. Say how you tested it.

That can't guarantee a reply, but it lowers the cost of reading your work.

Or skip steps 1 and 2

The Porchlamp rankings run this check across 11,000 projects, and every verdict lists the pull requests behind it.

What do you look at first before sending a pull request to a new project?