[Markdown] Contributing: Add section about release branch PRs

In an effort to centralize the release branch PR form and release
process info in general, dedicate a section to this for repositories and
forum announcements to refer to instead of each publishing their own
copies.

Author: AnthonyLatsis

contributing/_contributing-code.md

@@ -111,6 +111,41 @@ 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
+
+A pull request targeting a release branch (`release/x.y`) cannot be merged
+without a GitHub approval by a corresponding branch manager.
+In order for a change to be considered for inclusion in a release branch, the
+pull request must have:
+
+* A title starting with a designation containing the release version number of
+  the target branch.
+
+* The following form filled out in its description:
+
+  ```
+  - **Explanation**: A description of the changes. This can be brief, but it
+    should be clear.
+  - **Scope**: An assessment of the impact and importance of the changes. For
+    example, can the changes break existing code?
+  - **Issues**: References to issues the changes resolve, if any.
+  - **Original PRs**: Links to mainline branch pull requests in which the
+    changes originated.
+  - **Risk**: The (specific) risk to the release for taking the changes.
+  - **Testing**: The specific testing that has been done or needs to be done to
+    further validate any impact of the changes.
+  - **Reviewers**: The code owners that GitHub-approved the original changes in
+    the mainline branch pull requests. If an original change has not been
+    GitHub-approved by a respective code owner, provide a reason. Technical
+    review can be delegated by a code owner or otherwise requested as deemed
+    appropriate or useful.
+  ```
+
+  An item that is not applicable may be left blank or completed with an
+  indication thereof, but must not be omitted altogether.
+
+[Here](https://github.com/apple/swift/pull/73697) is an example.
+
 ### Code Review
 
 The Swift project relies heavily on code review to improve software quality: