docs: tidy up noise reduction essay (#7823)

docs/usage/noise-reduction.md

@@ -8,13 +8,13 @@ description: How to reduce the "noise" associated with module updates
 Generally, the first reaction people have to automated dependency updates like Renovate is "oh great/feel the power of automation".
 The next reaction a few days or weeks later is often "this is getting overwhelming".
 Indeed, if you leave Renovate on its default settings of raising a PR every single time any dependency receives any update.. you will get a lot of PRs and related notifications.
-This document will give you some ideas of how to reduce the amount of "noise" in your repository and the Pros/Cons of each.
+This document will give you some ideas of how to reduce the amount of "noise" in your repository and the Pros/Cons of each approach.
 
 Of course, please keep in mind that people's definitions of "noise" may differ.
 For some people, it's noisy only if they get a notification or email from GitHub.
 For others, too many commits in their `master` branch may be "noise".
 In other words, your mileage may vary.
-Please contact the author if you have any ideas on this topic!
+If you have any ideas on this topic, please contact the author by opening an [issue on the Renovate repository](https://github.com/renovatebot/renovate/issues).
 
 ## Package Grouping
 
@@ -25,7 +25,7 @@ For example, all `@angular/*` packages that are updated at the same time will be
 And every package in the React monorepo will be grouped together in a React monorepo PR too.
 
 You may wish to take this further, for example you might want to group together all packages related to `eslint`, even if they come from separate repositories/authors.
-In that case you might add config like this:
+In that case you might create a config like this:
 
 ```json
   "packageRules": [
@@ -47,9 +47,9 @@ You will also have less flexibility about what to do when one or more in the gro
 ## Scheduling Renovate
 
 On its own, the Renovate CLI tool runs once and then exits.
-Hence it only runs as often as its administrator sets it to (e.g. via `cron`).
+Hence, it only runs as often as its administrator sets it to (e.g. via `cron`).
 For the [Renovate app on GitHub](https://github.com/apps/renovate), it currently runs continuously using a job queue that gets refreshed hourly, or when you make relevant commits to your repository.
-Therefore, you can expect to get PRs at any time of the day, i.e. soon after versions are published to npm.
+Therefore, you can expect to get PRs at any time of the day, e.g. soon after versions are published to npm.
 
 Receiving PRs at any hour can increase the feeling of being "overwhelmed" by updates and possibly interrupt your flow during working hours, so many Renovate users also consider reducing Renovate's schedule to be outside their normal working hours, for example weeknights and weekends.
 This is achievable by configuring `schedule` in your Renovate config and optionally `timezone` (Renovate's default time zone is UTC, so you may find it easier to write schedules if you override `timezone` to your local one).
@@ -61,18 +61,19 @@ In that case, you might schedule Renovate to run every Tuesday after midnight to
 There are multiple reasons why Renovate may need to "recreate" PRs after you merge another:
 
 1. Conflict with `package.json` (sometimes)
-2.  Conflict with lock files (often)
-3.  If you have configure Renovate or GitHub that PRs must always be kept up-to-date with master
+1. Conflict with lock files (often)
+1. If you have configured Renovate or GitHub that PRs must always be kept up-to-date with master
 
 Any of the above reasons can lead to a Renovate branch being considered "stale" and then Renovate needs to rebase it off `master` before you can test and merge again, and Renovate won't do this until it's back in schedule.
 
 #### Selective scheduling
 
 Don't think that you need to apply blanket rules to scheduling.
-Remember that Renovate configuration is highly flexible so you can configure `automerge` anywhere from globally (entire repo) right down to a package/upgrade type level (e.g. you could even configure a nonsensical rule that patch updates of `jquery` are for Mondays only).
+Remember that Renovate's configuration is highly flexible so you can configure `automerge` anywhere from globally (entire repo) right down to a package/upgrade type level.
+You could even configure a nonsensical rule like: "patch updates of `jquery` are for Mondays only".
 
-Remember earlier our example of grouping all `eslint`?
-If you think about it.. updates to `eslint` rules don't exactly need to be applied in real time!
+Remember our example of grouping all `eslint` packages?
+If you think about it, updates to `eslint` rules don't exactly need to be applied in real time!
 You don't want to get too far behind, so how about we update `eslint` packages only once a month?
 
 ```json
@@ -105,15 +106,15 @@ If you're wondering what is supported and not, under the hood, the schedule is p
 Automerging is a Renovate feature that can save you a lot of time/noise directly, while also benefiting grouping and scheduling.
 In short: it means that Renovate can merge PRs or even branches itself if they pass your tests.
 
-It is recommended that you enable automerge for any types of dependency updates where you would just click Merge anyway.
+We recommend that you enable automerge for any type of dependency update where you would just click Merge anyway.
 We all know that there are some types of updates that we (nearly) always verify manually before merging, and plenty of others that we don't bother looking at unless tests fail.
 Every time you click Merge on a Renovate PR without manually testing it, you should consider if you can enable automerge and save yourself the time in future.
 
 Automerge works particularly well for `devDependencies` and for production `dependencies` that have great test coverage.
 
-For example, if you have `jest` or `mocha` as a dependency, and it has an upgrade with passing tests.. automerge them!
-If you have a linter like `eslint` or `tslint` and its update passes.. automerge them!
-If you have an API with 100% test coverage and `express` is updated.. automerge it!
+For example, if you have `jest` or `mocha` as a dependency, and it has an upgrade with passing tests: automerge them!
+If you have a linter like `eslint` or `tslint` and its update passes: automerge them!
+If you have an API with 100% test coverage and `express` is updated: automerge it!
 
 #### Branch automerging
 
@@ -140,7 +141,8 @@ And this is especially so if your repository needs rebasing, e.g. because you us
 
 This is a lot better than you waking up to two PRs and then having to deal with conflicts yourself after you merge the first one.
 
-Remember our running `eslint` example? Let's automerge it if all the linting updates pass:
+Remember our running `eslint` example?
+Let's automerge it if all the linting updates pass:
 
 ```json
   "packageRules": [
@@ -173,8 +175,8 @@ The table below highlights different noise reduction strategies and their effect
 First of all, if you ever have any ideas about how to make Renovate less noisy, please raise or comment on issues in the [main repository](https://github.com/renovatebot/renovate).
 Our philosophy is:
 
-1.  Nearly everyone should probably use Renovate-like dependency update automation
-2.  Over time, you should "see" Renovate less and less
+1. Nearly everyone should use Renovate-like dependency update automation
+1. Over time, you should "see" Renovate less and less
 
 One of our hopes with preset configs is that a set of "sensible" configs can be maintained by the community that combine grouping, scheduling and automerging to reduce the amount of noise in repositories with little downside or increased risk.
 Such lists could be maintained and used somewhat like Adblock lists - kept up to date by maintainers but for the majority of users they are simply trusted/automatic/invisible.