A Ready for Review pull request contains properly prepared, self-contained changes that are ready for colleagues to examine. The author explicitly promotes a Draft PR to this state, then awaits review. section 2.3.4
Before promoting a PR, make the review manageable and reduce avoidable back-and-forth:
- Review your own changes first: resolve questions, fill in missing context, consider edge cases, and check the fit with the overall architecture. section 2.4.2
- Break the work into distinct, clear, complete, and feasible portions instead of submitting a large or continually changing PR. section 2.4.2
- Use Draft when work is unfinished or when you want feedback on an idea without committing to the final implementation. section 2.3.4
- Align with the team on what each state means and document that agreement so authors and reviewers interpret the status consistently. section 2.3.4
From experiment to review
A developer opens two fully prepared draft PRs to compare Materialize and MUI CSS card implementations. After the team chooses Materialize and the feature is complete, the Materialize PR is promoted to Ready for Review; the alternative is deleted. section 2.3.4
Figure 2.6 The different states of PR review and their meaning
Use the state diagram to distinguish Draft, Ready for Review, and In Review, including who is expected to act next. section 2.3.4
