cleanup: update maintainers guide (#11862)

Co-authored-by: Lena <126529524+acuteenvy@users.noreply.github.com>

contributing-guides/maintainers-guide.md

@@ -60,6 +60,8 @@ for the behavior expected of tldr-pages maintainers.
   (2) have the **review comments addressed**,
   (3) get **approved reviews by two maintainers** (the second maintainer can merge immediately after approving).
 
+- It is suggested to wait for a few hours before merging a pull request with new additions to English pages. This is to allow other maintainers to review the changes and provide feedback.
+
 - If a PR fails to get a review from a second maintainer after a few days,
   the first maintainer should ping others for review. If it still lingers around
   for **over a week without a second maintainer’s approval**,
@@ -80,6 +82,8 @@ for the behavior expected of tldr-pages maintainers.
   Be mindful of signs of fatigue (less enthusiastic responses, slower reactions),
   and relax review standards if necessary — minor issues can always be fixed later.
 
+- For pull requests with major/breaking/architectural changes that are **not ready to be merged**, it is suggested to label them with the `decision` label and discuss the changes with the other maintainers in the chatroom.
+
 - When merging PRs, use the **merge strategy that produces a clean Git history**:
   If there's a single commit in the PR,
   or if the multiple commits are not semantically independent changes,
@@ -93,7 +97,28 @@ for the behavior expected of tldr-pages maintainers.
   is that if there are more "dirty" commits than "clean" commits,
   then prefer squash, else do a rebase.
 
-- Although having push access allows committing directly to the repository to all branches (except main),
+- It is suggested to clean up the commit message when merging a PR. For small commits, use:
+
+  ```
+  page-name: a short description of the change
+
+  Co-authored-by: ...
+  ```
+  if you think a more descriptive message is needed, use asterisks:
+  ```
+  page-name: a short description of the change
+
+  * some more information
+  * ...
+
+  ---------
+
+  Co-authored-by: ...
+  ```
+
+- It is suggested to preserve the `Co-authored-by` message when cleaning the body of a squashed commit message unless the change done was trivial.
+
+- Although having push access allows committing directly to the repository to all branches (except the main branch),
   please **create pull requests for all of your changes**.
   This ensures that the entire process that regular contributors go through
   is also exposed to maintainers,
@@ -101,7 +126,7 @@ for the behavior expected of tldr-pages maintainers.
   Similarly, **avoid merging your own PRs** unless approved by other maintainers.
 
 - At the last week of October, all applicable PRs that wouldn't get merged
- in time can be labeled as `hacktoberfest-accepted`.
+ in time can be labelled as `hacktoberfest-accepted`.
 
 ## III. Transparency
 
@@ -109,3 +134,10 @@ for the behavior expected of tldr-pages maintainers.
  should be documented as an issue with the [archive](https://github.com/tldr-pages/tldr/issues?q=label%3Aarchive) label
   and must be communicated with other maintainers.
 - All repository/organization settings changes must be documented as an issue with the [archive](https://github.com/tldr-pages/tldr/issues?q=label%3Aarchive) label.
+
+## IV. Handling failing actions and CLA checks
+
+- While merging multiple pull requests at the same time there is a chance that the deploy step might fail in the GitHub Actions workflow. In such cases, the maintainer should only **re-run** the workflow of the commit which was last merged (to prevent overwriting of assets by previous commits).
+- If the CLA check is frozen at the message "Status waiting to be reported", it is recommended to close and reopen the pull requests to retrigger the check (and notify the contributor about the same).
+
+For reference to see if a contributor has signed the CLA, visit the dashboard at <https://cla-assistant.io/>.