[Markdown] Contributing: Add section about release branch PRs

In an effort to centralize the release branch PR form in particular and
nomination process in general, dedicate a section to this for
repositories and forums announcements to refer to instead of each
publishing their own — sometimes slightly different, without good reason
— versions.

contributing/_contributing-code.md

@@ -111,6 +111,57 @@ For C or C++ source or header files, the code header should look this:
 
 The divider lines should be exactly 80 characters wide to aid in adherence to the code style guidelines.  The bottom section contains an optional description intended for generated documentation (these lines begin with `///` rather than `//`).  If there is no description, this area can be skipped.
 
+### Release Branch Pull Requests
+
+*All changes* to a release branch (`release/x.y`) must be proposed through pull
+requests.
+A pull request targeting a release branch cannot be merged without an approval
+by the corresponding release manager.
+In order for a change to be considered for inclusion in a release branch, the
+pull request must have:
+
+* A title that starts with a `[x.y]` tag matching the release version of the
+  target branch
+
+* The following form filled out in its description:
+
+  ```
+  * **Explanation**
+
+    A description of the change. This can be brief, but it should be clear.
+
+  * **Scope**
+
+    An assessment of the impact and importance of the change.
+    For example, is the change a source-breaking language change?
+
+  * **Issues**
+
+    References to issues the change resolves, if any.
+
+  * **Original PR**
+
+    Link to the mainline branch version of this pull request, if any.
+
+  * **Risk**
+
+    What is the (specific) risk to the release for taking this change?
+
+  * **Testing**
+
+    What specific testing has been done or needs to be done to further validate
+    any impact of this change?
+
+  * **Reviewers**
+
+    The code owners that approved the mainline branch pull request, if there is
+    one.
+    One or more code owners of the impacted components should approve the 
+    change.
+    Technical review can be delegated by a code owner or otherwise requested as
+    deemed appropriate or useful.
+  ```
+
 ### Code Review
 
 The Swift project relies heavily on code review to improve software quality: