diff --git a/docs/devel/development.md b/docs/devel/development.md
index 050419e243e..1349e0037c7 100644
--- a/docs/devel/development.md
+++ b/docs/devel/development.md
@@ -194,6 +194,23 @@ git push -f origin my-feature
 
 **Note:** If you have write access, please refrain from using the GitHub UI for creating PRs, because GitHub will create the PR branch inside the main repository rather than inside your fork.
 
+### Getting a code review
+
+Once your pull request has been opened it will be assigned to one or more
+reviewers.  Those reviewers will do a thorough code review, looking for
+correctness, bugs, opportunities for improvement, documentation and comments,
+and style.
+
+Very small PRs are easy to review.  Very large PRs are very difficult to
+review.  Github has a built-in code review tool, which is what most people use.
+At the assigned reviewer's discretion, a PR may be switched to use
+[Reviewable](https://reviewable.k8s.io) instead.  Once a PR is switched to
+Reviewable, please ONLY send or reply to comments through reviewable.  Mixing
+code review tools can be very confusing.
+
+See [Faster Reviews](faster_reviews.md) for some thoughts on how to streamline
+the review process.
+
 ### When to retain commits and when to squash
 
 Upon merge, all git commits should represent meaningful milestones or units of
@@ -206,9 +223,6 @@ fixups (e.g. automated doc formatting), use one or more commits for the
 changes to tooling and a final commit to apply the fixup en masse. This makes
 reviews much easier.
 
-See [Faster Reviews](faster_reviews.md) for more details.
-
-
 ## Testing
 
 Three basic commands let you run unit, integration and/or e2e tests: