From 5f21c63ba530632ebd7917c715c7142591383c92 Mon Sep 17 00:00:00 2001
From: HonkingGoose <34918129+HonkingGoose@users.noreply.github.com>
Date: Thu, 2 Jun 2022 16:58:52 +0200
Subject: [PATCH] docs: replace word therefore, plus other small changes
 (#15694)

---
 docs/usage/configuration-options.md           | 20 ++++++++++---------
 docs/usage/configuration-templates.md         |  2 +-
 docs/usage/dependency-pinning.md              | 11 +++++-----
 docs/usage/faq.md                             |  2 +-
 .../usage/getting-started/private-packages.md |  4 ++--
 docs/usage/getting-started/running.md         |  2 +-
 docs/usage/getting-started/use-cases.md       |  2 +-
 docs/usage/key-concepts/automerge.md          |  4 ++--
 docs/usage/known-limitations.md               |  6 +++---
 docs/usage/noise-reduction.md                 |  3 ++-
 docs/usage/self-hosted-configuration.md       |  2 +-
 docs/usage/updating-rebasing.md               |  2 +-
 lib/modules/datasource/docker/readme.md       |  2 +-
 lib/modules/manager/gomod/readme.md           |  2 +-
 lib/modules/manager/pip-compile/readme.md     |  3 +--
 lib/modules/manager/pre-commit/readme.md      |  2 +-
 16 files changed, 36 insertions(+), 33 deletions(-)

diff --git a/docs/usage/configuration-options.md b/docs/usage/configuration-options.md
index 8bea417833..f0e0314b8d 100644
--- a/docs/usage/configuration-options.md
+++ b/docs/usage/configuration-options.md
@@ -133,7 +133,8 @@ If configured, Renovate will take a random sample of given size from assignees a
 ## automerge
 
 By default, Renovate raises PRs but leaves them to someone or something else to merge them.
-By configuring this setting, you can enable Renovate to automerge PRs or even branches itself, therefore reducing the amount of human intervention required.
+By configuring this setting, you allow Renovate to automerge PRs or even branches.
+Using automerge reduces the amount of human intervention required.
 
 Usually you won't want to automerge _all_ PRs, for example most people would want to leave major dependency updates to a human to review first.
 You could configure Renovate to automerge all but major this way:
@@ -510,8 +511,9 @@ Examples of what having a Dependency Dashboard will allow you to do:
 
 <!-- prettier-ignore -->
 !!! tip
-    Enabling the Dependency Dashboard does not itself change any of the "control flow" of Renovate, e.g. it will otherwise still create and manage PRs exactly as it always has, including scheduling and rate limiting.
-    The Dependency Dashboard therefore provides visibility as well as additional control.
+    Just enabling the Dependency Dashboard doesn't change the "control flow" of Renovate.
+    Renovate still creates and manages PRs, and still follows your schedules and rate limits.
+    The Dependency Dashboard gives you extra visibility and control over your updates.
 
 ## dependencyDashboardApproval
 
@@ -621,7 +623,7 @@ This option is evaluated at PR/MR creation time and is only supported on the fol
 <!-- prettier-ignore -->
 !!! note
     GitLab implements draft status by checking whether the PR's title starts with certain strings.
-    Therefore, `draftPR` on GitLab is incompatible with the legacy method of triggering Renovate to rebase a PR by renaming the PR to start with `rebase!`.
+    This means that `draftPR` on GitLab is incompatible with the legacy method of triggering Renovate to rebase a PR by renaming the PR to start with `rebase!`.
 
 ## enabled
 
@@ -1361,7 +1363,7 @@ This option exists to provide flexibility about whether `npmrc` strings in confi
 In some situations you need the ability to force override `.npmrc` contents in a repo (`npmrcMerge=false`) while in others you might want to simply supplement the settings already in the `.npmrc` (`npmrcMerge=true`).
 A use case for the latter is if you are a Renovate bot admin and wish to provide a default token for `npmjs.org` without removing any other `.npmrc` settings which individual repositories have configured (such as scopes/registries).
 
-If `false` (default), it means that defining `config.npmrc` will result in any `.npmrc` file in the repo being overridden and therefore its values ignored.
+If `false` (default), it means that defining `config.npmrc` will result in any `.npmrc` file in the repo being overridden and its values ignored.
 If configured to `true`, it means that any `.npmrc` file in the repo will have `config.npmrc` prepended to it before running `npm`.
 
 ## packageRules
@@ -1446,7 +1448,7 @@ For example you have multiple `package.json` and want to use `dependencyDashboar
 ```
 
 Important to know: Renovate will evaluate all `packageRules` and not stop once it gets a first match.
-Therefore, you should order your `packageRules` in order of importance so that later rules can override settings from earlier rules if necessary.
+You should order your `packageRules` in order of importance so that later rules can override settings from earlier rules if needed.
 
 ### allowedVersions
 
@@ -2067,7 +2069,7 @@ This limit is enforced on a per-repository basis.
 
 If you configure `prCreation=not-pending`, then Renovate will wait until tests are non-pending (all pass or at least one fails) before creating PRs.
 However there are cases where PRs may remain in pending state forever, e.g. absence of tests or status checks that are configure to pending indefinitely.
-Therefore we configure an upper limit for how long we wait until creating a PR.
+This is why we configured an upper limit for how long we wait until creating a PR.
 
 <!-- prettier-ignore -->
 !!! note
@@ -2078,7 +2080,7 @@ Therefore we configure an upper limit for how long we wait until creating a PR.
 Sometimes Renovate needs to rate limit its creation of PRs, e.g. hourly or concurrent PR limits.
 In such cases it sorts/prioritizes by default based on the update type (e.g. patches raised before minor, minor before major).
 If you have dependencies that are more or less important than others then you can use the `prPriority` field for PR sorting.
-The default value is 0, so therefore setting a negative value will make dependencies sort last, while higher values sort first.
+The default value is 0, so setting a negative value will make dependencies sort last, while higher values sort first.
 
 Here's an example of how you would define PR priority so that devDependencies are raised last and `react` is raised first:
 
@@ -2136,7 +2138,7 @@ Renovate's `"auto"` strategy works like this for npm:
 5. Otherwise, replace the range. e.g. `"^2.0.0"` would be replaced by `"^3.0.0"`
 
 By default, Renovate assumes that if you are using ranges then it's because you want them to be wide/open.
-Therefore, Renovate won't deliberately "narrow" any range by increasing the semver value inside.
+Renovate won't deliberately "narrow" any range by increasing the semver value inside.
 
 For example, if your `package.json` specifies a value for `left-pad` of `^1.0.0` and the latest version on npmjs is `1.2.0`, then Renovate won't change anything because `1.2.0` satisfies the range.
 If instead you'd prefer to be updated to `^1.2.0` in cases like this, then configure `rangeStrategy` to `bump` in your Renovate config.
diff --git a/docs/usage/configuration-templates.md b/docs/usage/configuration-templates.md
index 0ea09b8b55..512f8c0438 100644
--- a/docs/usage/configuration-templates.md
+++ b/docs/usage/configuration-templates.md
@@ -30,7 +30,7 @@ Be careful, and consider creating a new "config help" post at the [discussions t
 ## Commit Message
 
 Renovate will use one commit per branch, this makes it easy for you to merge.
-Therefore, the `commitMessage` reflects the contents of the branch and is usually the same as the PR title.
+The `commitMessage` reflects the contents of the branch and is usually the same as the PR title.
 
 `commitMessage` has a default value of `{{commitMessagePrefix}} {{commitMessageAction}} {{commitMessageTopic}} {{commitMessageExtra}} {{commitMessageSuffix}}`, with the intention that you only edit some of those subcomponents.
 
diff --git a/docs/usage/dependency-pinning.md b/docs/usage/dependency-pinning.md
index b4c3dda3ca..f0bb261f8e 100644
--- a/docs/usage/dependency-pinning.md
+++ b/docs/usage/dependency-pinning.md
@@ -17,7 +17,7 @@ To ensure we're all talking about the same thing, it's important to define exact
 Historically, projects use SemVer ranges in their `package.json`.
 For instance, if you run `npm install foobar` you will see an entry like `"foobar": "^1.1.0"` added to your `package.json`.
 Verbosely, this means "any foobar version greater than or equal to 1.1.0 but less than 2".
-Therefore the project will automatically use 1.1.1 if it's released, or 1.2.0, or 1.2.1, etc - meaning you will get not only patch updates but also feature (minor) releases too.
+The project will automatically use `1.1.1` if it's released, or `1.2.0`, or `1.2.1`, etc - meaning you will get not only patch updates but also feature (minor) releases too.
 
 Another alternative is ranges like `"foobar": "~1.1.0"` which means "any foobar version greater than or equal to 1.1.0 but less than 1.2".
 This narrows the range to only patch updates to the 1.1 range.
@@ -67,7 +67,7 @@ You would need to manually check and work out which dependency caused the failur
 Consider the same situation if instead you were _pinning_ dependency versions.
 Your `main` branch would not be broken because it's pinned to `foobar@1.1.0` - instead you'd just have a Pull Request for upgrading to `foobar@1.2.0` which would fail.
 You'd know not to merge it and can wait for `foobar@1.2.1` or later when it's fixed.
-Therefore you know exactly what you're running and you know exactly what failed - you have great "visibility".
+By pinning dependencies you know exactly what you're running and you know exactly what failed.
 
 Now consider a similar theoretical scenario where `foobar@1.2.0` is faulty but it is _not_ caught by any of your automated tests.
 This is more common and more dangerous.
@@ -100,8 +100,9 @@ To some extent this is simply a trade-off for having your dependencies pinned an
 
 There are some dependencies that either (a) don't have the potential to break something in production, or (b) are fully tested by your tests.
 
-For example, it's very hard for `eslint` to break anything in production. If your build/tests pass, then you are fine.
-Therefore you should consider enabling automerge for all lint packages to save yourself the pointless click when you manually approve them each time.
+For example, it's very hard for `eslint` to break anything in production.
+If your build/tests pass, then you are fine.
+Consider enabling automerge for all lint packages to save yourself the pointless click when you manually approve them each time.
 In this case you might wake up to 5/10 of your overnight Pull Requests having already merged themselves.
 
 Another example of a good candidate for automerging might be a database driver like `node-postgres` (`pg` on npm), if you have 100% test coverage of your API.
@@ -182,7 +183,7 @@ The (broken) upgrade to `1.2.0` would have been explicitly proposed to you via a
 Meanwhile you could be upgrading all the other essential fixes of other dependencies without worrying about `foobar`.
 You could even be running `yarn upgrade` regularly to be getting _indirect_ package updates in the lockfile and seeing if everything still passes.
 
-Therefore, the lock file does not solve the same SemVer problems that pinning solves - but it compliments it.
+So the lock file does not solve the same SemVer problems that pinning solves - but it compliments it.
 For this reason our usual recommendation using a lock file regardless of whether you pin dependencies or not, and pinning even if you have a lock file.
 
 Don't forget though that our motto is "Flexible, so you don't need to be", so go ahead and configure however you want.
diff --git a/docs/usage/faq.md b/docs/usage/faq.md
index f59332e7a5..4ba3e7d5f3 100644
--- a/docs/usage/faq.md
+++ b/docs/usage/faq.md
@@ -51,7 +51,7 @@ The default branch name that Git uses is `master` (this will be changed to `main
 The Git-hosting ecosystem has settled on using `main` to replace `master`.
 When you create a new repository on say GitHub or GitLab, you'll get a `main` branch as your base branch.
 
-It therefore makes sense for Renovate to replace `master` with `main` where possible as well.
+We've replaced `master` with `main` in our documentation where possible.
 
 A branch name has no special meaning within the Git program, it's just a name.
 The base branch could be called `trunk` or `mainline` or `prod`, and Git would work just as well.
diff --git a/docs/usage/getting-started/private-packages.md b/docs/usage/getting-started/private-packages.md
index 46586c41ba..37afd34d9d 100644
--- a/docs/usage/getting-started/private-packages.md
+++ b/docs/usage/getting-started/private-packages.md
@@ -371,8 +371,8 @@ The solution to this is that you should break your presets into public and priva
 
 ### Encrypting secrets
 
-It is strongly recommended that you don't commit secrets to repositories, including private ones, and this includes secrets needed by Renovate to access private modules.
-Therefore the preferred approach to secrets is that the bot administrator configures them as `hostRules` which are then applied to all repositories which the bot accesses.
+It is strongly recommended that you avoid committing secrets to repositories, including private ones, and this includes secrets needed by Renovate to access private modules.
+The preferred approach to secrets is that the bot administrator configures them as `hostRules` which are then applied to all repositories which the bot accesses.
 
 If you need to provide credentials to the hosted Renovate App, please do this:
 
diff --git a/docs/usage/getting-started/running.md b/docs/usage/getting-started/running.md
index c657014ffd..ddded8a81a 100644
--- a/docs/usage/getting-started/running.md
+++ b/docs/usage/getting-started/running.md
@@ -23,7 +23,7 @@ Self-hosting Renovate means that you are the "administrator" of the bot, which e
 Renovate's Open Source CLI is built and distributed as the npm package `renovate`.
 You can run this directly in any Node.js environment - even via `npx` - and it will process all the repositories it is configured with, before exiting.
 When you install Renovate from npm it naturally does not come bundled with any third-party tools or languages such as Ruby, Python, Composer, Bundler, Poetry, etc.
-Therefore if you need Renovate to support any non-npm lock files like Bundler then you'll need to make sure all required third-party tools are pre-installed in the same environment alongside Renovate before you run it.
+If you need Renovate to support any non-npm lock files like Bundler then you'll need to make sure all required third-party tools are pre-installed in the same environment alongside Renovate before you run it.
 
 The `renovate` npm package is compatible with all of Renovate's supported platforms.
 
diff --git a/docs/usage/getting-started/use-cases.md b/docs/usage/getting-started/use-cases.md
index 8a2e17d7ff..75379e12d6 100644
--- a/docs/usage/getting-started/use-cases.md
+++ b/docs/usage/getting-started/use-cases.md
@@ -39,7 +39,7 @@ npm, Yarn, Bundler, Composer, Poetry, Pipenv, and Cargo all support or use lock
 
 If you use a lock file then changes to your package file must come with a compatible change to the lock file.
 Renovate can patch/update package files directly, but a lock file is too complex to "reverse engineer".
-Therefore Renovate lets the package manager do the lock file update.
+This is why Renovate lets the package manager do the lock file update.
 A simplified example:
 
 1. The repository has a `package.json` and `package-lock.json` with version `1.0.0` of a dependency
diff --git a/docs/usage/key-concepts/automerge.md b/docs/usage/key-concepts/automerge.md
index 71b8a77982..22160cd4fe 100644
--- a/docs/usage/key-concepts/automerge.md
+++ b/docs/usage/key-concepts/automerge.md
@@ -15,7 +15,7 @@ If you or others keep committing to the default branch then Renovate cannot find
 Once a branch is automerged, the "Git state" needs to be recalculated for every remaining branch.
 At times, merging one branch could result in another branch's updates being changed or even removed as unnecessary.
 Renovate's approach is to ensure that automerging branches are up-to-date with their target branch before automerging.
-Therefore merging multiple branches in a row won't reliably work, we prefer not to do that.
+This means merging multiple branches in a row won't work reliably, so we prefer not to do that.
 What all this means is that Renovate will only automerge at most one branch/PR per target branch per run, before you need to wait for the next run.
 
 As a general guide, we recommend that you enable automerge for any type of dependency updates where you would just click "merge" anyway.
@@ -66,7 +66,7 @@ But in many cases the new version(s) will pass tests, and if so then there's rea
 
 ### Automerge non-major updates
 
-Non-major updates in SemVer ecosystems shouldn't have breaking changes (if they follow the spec), therefore many users enable automerge for these too:
+Non-major updates in SemVer ecosystems shouldn't have breaking changes (if they follow the spec), so many users enable automerge for these too:
 
 ```json
 {
diff --git a/docs/usage/known-limitations.md b/docs/usage/known-limitations.md
index 87a12f6709..a3ec63ca85 100644
--- a/docs/usage/known-limitations.md
+++ b/docs/usage/known-limitations.md
@@ -26,9 +26,9 @@ For this reason, it's best to allow for a minimum 2-3 hours schedule window per
 
 ## Automerge limitations
 
-Renovate automerges at most one branch per run.
-Renovate will only automerge a branch when it is up-to-date with the target branch.
-Therefore, Renovate may not be able to automerge as many branches as you expect, especially if your base branch is receiving regular commits at the same time.
+- Renovate automerges at most one branch per run
+- Renovate will only automerge a branch when it is up-to-date with the target branch
+- Renovate may not be able to automerge as many branches as you expect, especially if your base branch is receiving regular commits at the same time
 
 The limitation to only merge one branch per run is because Renovate's dependency and branch state is based on what was present in the base branch at the start of the run.
 If a branch is merged into the base branch during Renovate's run - including by other users - it means that remaining Renovate branches may have Git conflicts.
diff --git a/docs/usage/noise-reduction.md b/docs/usage/noise-reduction.md
index ec2cf2a670..b19ca456c7 100644
--- a/docs/usage/noise-reduction.md
+++ b/docs/usage/noise-reduction.md
@@ -52,8 +52,9 @@ For a high level overview of scheduling when Renovate bot runs, read the [key co
 
 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`).
+
 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, e.g. soon after versions are published to npm.
+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).
diff --git a/docs/usage/self-hosted-configuration.md b/docs/usage/self-hosted-configuration.md
index 12c31085c6..6b4a84336f 100644
--- a/docs/usage/self-hosted-configuration.md
+++ b/docs/usage/self-hosted-configuration.md
@@ -396,7 +396,7 @@ Disabling the warning is helpful for self-hosted environments that can't access
 ## globalExtends
 
 Unlike the `extends` field, which is passed through unresolved to be part of repository config, any presets in `globalExtends` are resolved immediately as part of global config.
-Therefore you need to use this field if your preset has any global-only configuration options, such as the list of repositories to run against.
+Use the `globalExtends` field if your preset has any global-only configuration options, such as the list of repositories to run against.
 
 Use the `extends` field instead of this if, for example, you need the ability for a repository config (e.g. `renovate.json`) to be able to use `ignorePresets` for any preset defined in global config.
 
diff --git a/docs/usage/updating-rebasing.md b/docs/usage/updating-rebasing.md
index 706d06cb08..35eae7b54b 100644
--- a/docs/usage/updating-rebasing.md
+++ b/docs/usage/updating-rebasing.md
@@ -57,7 +57,7 @@ Or you can add a "rebase" label to the PR.
 The label name is configurable via the `rebaseLabel` option.
 
 If you apply a rebase label then Renovate will regenerate its commit for the branch, even if the branch has been modified.
-Therefore it is useful in situations such as:
+The rebase label is useful in situations like:
 
 - If a branch is stale but you don't have `rebaseWhen=behind-base-branch` enabled
 - If a branch has been edited and you want to discard the edits and have Renovate create it again
diff --git a/lib/modules/datasource/docker/readme.md b/lib/modules/datasource/docker/readme.md
index ab423d1709..e8012fce9a 100644
--- a/lib/modules/datasource/docker/readme.md
+++ b/lib/modules/datasource/docker/readme.md
@@ -2,7 +2,7 @@ This datasource identifies an image's source repository according to the [pre-de
 
 This datasource looks for the metadata of the **latest stable** image found on the Docker registry and uses the value of the label `org.opencontainers.image.source` and `org.label-schema.vcs-url` as the `sourceUrl`.
 
-The [Label Schema](https://label-schema.org/) is superseded by OCI annotations, therefore `org.opencontainers.image.source` label should be preferred.
+The [Label Schema](https://label-schema.org/) is superseded by OCI annotations, use the `org.opencontainers.image.source` label if possible.
 
 If you maintain a Docker image and want Renovate to find your changelogs, add a `org.opencontainers.image.source` field to your Dockerfile.
 The link must point to your GitHub or GitLab repository.
diff --git a/lib/modules/manager/gomod/readme.md b/lib/modules/manager/gomod/readme.md
index f41d8b140f..8d2a59ee7e 100644
--- a/lib/modules/manager/gomod/readme.md
+++ b/lib/modules/manager/gomod/readme.md
@@ -7,4 +7,4 @@ You might be interested in the following `postUpdateOptions`:
 1. `gomodMassage` - to enable massaging of all `replace` statements prior to running `go` so that they will be ignored.
 
 When Renovate is running using `binarySource=docker` (such as in the hosted Mend Renovate app) then it will pick the latest compatible version of Go to run, i.e. the latest `1.x` release.
-Therefore even if the `go.mod` has a version like `go 1.14`, you will see Renovate treating that as a `^1.14` constraint and not `=1.14`.
+Even if the `go.mod` has a version like `go 1.14`, Renovate will treat it as a `^1.14` constraint and not `=1.14`.
diff --git a/lib/modules/manager/pip-compile/readme.md b/lib/modules/manager/pip-compile/readme.md
index 981635be2b..894002ffa6 100644
--- a/lib/modules/manager/pip-compile/readme.md
+++ b/lib/modules/manager/pip-compile/readme.md
@@ -21,8 +21,7 @@ You can "activate" the manager by specifying a `fileMatch` pattern such as:
 
 If Renovate matches/extracts a file, it assumes that the corresponding output file is found by swapping the `.in` for `.txt`.
 e.g. `requirements.in` => `requirements.txt`
-
-Therefore it will not work if files are in separate directories, including `input/requirements.in` and `output/requirements.txt`.
+It will not work if files are in separate directories, including `input/requirements.in` and `output/requirements.txt`.
 
 If no `.in` suffix is found, then a `.txt` suffix is appended for the output file, e.g. `foo.file` would look for a corresponding `foo.file.txt`.
 
diff --git a/lib/modules/manager/pre-commit/readme.md b/lib/modules/manager/pre-commit/readme.md
index 04d9d97af5..0878f3975f 100644
--- a/lib/modules/manager/pre-commit/readme.md
+++ b/lib/modules/manager/pre-commit/readme.md
@@ -1,6 +1,6 @@
 _Important note_: The `pre-commit` manager is disabled by default and must be opted into through config.
 Renovate's approach to version updating is not fully aligned with `pre-commit upgrade` and this has caused frustration for `pre-commit`'s creator/maintainer.
-Attempts to work with the `pre-commit` project to fix these gaps have been rejected, so therefore we have chosen to disable the manager by default indefinitely.
+Attempts to work with the `pre-commit` project to fix these gaps have been rejected, so we have chosen to disable the manager by default indefinitely.
 Please do not contact the `pre-commit` project/maintainer about any Renovate-related topic.
 To view a list of open issues related to the `pre-commit` manager in Renovate, see the [filtered list using the `manager:pre-commit` label](https://github.com/renovatebot/renovate/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Amanager%3Apre-commit).
 
-- 
GitLab