diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 384893be1c..e82c119dfa 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -7,6 +7,55 @@ Here are some guidelines for contributing back to this
 project. There is also a link:MyFirstContribution.html[step-by-step tutorial]
 available which covers many of these same guidelines.
 
+[[patch-flow]]
+=== An ideal patch flow
+
+Here is an ideal patch flow for this project the current maintainer
+suggests to the contributors:
+
+. You come up with an itch.  You code it up.
+
+. Send it to the list and cc people who may need to know about
+  the change.
++
+The people who may need to know are the ones whose code you
+are butchering.  These people happen to be the ones who are
+most likely to be knowledgeable enough to help you, but
+they have no obligation to help you (i.e. you ask for help,
+don't demand).  +git log -p {litdd} _$area_you_are_modifying_+ would
+help you find out who they are.
+
+. You get comments and suggestions for improvements.  You may
+  even get them in an "on top of your change" patch form.
+
+. Polish, refine, and re-send to the list and the people who
+  spend their time to improve your patch.  Go back to step (2).
+
+. The list forms consensus that the last round of your patch is
+  good.  Send it to the maintainer and cc the list.
+
+. A topic branch is created with the patch and is merged to `next`,
+  and cooked further and eventually graduates to `master`.
+
+In any time between the (2)-(3) cycle, the maintainer may pick it up
+from the list and queue it to `seen`, in order to make it easier for
+people to play with it without having to pick up and apply the patch to
+their trees themselves.
+
+[[patch-status]]
+=== Know the status of your patch after submission
+
+* You can use Git itself to find out when your patch is merged in
+  master. `git pull --rebase` will automatically skip already-applied
+  patches, and will let you know. This works only if you rebase on top
+  of the branch in which your patch has been merged (i.e. it will not
+  tell you if your patch is merged in `seen` if you rebase on top of
+  master).
+
+* Read the Git mailing list, the maintainer regularly posts messages
+  entitled "What's cooking in git.git" giving
+  the status of various proposed changes.
+
 [[choose-starting-point]]
 === Choose a starting point.
 
@@ -562,55 +611,6 @@ repositories.
 
 Patches to these parts should be based on their trees.
 
-[[patch-flow]]
-== An ideal patch flow
-
-Here is an ideal patch flow for this project the current maintainer
-suggests to the contributors:
-
-. You come up with an itch.  You code it up.
-
-. Send it to the list and cc people who may need to know about
-  the change.
-+
-The people who may need to know are the ones whose code you
-are butchering.  These people happen to be the ones who are
-most likely to be knowledgeable enough to help you, but
-they have no obligation to help you (i.e. you ask for help,
-don't demand).  +git log -p {litdd} _$area_you_are_modifying_+ would
-help you find out who they are.
-
-. You get comments and suggestions for improvements.  You may
-  even get them in an "on top of your change" patch form.
-
-. Polish, refine, and re-send to the list and the people who
-  spend their time to improve your patch.  Go back to step (2).
-
-. The list forms consensus that the last round of your patch is
-  good.  Send it to the maintainer and cc the list.
-
-. A topic branch is created with the patch and is merged to `next`,
-  and cooked further and eventually graduates to `master`.
-
-In any time between the (2)-(3) cycle, the maintainer may pick it up
-from the list and queue it to `seen`, in order to make it easier for
-people to play with it without having to pick up and apply the patch to
-their trees themselves.
-
-[[patch-status]]
-== Know the status of your patch after submission
-
-* You can use Git itself to find out when your patch is merged in
-  master. `git pull --rebase` will automatically skip already-applied
-  patches, and will let you know. This works only if you rebase on top
-  of the branch in which your patch has been merged (i.e. it will not
-  tell you if your patch is merged in `seen` if you rebase on top of
-  master).
-
-* Read the Git mailing list, the maintainer regularly posts messages
-  entitled "What's cooking in git.git" giving
-  the status of various proposed changes.
-
 == GitHub CI[[GHCI]]
 
 With an account at GitHub, you can use GitHub CI to test your changes