diff --git a/docs/community-governance.md b/docs/community-governance.md
index 1592dd3a56..da252a8e03 100644
--- a/docs/community-governance.md
+++ b/docs/community-governance.md
@@ -95,8 +95,15 @@ However, if there are no objections from maintainers, the PR can be merged with
 ### Commit messages
 
 Mergers are required to rewrite the PR title and the first comment (the summary) when necessary so the squash commit message is clear.
+Usually the Pull Request description and commit message body should not be empty, unless the title is already clear enough or the description would be a copy of the comments in code.
 
-The final commit message should not hedge: replace phrases like `hopefully, <x> won't happen anymore` with definite wording.
+The final commit message:
+
+- should match the code changes.
+- should only keep true co-authors, false-positive co-authors should be removed.
+- should not hedge: replace phrases like `hopefully, <x> won't happen anymore` with definite wording.
+- should not contain hidden information like `<!-- -->` or extra information after the description's divider `----`.
+- should not contain unrelated contents (e.g.: Release Notes, Configuration, etc.) from a Renovate update PR.
 
 #### PR Co-authors
 
@@ -158,9 +165,16 @@ Any account with write access (including bots and TOC members) **must** use [2FA
 Mergers are the maintainers who carry out the final merge of approved PRs. Their responsibilities, described throughout this guide, are:
 
 - Merging PRs from the [merge queue](#getting-prs-merged) in order, once a PR has `lgtm/done`, no open discussions, and no merge conflicts.
-- Rewriting the PR title and summary so the squash [commit message](#commit-messages) is clear, removing false-positive co-authors while keeping every true co-author.
+- Rewriting the PR title and description prior to the merge, making the [commit message](#commit-messages) clear.\
+  In particular, mergers should edit the PR description.\
+  Mergers should **not** edit the actual commit message except to remove unnecessary information. Because of that, even if users are looking at the PR, they can understand what changed.
 - Assigning the correct labels (including `type/…`) needed for changelog and backport decisions.
 - Agreeing, together with the owners, on when a release is ready (see [release management](release-management.md)).
+- Merging a PR also means the PR looks good to the merger and is approved by the merger.
+
+If a merger violates these merge guides more than 3 times in the past 365 days
+(e.g.: merge with unresolved reviews without TOC decision to ignore the review, merge with garbage commit messages),
+they may lose their merging privileges for at least three months.
 
 #### Becoming a merger
 
@@ -200,7 +214,7 @@ random.seed("Gitea TOC <YEAR> Election")
 random.choice([<CANDIDATE_1>, <CANDIDATE_2>, ...])
 ```
 
-The result of this script needs then to be published in the TOC election issue to ensure transparency of the process. 
+The result of this script needs then to be published in the TOC election issue to ensure transparency of the process.
 
 ### Current TOC members
 
@@ -213,7 +227,7 @@ The result of this script needs then to be published in the TOC election issue t
     - [bircni](https://gitea.com/bircni) <bircni@icloud.com>
     - [delvh](https://gitea.com/delvh) <dev.lh@web.de>
     - [TheFox0x7](https://gitea.com/TheFox0x7) <thefox0x7@gmail.com>
-    
+
 
 ### Previous TOC/owners members