fixup! Update backport, release and sync documentation

book/src/development/infrastructure/backport.md

@@ -19,19 +19,20 @@ some explanation and are quite subjective. Good judgement is required.
 1. **Is the fix worth a backport?**
 
    This is really subjective. An ICE fix usually is. Moving a lint to a _lower_
-   group usually as well. An FP fix usually not (on its own). If a backport is
-   done anyway, FP fixes might also be included. If the PR has a lot of changes,
-   backports must be considered more carefully.
+   group (from warn- to allow-by-default) usually as well. An FP fix usually not
+   (on its own). If a backport is done anyway, FP fixes might also be included.
+   If the PR has a lot of changes, backports must be considered more carefully.
 
 2. **Is the problem that was fixed by the PR already in `beta`?**
 
    It could be that the problem that was fixed by the PR hasn't made it to the
    `beta` branch of the Rust repo yet. If that's the case, and the fix is
-   already synced to the Rust repo, the fix doesn't need to be backported. If
-   the fix PR is not synced yet, the fix PR either needs to be "backported" to
-   the Rust `master` branch or to `beta` in the next backport cycle.
+   already synced to the Rust repo, the fix doesn't need to be backported, as it
+   will hit stable together with the commit that introduced the problem. If the
+   fix PR is not synced yet, the fix PR either needs to be "backported" to the
+   Rust `master` branch or to `beta` in the next backport cycle.
 
-3. **Is the fix already synced to `master`?**
+3. **Make sure that the fix is on `master` before porting to `beta`**
 
    The fix must already be synced to the Rust `master` branch. Otherwise, the
    next `beta` will be missing this fix again. If it is not yet in `master` it
@@ -67,9 +68,9 @@ git reset --hard upstream/beta
 
 ## Backport the changes
 
-When PR is merged with the GitHub merge queue, the PR is closed with the message
+When a PR is merged with the GitHub merge queue, the PR is closed with the message
 
-> <PR title> (#<PR number>)
+> \<PR title\> (#\<PR number\>)
 
 This commit needs to be backported. To do that, find the `<sha1>` of that commit
 and run the following command in the clone of the **Rust repository**:
@@ -95,7 +96,7 @@ Backports:
 - <Link to the Clippy PR>
 - ...
 
-<Short summary what is backported and why>
+<Short summary of what is backported and why>
 ```
 
 Mark is from the release team and they ultimately have to merge the PR before

book/src/development/infrastructure/release.md

@@ -48,7 +48,7 @@ git commit -m "Bump Clippy version -> 0.1.XY" **/*Cargo.toml
 
 ## Find the Clippy commit
 
-For both, updating the `beta` and the `stable` branch, the first step is to find
+For both updating the `beta` and the `stable` branch, the first step is to find
 the Clippy commit of the last Clippy sync done in the respective Rust branch.
 
 Running the following commands _in the Rust repo_ will get the commit for the
@@ -88,7 +88,7 @@ git push upstream stable
 After updating the `stable` branch, tag the HEAD commit and push it to the
 Clippy repo.
 
-> Note: Only push the tag, once the Deploy GitHub action of the `beta` branch is
+> Note: Only push the tag once the Deploy GitHub action of the `beta` branch is
 > finished. Otherwise the deploy for the tag might fail.
 
 ```bash