What to Do When Your Pull Request Is Ignored

Leonid Bugaev
|
(Updated September 1, 2026)
|
5 min read
pull-request beginners contributing github

The pull request is open. CI is green. Nobody has said a word.

This page is the wait, the one bump, and when you close it yourself. It is not how to answer a review that already exists — that is how to respond to code review. It is not what to do after a merge — that is after your first open source contribution. It is not how to pick the next ticket — how to pick an issue that will get merged. Health checks live in how to tell if an open source project is active; this page only uses them on your silent PR.

Silence is not a personal insult. Most of the time it is a dead queue.

Timeline: green, wait ~7 days, one bump, stop

Clock starts when the PR is ready and CI is green, not when you first pushed a draft.

  1. CI green. Red checks are not “ignored.” Fix them. Do not bump a failing PR.
  2. Wait about seven days. Maintainers batch review. A weekend plus a work week is normal. Do not comment “any update?” on day two.
  3. One polite bump. One comment. Facts. Then wait another stretch if you want — or leave. Do not stack a second ping.
  4. Stop. Two weeks of nothing after a bump is enough. Close your PR or walk away. Daily pings do not create review capacity.

If they already left a review, you are on the review page, not this one.

Check the repo, not your feelings

Before you assume they hate the patch, look at the same signals you should have used before you wrote code.

The full health check is how to tell if an open source project is active: Pulse, merged list, review latency, bus factor. This page will not rewrite it. If those checks fail, the ignored PR is the symptom. Leave.

What a bump looks like

One comment on your PR. Not an issue. Not chat. Not email.

Keep it short:

No @everyone. No tagging every CODEOWNER. No “friendly reminder” every morning. No opening a second PR to get attention.

If GitHub lets you request reviewers and you have write access, one request is enough. First-timers usually cannot; the comment is the bump.

When to close your own PR

Close it when:

Closing is polite. It unblocks the issue. Add one line: you are closing due to no review / you will take the change elsewhere. Then stop. Do not delete the branch until you copied anything you still want. Do not flame the README.

Take the work elsewhere: another specified issue on a live hub, or your own repo if the patch is only useful to you. Do not duplicate-spam the same diff at five similar projects.

Draft vs ready

If you opened a draft, they may never see it. Drafts do not auto-request code owners and do not look mergeable. Mark Ready for review in the merge box when the diff is on-topic and CI is green. The GitHub buttons for that live in how to contribute to open source on GitHub — one sentence here is enough: draft is invisible-by-default, ready is the start of the wait clock.

FAQ

CI is still running. Should I bump? No. Wait for green. A bump on a red or pending check is asking them to review a broken diff.

They reacted with an emoji and nothing else. That is not a review. Wait the seven days. One bump. Do not treat a thumbs-up as a merge promise.

Can I @ the last person who merged? Once, only if they are clearly the reviewer of record and the project is small. Do not @ the whole org. Do not @ people who have not touched the repo in a year.

Should I open the same PR on a fork that still merges? Only if the original is unmaintained and you will actually use the fork. Say so when you close the original. Do not keep both open.

The issue still says help wanted. Labels rot. An ignored PR plus a dead merge list beats a leftover badge. Close, pick a specified issue on a repo that still merges.

The job is: green CI, wait about a week, one factual bump, then leave. That is the whole page.

Back to all articles Find projects that need your help