Merge rust-bitcoin/rust-bitcoin#2685: Add backport section to contributing docs

b49e670772 Add backport section to contributing docs (Tobin C. Harding)

Pull request description:

  Add a section on how we do backports and what the merge policy is.

  Recently I backported a patch by pushing directly to the `0.32.x` release branch but this is not an optimal process because it leaves no history on github. Instead PR backports in like we do for patching `master` but allow one-ACK merging if the backport is a straight cherry pick of a patch from `master`.

ACKs for top commit:
  apoelstra:
    ACK b49e670772 looks much better!
  storopoli:
    ACK b49e670772
  sanket1729:
    ACK b49e670772

Tree-SHA512: f114cc015cd0c314567dc337c77ba9b021132f5bbd503f58fcac1c86acab3aae89d179af67cde89f2ac48d7391f7cc7fc23b4f7cfa63ad2b89d335a36cbe131b

CONTRIBUTING.md

@@ -182,6 +182,19 @@ any of the following conditions:
 [1] - The aim is to reduce the burden of re-ACK'ing trivial changes and also
       alleviate the problem of devs spread around the world in different timezones.
 
+#### Backporting
+
+We maintain release branches (e.g. `0.32.x` for the `v0.32` releases).
+
+In order to backport changes to these branches the process we use is as follows:
+
+- PR change into `master`.
+- Mark the PR with the appropriate labels if backporting is needed (e.g. `port-0.32.x`).
+- Once PR merges create another PR that targets the appropriate branch.
+- If, and only if, the backport PR is identical to the original PR (i.e. created using
+  `git cherry-pick`) then the PR may be one-ACK merged.
+
+Any other changes to the release branches should follow the normal 2-ACK merge policy.
 
 ## Coding conventions