docs: Proofreading + general improvements

docs/development/adding-a-package-manager.md

@@ -38,20 +38,20 @@ For example:
 ### `extractPackageFile(content, packageFile, config)` (async, semi-mandatory)
 
 This function is mandatory, unless you use `extractAllPackageFiles` instead.
-It takes as arguments the file's content and optionally the file's full file pathname and config.
+It takes as arguments the content of the file and optionally the full file pathname and config.
 The function returns an array of detected or extracted dependencies, including the:
 
 - dependency name
-- dependency type (dependencies, devDependencies, etc)
+- dependency type (dependencies, devDependencies, etc.)
 - currentValue
 - versioning used (like SemVer, PEP 440)
 
-The `extractPackageFile` function doesn't need to fully _understand_ the file or syntax that it gets.
+The `extractPackageFile` function does not need to fully _understand_ the file or syntax that it gets.
 It needs to understand enough to extract a correct list of dependencies.
 
-In general, we extract _all_ dependencies from each dependency file, even if they have values we don't support.
+In general, we extract _all_ dependencies from each dependency file, even if they have values we do not support.
 
-If the function reads parts of a dependency file that it can't parse, it should give a `skipReason` message to the `extractPackageFile` function.
+If the function reads parts of a dependency file that it can not parse, it should give a `skipReason` message to the `extractPackageFile` function.
 Make sure the `skipReason` message is helpful to someone reading the logs.
 
 If `extractPackageFile` is passed a file which is a "false match", so not a package file, or a file with no dependencies then it can return `null`.
@@ -60,7 +60,7 @@ Downstream this results in the file being ignored and removed from the list of p
 ### `extractAllPackageFiles(packageFiles)` (async, optional)
 
 Normally a package manager parses or extracts all package files in _parallel_, and can thus use the `extractPackageFile` function.
-If the package manager you're adding works in _serial_, use this function instead.
+If the package manager you are adding works in _serial_, use this function instead.
 
 For example the npm and Yarn package manager must process the `package.json` and `package-lock` or `yarn.lock` files together.
 This allows features like Workspaces to work.
@@ -102,7 +102,7 @@ To _directly_ update dependencies in lock files: use `updateLockedDependency` in
 
 Use `updateDependency` if _both_ conditions apply:
 
-- the manager can't be updated to use the standard replacing mechanism
+- the manager can not be updated to use the standard replacing mechanism
 - a custom replacement has to be provided
 
 ### `updateLockedDependency` (optional)

docs/development/best-practices.md

@@ -1,12 +1,12 @@
 # Best practices
 
 This document explains our best practices.
-Follow these best practices when you're working on our code.
+Follow these best practices when you are working on our code.
 
 ## Git branch names
 
 Branch names should start with a [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) scope like `feat/` or `fix/`.
-If you're closing an issue with your PR then put the issue number after the scope.
+If you are closing an issue with your PR then put the issue number after the scope.
 Finally, describe the changes in the branch in a few words.
 
 Some good branch names:
@@ -18,7 +18,7 @@ Some good branch names:
 
 Avoid branch names like `patch-1`.
 
-If you don't know the correct Conventional Commit scope: give your branch a descriptive name like `issue-1-feature-foo`.
+If you do not know the correct Conventional Commit scope: give your branch a descriptive name like `issue-1-feature-foo`.
 
 If you forgot to pick a good branch name when you started work, then rename the branch before creating the pull request.
 Read the [GitHub Docs, renaming a branch](https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-branches-in-your-repository/renaming-a-branch) to learn how to rename your branch on GitHub.
