maintainers-guide.md: reword some passages for improved clarity

contributing-guides/maintainers-guide.md

@@ -10,7 +10,9 @@ for the behavior expected of tldr-pages maintainers:
   **Be welcoming and friendly**, and if you don't know how to answer,
   ping other maintainers who you think might have a say.
 
-- **Every new discussion should receive a response within 3 days (ideally)**.
+- **Help keep the project responsive**.
+  New discussion threads (issues or pull requests)
+  should receive a response within 3 days, ideally.
   You can respond yourself
   or ask other members to provide their thoughts/opinions.
 
@@ -29,24 +31,26 @@ for the behavior expected of tldr-pages maintainers:
   (pull request, feature request, bug report, etc.)
   is a voluntary gift of time offered to the tldr project
   by someone who cares about it,
-  so make sure not to take it for granted.
+  so make sure it's clear that that we don't take it for granted.
 
 ## II. Handling PRs
 
-- When merging PRs, use the strategy that produces a **clean git history**:
-  Use squash if there's a single commit in the PR,
-  or if the multiple commits are not independent changes.
-  If the PR author took the time to craft individual,
-  informative commit messages for each commit,
-  use rebase to honor that work and preserve the history of the changes.
+- 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,
+  use the `Squash and merge` method.
+  If the PR author took the time to craft
+  individual, informative messages for each commit,
+  use the `Rebase and merge` method,
+  to honor that work and preserve the history of the changes.
+  For less clear-cut cases, a simple heuristic you can follow
+  is that if there are more "dirty" commits than "clean" commits,
+  then prefer squash, else do a rebase.
 
-  A simple heuristic to follow is that if there are more "dirty" commits
-  than "clean" commits, then prefer squash, else do a rebase.
-
-- Although push access allows committing directly to the repository,
+- Although having push access allows committing directly to the repository,
   please **create pull requests for all of your changes**,
   except the simplest ones (e.g. typo fixes).
-  This ensures that the entire process other contributors go through
-  is exposed to maintainers,
+  This ensures that the entire process that regular contributors go through
+  is also exposed to maintainers,
   who can then identify and address bottlenecks or inconveniences.
-  Similarly, **avoid merging your own PRs**.
+  Similarly, **avoid merging your own PRs** unless approved by other maintainers.