docs: fix typos (#2061)

* docs: fix typo

* docs: fix typos

* docs: fix typos

Author: omahs

docs/contributing.md

@@ -17,11 +17,11 @@ Everyone contributing to the cibuildwheel project is expected to follow the [PSF
 - `cibuildwheel` should wrap the complexity of wheel building.
 - The user interface to `cibuildwheel` is the build script (e.g. `.travis.yml`). Feature additions should not increase the complexity of this script.
 - Options should be environment variables (these lend themselves better to YML config files). They should be prefixed with `CIBW_`.
-- Options should be generalise to all platforms. If platform-specific options are required, they should be namespaced e.g. `CIBW_TEST_COMMAND_MACOS`
+- Options should be generalised to all platforms. If platform-specific options are required, they should be namespaced e.g. `CIBW_TEST_COMMAND_MACOS`
 
 Other notes:
 
-- The platforms are very similar, until they're not. I'd rather have straight-forward code than totally DRY code, so let's keep airy platform abstractions to a minimum.
+- The platforms are very similar, until they're not. I'd rather have straightforward code than totally DRY code, so let's keep airy platform abstractions to a minimum.
 - I might want to break the options into a shared config file one day, so that config is more easily shared. That has motivated some of the design decisions.
 
 ### cibuildwheel's relationship with build errors
@@ -102,7 +102,7 @@ CIBW_PLATFORM=linux pytest test -k test_build_frontend_args
 
 ### Linting, docs
 
-Most developer tasks have a nox interface. This allows you to very simply run tasks without worrying about setting up a development environment (as shown below). This is a slower than setting up a development environment and reusing it, but has the (important) benefit of being highly reproducible; an earlier run does not affect a current run, or anything else on your machine.
+Most developer tasks have a nox interface. This allows you to very simply run tasks without worrying about setting up a development environment (as shown below). This is slower than setting up a development environment and reusing it, but has the (important) benefit of being highly reproducible; an earlier run does not affect a current run, or anything else on your machine.
 
 You can see a list of sessions by typing `nox -l`; here are a few common ones:
 

docs/deliver-to-pypi.md

@@ -86,7 +86,7 @@ This requires setting this GitHub workflow in your project's PyPI settings (for
 
 You should use Dependabot to keep the publish action up to date. In the above
 example, the same name (the default, "artifact" is used for all upload-artifact
-runs, so we can just download all of the in one step into a common directory.
+runs, so we can just download all of them in one step into a common directory.
 
 See
 [`examples/github-deploy.yml`](https://github.com/pypa/cibuildwheel/blob/main/examples/github-deploy.yml)

docs/faq.md

@@ -133,7 +133,7 @@ myextension = Extension(
 
 ### Automatic updates using Dependabot {: #automatic-updates}
 
-Selecting a moving target (like the latest release) is generally a bad idea in CI. If something breaks, you can't tell whether it was your code or an upstream update that caused the breakage, and in a worse-case scenario, it could occur during a release.
+Selecting a moving target (like the latest release) is generally a bad idea in CI. If something breaks, you can't tell whether it was your code or an upstream update that caused the breakage, and in a worst-case scenario, it could occur during a release.
 
 There are two suggested methods for keeping cibuildwheel up to date that instead involve scheduled pull requests using GitHub's Dependabot.
 
@@ -184,7 +184,7 @@ This will also try to update other pins in all requirement files, so be sure you
 ### Alternatives to cibuildwheel options {: #cibw-options-alternatives}
 
 cibuildwheel provides lots of opportunities to configure the build
-environment. However, you  might consider adding this build configuration into
+environment. However, you might consider adding this build configuration into
 the package itself - in general, this is preferred, because users of your
 package 'sdist' will also benefit.