“Awaiting review” is the state of a pull request after the author has opened it and before anyone has reviewed it. The code is written, the checks may be green, and the change is waiting on a person. On GitHub it shows as “Review required” when the repository needs an approval before merging, with the requested reviewers listed on the side.
Reviews get requested a few ways. The author picks reviewers by hand. A CODEOWNERS file assigns them automatically based on which files changed. Some teams rotate review duty or assign it from a team alias. GitLab does the same with reviewers, approval rules and code owners.
The wait is often the slowest part of shipping, and most of it is in the author’s control. Keep pull requests small enough to review in one sitting. Write a description that says what changed, why, and how to test it. Point at the risky part. Add screenshots for UI changes. Mark it as a draft until it is actually ready, so the request means something when it arrives.
If it has been a working day, a short, specific nudge is fine: “Could you look at the migration in this one today? It blocks the release.” If it keeps happening, it is a team process question, not a personal one. Some teams set an expected review time so nobody has to guess.
Reviewing other people’s pull requests is the fastest way to get yours reviewed. It is also how you learn the codebase.
The piece says “AWAITING REVIEW.” It does not say since when.
In the wild
This one’s been awaiting review since Tuesday. Could someone on payments take a look? It’s about 120 lines.
