governance/maintainership guides: minor textual fixes

GOVERNANCE.md

@@ -29,9 +29,10 @@ with no central authority.
 
 - **All communications are public**.
   There are no permanent private channels where maintainers discuss "internal" matters.
-  Occasional private chat messages may be exchanged,
+  Occasional private chat or email messages may be exchanged,
   e.g. when setting up services that require passwords,
-  but otherwise all exchanges that impact the project either happen in issue or PR discussions,
+  but otherwise all communications that impact the project
+  will either happen in issue and PR discussions,
   or in the [Gitter chat room](https://gitter.im/tldr-pages/tldr)
   (which is open to all, and publicly logged).
 
@@ -88,7 +89,7 @@ the metrics used are simple, objective, and publicly available.
   and their name added to the list of former maintainers in the MAINTAINERS.md file.
   Again, this is and merely a reflection of their actual involvement with the project,
   not a demotion or punishment. In fact, if they return to active participation in the project,
-  they should be re-added back to the organization, to reflect that fact.
+  they should be added back to the organization, to reflect that fact.
 
     - This inactivity threshold additionally ensures
       that the list of organization members doesn't grow to unwieldy sizes,

contributing-guides/maintainers-guide.md

@@ -8,7 +8,7 @@ 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.
 
-- Although push access allows committing directly to master,
+- Although push access allows committing directly to the repository,
   plase **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
@@ -18,7 +18,7 @@ for the behavior expected of tldr-pages maintainers:
 - Ideally, **every new discussion should receive a response within 24 hours**.
   You can respond yourself or ask other members to provide their thoughts/opinions.
 
-- When mergin PRs, use the strategy that produces a **clean git history** in the repository:
+- When merging PRs, use the strategy that produces a **clean git history** in the repository:
   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 regular merge to honor that work and preserve the history of the changes.