Pull requests that get good reviews

A 2,000-line pull request with the description "fixes" gets one of two reviews: a rubber-stamp approval, or a week of delay. Neither catches bugs. Small, well-described pull requests get reviewed quickly and properly. Most of what makes a review useful is decided by the author before the reviewer opens it.

#Keep it small and focused

• One change per pull request. A refactor, a bug fix and a new feature are three pull requests, even if you did them together.
• Separate moves from changes. If you rename files or move code, do that in its own pull request, so the reviewer isn't hunting for a logic change inside 40 moved files.
• Aim for something a reviewer can read in one sitting, usually a few hundred lines at most. Large features can be merged in steps behind a feature flag.

#Write a description that answers the reviewer's questions

A reviewer needs to know:

• Why this change exists: the problem or requirement, with a link to the work item
• What changed, in a sentence or two, and anything deliberately left out
• How it was tested, including anything manual
• Risks: migrations, configuration changes, behavior changes for other teams, anything that needs care when deploying

Screenshots for UI changes and example requests and responses for API changes save the reviewer from running the code just to understand it.

#Make it the default with a template

Azure Repos picks up a pull request template from a file such as .azuredevops/pull_request_template.md in the default branch:

## Why
<!-- The problem this solves. Link the work item. -->

## What changed

## How I tested it
- [ ] Unit tests
- [ ] Integration tests
- [ ] Manually verified:

## Deployment notes
<!-- Migrations, new settings, feature flags, anything to watch after release -->

Every new pull request starts with these headings, so writing a good description becomes the easy path.

#Let tools handle the trivia

Reviews shouldn't spend time on formatting or naming conventions. Put those rules in .editorconfig, turn on analyzers, and run dotnet format --verify-no-changes and the build in a build validation branch policy. Machines check the style, so people can focus on design, correctness and risk.

#Reviewing well

• Review the design first, then the details. A comment that the whole approach should change is more useful on day one than after 30 line-level comments.
• Ask questions instead of issuing verdicts: "What happens if this list is empty?" invites a better answer than "This is wrong."
• Label the weight of your comments, so the author knows what blocks approval and what's a suggestion.
• Respond quickly. A pull request waiting two days for review costs more than the review itself.

#Takeaway

Keep pull requests small and focused, explain why, what and how it was tested, and use a template so that's the default. Automate formatting and style checks, and spend review time on design and correctness.