diff --git a/docs/devel/pr_workflow.dia b/docs/devel/pr_workflow.dia
new file mode 100644
index 00000000000..d520c21ddee
Binary files /dev/null and b/docs/devel/pr_workflow.dia differ
diff --git a/docs/devel/pr_workflow.png b/docs/devel/pr_workflow.png
new file mode 100644
index 00000000000..dc95a366253
Binary files /dev/null and b/docs/devel/pr_workflow.png differ
diff --git a/docs/devel/pull-requests.md b/docs/devel/pull-requests.md
index eaffce237d6..b0fb7385461 100644
--- a/docs/devel/pull-requests.md
+++ b/docs/devel/pull-requests.md
@@ -34,8 +34,7 @@ Documentation for other releases can be found at
 Pull Request Process
 ====================
 
-An overview of how we will manage old or out-of-date pull requests.
-
+An overview of how we will manage old or out-of-date pull requests.k
 Process
 -------
 
@@ -51,6 +50,10 @@ We want to limit the total number of PRs in flight to:
 Life of a Pull Request
 ----------------------
 
+### Visual overview
+
+![PR workflow](pr_workflow.png)
+
 Unless in the last few weeks of a milestone when we need to reduce churn and stabilize, we aim to be always accepting pull requests.
 
 Either the [on call](https://github.com/kubernetes/kubernetes/wiki/Kubernetes-on-call-rotations) manually or the [github "munger"](https://github.com/kubernetes/contrib/tree/master/mungegithub) submit-queue plugin automatically will manage merging PRs.