docs: fix grammar and base strategy design href (googleapis#1674)

README.md

@@ -121,8 +121,8 @@ prefixes: "feat", "fix", and "deps".
 Some languages have their specific releasable unit configuration. For example,
 "docs" is a prefix for releasable units in Java and Python.
 
-If you think Release Please missed to create a release PR after a pull request
-with with releasable unit has been merged, please re-run `release-please`. If you are using
+If you think Release Please missed creating a release PR after a pull request
+with a releasable unit has been merged, please re-run `release-please`. If you are using
 the GitHub application, add `release-please:force-run` label to the merged pull request. If
 you are using the action, look for the failed invocation and retry the workflow run.
 Release Please will process the pull request immediately to find releasable units.
@@ -171,7 +171,7 @@ for installation and configuration instructions.
 ## Bootstrapping your Repository
 
 Release Please looks at commits since your last release tag. It may or may not be able to find
-your previous releases. The easiest way to on-board your repository is to
+your previous releases. The easiest way to onboard your repository is to
 [bootstrap a manifest config](/docs/cli.md#bootstrapping).
 
 ## Customizing Release Please

docs/cli.md

@@ -209,10 +209,10 @@ This CLI command is deprecated in favor of `github-release` which handles this p
 same options. This command is preserved for backward compatibility and will be removed in the
 next major version.
 
-This command should run some time after a release PR has been merged and before
+This command should run sometime after a release PR has been merged and before
 the next release PR is merged. It will create GitHub Releases based on the
 last merged release PR it finds (which is why you don't want to let two release
-PRs merge w/out running it). If successful it will remove the
+PRs merge without running it). If successful it will remove the
 `"autorelease: pending"` label and adds the `"autorelease: tagged"` label.
 Creating all the releases is not transactional. If any fail to create the
 command can be re-run safely to finish creating releases.

docs/customizing.md

@@ -134,7 +134,7 @@ using the [Generic](/src/updaters/generic.ts) updater. You can specify
 a comma separated list of file paths with the `--extra-files` CLI option
 or the `extra-files` option in the manifest configuration.
 
-To mark versions needing update in those files, you will add annotations
+To mark versions needing an update in those files, you will add annotations
 (usually in comments).
 
 You can annotate a line (inline) via:

docs/design.md

@@ -47,7 +47,7 @@ For more information, see https://semver.org
 
 ### Conventional commits
 
-Conventional commits is a specification for making commit messages machine readable and
+Conventional commits is a specification for making commit messages machine-readable and
 informing automation tools (like `release-please`) about the context of the commit.
 
 For more information, see https://conventionalcommits.org
@@ -134,7 +134,7 @@ for fetching file contents/data from the GitHub API.
 
 ### Version
 
-We have a concrete, core class [`Version`][version] which is encapsulates a semantic
+We have a concrete, core class [`Version`][version] which encapsulates a semantic
 version.
 
 A [`Version`][version] instance contains:
@@ -147,7 +147,7 @@ A [`Version`][version] instance contains:
 
 ### Versioning strategy
 
-We define a [`VersioningStrategy`][versioning-strategy] interface which abstracts the
+We define a [`VersioningStrategy`][versioning-strategy] interface that abstracts the
 notion of how to increment a `Version` given a list of commits.
 
 In the default case ([`DefaultVersioningStrategy`][default-versioning-strategy]):
@@ -172,7 +172,7 @@ update when proposing the next release version. In the most basic case
 ([`Simple`][simple-strategy]), we do not update any source files except the `CHANGELOG.md`.
 
 **Contributor note**: Implementation-wise, most strategies inherit from the
-[`BaseStrategy`](base-strategy). This is not necessary, but it handles most of the common
+[`BaseStrategy`][base-strategy]. This is not necessary, but it handles most of the common
 behavior. If you choose to extend `BaseStrategy`, you only need to implement a single
 `buildUpdates()` method (which files need to be updated).
 
@@ -181,7 +181,7 @@ test to ensure we don't break it in the future.
 
 ### Updating file contents
 
-The most common customation a `Strategy` makes is determining which standard files need to be
+The most common customization a `Strategy` makes is determining which standard files need to be
 updated. For example, in a `nodejs` library, you will want to update the `version` entry in
 your library's `package.json` (and `package-lock.json` if it exists).
 
@@ -200,7 +200,7 @@ test to ensure we don't break it in the future.
 We define a [`ChangelogNotes`][changelog-notes] interface which abstracts the notion of how
 to build a `CHANGELOG.md` entry given a list of commits. The default implementation
 ([`DefaultChangelogNotes`][default-changelog-notes]), uses the
-`conventional-changelog-writer` library to generate a standardized release notes based on
+`conventional-changelog-writer` library to generate standardized release notes based on
 the conventionalcommits.org specification.
 
 We also have a second implementation that uses the GitHub changelog generator API.

docs/java.md

@@ -1,22 +1,22 @@
 # Java and Maven Strategies
 
-This strategy generates SNAPSHOT versions after each release. Snapshot is created as separate "release" Pull Request, which updates all affected files, but does not create actual release or tag.
+This strategy generates SNAPSHOT versions after each release. Snapshot is created as a separate "release" Pull Request, which updates all affected files, but does not create an actual release or tag.
 
 Snapshot bumps have `autorelease: snapshot` label.
 
 ## `java` Strategy
 
 General-purpose Java strategy, that does not update any files on its own.
 
-Uses `extra-files` to bump versions in actual files. For typical Maven project, use `maven` strategy instead. 
+Uses `extra-files` to bump versions in actual files. For a typical Maven project, use the `maven` strategy instead. 
 
 ## `maven` Strategy
 
 Updates all found `pom.xml` files (recursively) using `pom` updater.
 
 ## `pom` Updater
 
-Updates `/project/version` to current version automatically.
+Updates `/project/version` to the current version automatically.
 
-If version is not set, it tries to update `/project/parent/version`, assuming it is submodule which inherits version from its parent and should be bumped too. 
-If this behavior is not intended, use `generic` or `xml` updater via `extra-files`.
+If the version is not set, it tries to update `/project/parent/version`, assuming it is a submodule which inherits the version from its parent and should be bumped too. 
+If this behavior is not intended, use the `generic` or `xml` updater via `extra-files`.

docs/manifest-releaser.md

@@ -1,6 +1,6 @@
 # Manifest Driven release-please
 
-release-please can be setup to use source controlled files containing releaser
+release-please can be setup to use source-controlled files containing releaser
 specific configuration (the `release-please-config.json`) as well package
 version tracking (the `.release-please-manifest.json`).
 
@@ -84,7 +84,7 @@ this config value will be ignored for all subsequent runs and can be removed.
 The simplest way to tell release-please the current version for a package
 it has never released before is to manually add an entry into
 `.release-please-manifest.json`. This change should be made directly on the
-default/configured branch or on a separate, user created branch/PR which is then
+default/configured branch or on a separate, user-created branch/PR which is then
 merged into the default/configured branch.
 
 ```js
@@ -447,14 +447,14 @@ It looks at what packages were updated by release-please and updates their
 reference in other packages' dependencies lists. Even when a particular package
 was not updated by release-please, if a dependency did have an update, it will
 be patch bump the package, create a changelog entry, and add it to the list of
-PR changes. Under the hood this plugin adapts specific dependency graph building
+PR changes. Under the hood, this plugin adapts specific dependency graph building
 and updating functionality from the popular
 [lerna](https://github.com/lerna/lerna) tool.
 
 #### Breaking versions
 
 When using the `node-workspace` tool, breaking versions bumps will be included in
-your update pull request. If you don't agree this behavior and would only like
+your update pull request. If you don't agree with this behavior and would only like
 your local dependencies bumped if they are within the SemVer range, you can set the
 `"always-link-local"` option to `false` in your manifest config.