Suggest that maintainers make small fixes directly before merging

If a merge request is done, but has a trivial change needed (for
instance, a typo fix), then it's much more efficient if the maintainer
does that directly using the suggest changes feature:

1. It prevents another back and forth, especially where the maintainer
   and author are in different time zones.
2. It saves a pipeline run if the maintainer doesn't see the new MR
   within two hours of the new pipeline running.

doc/development/code_review.md

@@ -327,6 +327,23 @@ Before taking the decision to merge:
   before merging. A comment must to be posted if the MR is merged with any failed job.
 - If the MR contains both Quality and non-Quality-related changes, the MR should be merged by the relevant maintainer for user-facing changes (backend, frontend, or database) after the Quality related changes are approved by a Software Engineer in Test.
 
+If a merge request is fundamentally ready, but needs only trivial fixes (such as
+typos), consider demonstrating a [bias for
+action](https://about.gitlab.com/handbook/values/#bias-for-action) by making
+those changes directly without going back to the author. You can do this by
+using the [suggest changes](../user/discussions/index.md#suggest-changes) feature to apply
+your own suggestions to the merge request. Note that:
+
+- If the changes are not straightforward, please prefer assigning the merge request back
+  to the author.
+- **Before applying suggestions**, edit the merge request to make sure
+  [squash and
+  merge](../user/project/merge_requests/squash_and_merge.md#squash-and-merge)
+  is enabled, otherwise, the pipeline's Danger job will fail.
+  - If a merge request does not have squash and merge enabled, and it
+    has more than one commit, then see the note below about rewriting
+    commit history.
+
 When ready to merge:
 
 - Consider using the [Squash and