@@ -73,7 +73,7 @@ Source: [Google TypeScript Style Guide, function declarations](https://google.gi
 ### Write understandable code
 
 Write code that is easier to read, review and maintain.
-Avoid "clever" code that's hard to understand.
+Avoid "clever" code that is hard to understand.
 
 Prefer verbose code which is easier for others to read and maintain than concise code which may be hard or slower for others to understand.
 For example, Array `reduce()` functions are often hard to understand first time, and can be replaced with simpler `for` loops.

docs/development/creating-editing-renovate-presets.md

@@ -22,12 +22,12 @@ We have multiple kinds of `group:` presets, with different rules.
 
 ##### Rules for `group:recommended` presets
 
-1. The `group:recommended` preset is for related dependencies which aren't from a monorepo but which usually need to be updated together as separate PRs may each break
+1. The `group:recommended` preset is for related dependencies which are not from a monorepo but which usually need to be updated together as separate PRs may each break
 
 ##### Rules for `group:*` presets
 
 1. Finally, any other `group:*` presets can be added if they are beneficial to a wide number of users
-1. They don't need to be added to `group:recommended`, meaning that users will "opt in" to them one by one and not get them automatically from `config:recommended`, which includes `group:monorepo` and `group:recommended`
+1. They do not need to be added to `group:recommended`, meaning that users will "opt in" to them one by one and not get them automatically from `config:recommended`, which includes `group:monorepo` and `group:recommended`
 
 #### Replacement presets
 

docs/development/design-decisions.md

@@ -47,9 +47,9 @@ You could limit Renovate to only update the `package.json` in the root of the re
 
 ## Separate Branches per dependency
 
-By default, `renovate` will maintain separate branches for each dependency.
-So if 20 dependencies need updating, there will be at least 20 branches/PRs.
-Although this may seem undesirable, it's even less desirable if all 20 were in the same Pull Request and it's very difficult to work out which upgrade caused the test failure.
+We decided that Renovate should create a separate branch for each dependency, at least by default.
+So if 20 dependencies need to be updated, you will get 20 branches (and 20 PRs) from Renovate.
+This may look bad, but it's better than putting all 20 dependencies in a single branch, which makes it hard to work out which upgrade causes a test failure.
 
 But you can override the default templates for branch name to get a single branch for all dependencies.
 The `groupName` configuration option can be used at a repository level (e.g. give it the value `All`) and then all dependency updates will be in the same branch/PR.
@@ -61,7 +61,7 @@ For example, if the current example is 1.6.0 and upgrades to 1.7.0 and 2.0.0 exi
 
 Our reasons for separating minor and major PRs:
 
-- It's often the case that projects can't upgrade major dependency versions immediately
+- It's often the case that projects can not upgrade major dependency versions immediately
 - It's also often the case that previous major versions continue receiving Minor or Patch updates
 - Projects should get Minor and Patch updates for their current Major release even if a new Major release exists
 
@@ -73,7 +73,7 @@ Branches have names like `renovate/webpack-1.x` instead of `renovate/webpack-1.2
 
 We do this because:
 
-- Branches often get updates (e.g. new patches) before they're merged
+- Branches often get updates (e.g. new patches) before they are merged
 - Naming the branch like `1.x` means its name still makes sense if a `1.2.1` release happens
 
 Note: You can configure the branch names by using the string template `branchName` and/or its sub-templates `branchPrefix` and `branchTopic`.
@@ -83,14 +83,14 @@ Note: You can configure the branch names by using the string template `branchNam
 By default, the script does not create a new PR if it finds a previously-closed PR with the same branch name and PR title (assuming the PR title has a version in it).
 This allows users to close unwelcome upgrade PRs and not worry about them being recreated every run.
 
-## Rebasing Unmergeable Pull Requests
+## Rebasing unmergeable Pull Requests
 
 With the default behavior of one branch per dependency, it's often the case that a PR gets merge conflicts after an adjacent dependency update is merged.
-On most platforms you can use a web interface to resolve merge conflicts, but you're still resolving the conflicts manually, which is annoying.
+On most platforms you can use a web interface to resolve merge conflicts, but you are still resolving the conflicts manually, which is annoying.
 
 `renovate` will rebase any unmergeable branches and add the latest necessary commit on top of the most recent `main` commit.
 
-Note: `renovate` will only do this if the original branch hasn't been modified by anyone else.
+Note: `renovate` will only do this if the original branch has not been modified by anyone else.
 
 ## Suppressing string templates from CLI
 
@@ -107,6 +107,6 @@ Alternatively, consider using a Configuration File.
 
 Renovate uses the following convention for log levels:
 
-- logger.error should only be used for problems that are likely to be a Renovate bug or require Renovate improvements. These are the types of errors that Renovate administrators should be alerted to immediately
-- logger.warn should be used for problems that might be a Renovate problem so should be checked periodically in batches
+- `logger.error` should only be used for problems that are likely to be a Renovate bug or require Renovate improvements. These are the types of errors that Renovate administrators should be alerted to immediately
+- `logger.warn` should be used for problems that might be a Renovate problem so should be checked periodically in batches
 - For _user_ problems (e.g. configuration errors), these should not warn or error on the server side and instead use logger.info

docs/development/help-us-help-you.md

@@ -17,30 +17,30 @@ This also means that features or bug fixes that you really want can take a long
 
 ## Be respectful to competitors
 
-Even if you're intending to express a compliment to Renovate from a good heart, try not to phrase it in a way which would be insulting to the developers of alternative tools like Dependabot.
-There are a lot of good bots out there, and while we're happy if you like Renovate, we are friends with the creators and developers of other bots and want to keep things friendly.
+Even if you are intending to express a compliment to Renovate from a good heart, try not to phrase it in a way which would be insulting to the developers of alternative tools like Dependabot.
+There are a lot of good bots out there, and while we are happy if you like Renovate, we are friends with the creators and developers of other bots and want to keep things friendly.
 
-Objective, respectful comparisons or questions are always welcome too - including if you find Renovate missing something you'd like to see.
+Objective, respectful comparisons or questions are always welcome too - including if you find Renovate missing something you would like to see.
 
 ## Provide adequate descriptions
 
-Renovate maintainers and contributors spend many hours helping users, most of the time with problems which are the user's own misconfiguration or misunderstanding.
-When you ask for help or are receiving it, please put effort into adequately describing your problem, what you've tried, and what you're trying to do.
+Renovate maintainers and contributors spend many hours helping users, most of the time with problems which are the own misconfiguration or misunderstanding from the user.
+When you ask for help or are receiving it, please put effort into adequately describing your problem, what you have tried, and what you are trying to do.
 
-If you describe a problem with too few details, and we ask you follow-up questions, and you continue to give short and incomplete descriptions, you're likely to not get any further questions or help.
+If you describe a problem with too few details, and we ask you follow-up questions, and you continue to give short and incomplete descriptions, you are likely to not get any further questions or help.
 You may get referred to this document though, to explain why!
 
-In other words, if someone's taking the time to help you, "don't be lazy".
+In other words, if someone is taking the time to help you, "do not be lazy".
 
 ## Avoid complaining about docs after getting help
 
-If someone's helped you get some functionality working, or successfully troubleshoot a problem, please try to do this:
+If someone has helped you get some functionality working, or successfully troubleshoot a problem, please try to do this:
 
 - Let us know which advice fixed your problem, if it's unclear
-- If you're feeling polite, thank the person who helped you
-- If you're feeling helpful, submit a Pull Request to improve the relevant documentation
+- If you are feeling polite, thank the person who helped you
+- If you are feeling helpful, submit a Pull Request to improve the relevant documentation
 
-Please don't ruin a successful result with a criticism or complaint about the quality of the documentation.
+Please do not ruin a successful result with a criticism or complaint about the quality of the documentation.
 If you feel frustrated because better documentation would have prevented you from making the mistake in the first place then improve it with a PR for those who come after you!
 
 ## Avoid spamming issues
@@ -52,7 +52,7 @@ Instead, use the "Subscribe" button to follow issues.
 
 ## Reproduce repositories on github.com
 
-If you've been asked to provide a reproduction repository, please create it on github.com unless the reproduction itself is specific to another platform like GitLab.
+If you have been asked to provide a reproduction repository, please create it on github.com unless the reproduction itself is specific to another platform like GitLab.
 
 The Renovate maintainers can test and debug the quickest when using GitHub, and we also have a dedicated organization called [renovate-reproductions](https://github.com/renovate-reproductions/) where we fork reproductions into so that we have a copy in case the original creator removes theirs.
 
@@ -61,21 +61,21 @@ The Renovate maintainers can test and debug the quickest when using GitHub, and
 We have documented what a "minimal" reproduction repository means, and request that you stick to it.
 The more config and the more dependencies in a reproduction, the slower it is to debug and solve the problem.
 
-Unless you're planning to work on the feature or fix yourself, please be respectful of the person's time who would need to do the work instead.
+Unless you are planning to work on the feature or fix yourself, please be respectful of the person's time who would need to do the work instead.
 
 ## Filter logs before sharing them
 
-If you've been asked to give us the logs in an issue or discussion, please don't copy/paste the entire output and expect someone else to sort through thousands of lines to help you.
+If you have been asked to give us the logs in an issue or discussion, please do not copy/paste the entire output and expect someone else to sort through thousands of lines to help you.
 A full log dump takes a lot of time to scroll through, and it is next to impossible to do so from mobile.
 
 Instead, please select the logs relevant to your problem and paste only the relevant logs.
-If it turns out there's a need for the full dump, someone can ask you for it later.
+If it turns out there is a need for the full dump, someone can ask you for it later.
 
 ## Avoid unjustified bug reports
 
-Don't raise a bug report unless it's definitely a bug.
-"I don't like this" or "I didn't expect this to happen" is not the same thing as a bug.
+Do not raise a bug report unless it's definitely a bug.
+"I do not like this" or "I did not expect this to happen" is not the same thing as a bug.
 
 Many unjustified bug reports are filed because people they think it will get them more attention.
-Instead, you may be wasting maintainer time because we have to reclassify your invalid bug report or convert it to a discussion, and you are much less likely to get the attention you're hoping for.
+Instead, you may be wasting maintainer time because we have to reclassify your invalid bug report or convert it to a discussion, and you are much less likely to get the attention you are hoping for.
 If in doubt, start a discussion instead.

docs/development/issue-labeling.md

@@ -55,7 +55,7 @@ For example, use `status:requirements` to mean that an issue is not yet ready fo
 
 Use these to label the type of issue.
 For example, use `type:bug` to label a bug type issue, and use `type:feature` for feature requests.
-Only use `type:refactor` for code changes, don't use `type:refactor` for documentation type changes.
+Only use `type:refactor` for code changes, do not use `type:refactor` for documentation type changes.
 
 All issues should have a `type:*` label.
 Use [this search](https://github.com/renovatebot/renovate/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+-label%3Atype%3Abug+-label%3Atype%3Afeature+-label%3Atype%3Adocs+-label%3Atype%3Arefactor+) to find issues without a `type:*` label.
@@ -185,7 +185,7 @@ Add a label `duplicate` to issues/PRs that are a duplicate of an earlier issue/P
 Add a label `good first issue` to issues that are small, easy to fix, and do-able for a newcomer.
 This label is sometimes picked up by tools or websites that try to encourage people to contribute to open source.
 
-Add the label `help wanted` to indicate that we need the original poster or someone else to do some work or it is unlikely to get done.
+Add the label `help wanted` to indicate that we need the original poster or someone else to do some work, or it is unlikely to get done.
 
 Add a label `auto:bad-vibes` to any discussion containing rude comments such as excessive criticism or ungratefulness.
 
@@ -195,7 +195,7 @@ Add a label `auto:discussion-first` to any PR which needs discussing first.
 
 Add a label `auto:format-code` to any Discussion which needs code formatting.
 
-Add a label `auto:logs` to indicate that there's a problem with the logs, and the contributor needs to do one of these things:
+Add a label `auto:logs` to indicate that there is a problem with the logs, and the contributor needs to do one of these things:
 
 1. Provide logs (if there are none yet)
 1. Provide more logs (in case current logs are insufficient)
@@ -207,7 +207,7 @@ Add a label `auto:no-coverage-ignore` if PR authors avoid needed unit tests by i
 
 Add a label `auto:no-done-comments` if PR authors unnecessary "Done" comments, or type comments to ask for a review instead of requesting a new review through GitHub's UI.
 
-Add a label `auto:reproduction` if nobody's reproduced it in a public repo yet and such a reproduction is necessary before further work can be done.
+Add a label `auto:reproduction` if nobody has reproduced it in a public repo yet and such a reproduction is necessary before further work can be done.
 
 Add a label `auto:retry-latest` to any Discussion where the user should retry the latest version of Renovate to see if the problem persists.