docs: Fix typos (#6641)

Co-authored-by: Ben Sherman <bentshermann@gmail.com>

Author: christopher-hakkaart

docs/cli.md

@@ -32,7 +32,7 @@ $ nextflow run main.nf
 
 **Remote pipelines**
 
-Use the format `<organization>/<repository>` to run a pipeline from directly from Git repositories:
+Use the format `<organization>/<repository>` to run a pipeline directly from Git repositories:
 
 ```console
 $ nextflow run nextflow-io/hello

docs/conda.md

@@ -6,7 +6,7 @@
 
 Nextflow has built-in support for Conda that allows the configuration of workflow dependencies using Conda recipes and environment files.
 
-This allows Nextflow applications to use popular tool collections such as [Bioconda](https://bioconda.github.io) and the [Python Package index](https://pypi.org/), whilst taking advantage of the configuration flexibility provided by Nextflow.
+This allows Nextflow applications to use popular tool collections such as [Bioconda](https://bioconda.github.io) and the [Python Package index](https://pypi.org/), while taking advantage of the configuration flexibility provided by Nextflow.
 
 ## Prerequisites
 
@@ -93,7 +93,7 @@ process hello {
 ```
 
 :::{warning}
-The environment file name **must** have a `.yml` or `.yaml` extension or else it won't be properly recognised.
+The environment file name **must** have a `.yml` or `.yaml` extension or else it won't be properly recognized.
 :::
 
 (conda-pypi)=

docs/config.md

@@ -166,7 +166,7 @@ profiles {
 }
 ```
 
-See {ref}`cli-params` for information about how pipeline parameters are resovled at runtime.
+See {ref}`cli-params` for information about how pipeline parameters are resolved at runtime.
 
 (config-process)=
 

docs/executor.md

@@ -221,7 +221,7 @@ See the {ref}`Kubernetes <k8s-page>` page to learn how to set up a Kubernetes cl
 
 ## Local
 
-The `local` executor is used by default. It runs the pipeline processes on the computer where Nextflow is launched. The processes are parallelised by spawning multiple threads, taking advantage of the multi-core architecture of the CPU.
+The `local` executor is used by default. It runs the pipeline processes on the computer where Nextflow is launched. The processes are parallelized by spawning multiple threads, taking advantage of the multi-core architecture of the CPU.
 
 The `local` executor is useful for developing and testing a pipeline script on your computer, before switching to a cluster or cloud environment with production data.
 

docs/reference/process.md

@@ -364,9 +364,9 @@ The example above declares that the CPU generic architecture is `linux/x86_64` (
 
 This directive is currently used by the following Nextflow functionalities:
 
-- by the [spack](#spack) directive, to build microarchitecture-optimised applications;
+- by the [spack](#spack) directive, to build microarchitecture-optimized applications;
 - by the {ref}`wave-page` service, to build containers for one of the generic families of CPU architectures (see below);
-- by the `spack` strategy within {ref}`wave-page`, to optimise the container builds for specific CPU microarchitectures.
+- by the `spack` strategy within {ref}`wave-page`, to optimize the container builds for specific CPU microarchitectures.
 
 Allowed values for the `arch` directive are as follows, grouped by equivalent family (choices available for the sake of compatibility):
 - X86 64 bit: `linux/x86_64`, `x86_64`, `linux/amd64`, `amd64`
@@ -443,7 +443,7 @@ When using Wave, the following additional directives must be uniform:
 
 ### beforeScript
 
-The `beforeScript` directive allows you to execute a custom (Bash) snippet *before* the main process script is run. This may be useful to initialise the underlying cluster environment or for other custom initialisation.
+The `beforeScript` directive allows you to execute a custom (Bash) snippet *before* the main process script is run. This may be useful to initialize the underlying cluster environment or for other custom initialization.
 
 For example:
 

docs/reports.md

@@ -95,7 +95,7 @@ nextflow log goofy_kilby -filter 'name =~ /hello.*/ && status == "FAILED"'
 
 ## Execution report
 
-Nextflow can create an HTML execution report: a single document which includes many useful metrics about a workflow execution. The report is organised in the three main sections: `Summary`, `Resources` and `Tasks` (see below for details).
+Nextflow can create an HTML execution report: a single document which includes many useful metrics about a workflow execution. The report is organized in the three main sections: `Summary`, `Resources` and `Tasks` (see below for details).
 
 To enable the creation of this report add the `-with-report` command line option when launching the pipeline execution. For example:
 
@@ -197,7 +197,7 @@ The following table shows the fields that can be included in the execution repor
 : Nextflow process name.
 
 `tag`
-: User provided identifier associated this task.
+: User provided identifier associated with this task.
 
 `name`
 : Task name.
@@ -331,7 +331,7 @@ Nextflow can render an HTML timeline for all processes executed in your pipeline
 ```{image} _static/timeline-min.png
 ```
 
-Each bar represents a process run in the pipeline execution. The bar length represents the task duration time (wall-time). The colored area in each bar represents the real execution time. The grey area to the *left* of the colored area represents the task scheduling wait time. The grey area to the *right* of the colored area represents the task termination time (clean-up and file un-staging). The numbers on the x-axis represent the time in absolute units e.g. minutes, hours, etc.
+Each bar represents a process run in the pipeline execution. The bar length represents the task duration time (wall-time). The colored area in each bar represents the real execution time. The gray area to the *left* of the colored area represents the task scheduling wait time. The gray area to the *right* of the colored area represents the task termination time (clean-up and file un-staging). The numbers on the x-axis represent the time in absolute units e.g. minutes, hours, etc.
 
 Each bar displays two numbers: the task duration time and the virtual memory size peak.
 

docs/secrets.md

@@ -94,7 +94,7 @@ The above example is only meant to demonstrate how to access a secret, not how t
 
 ## Process directive
 
-Secrets can be accesses by processes using the {ref}`process-secret` directive. For example:
+Secrets can be accessed by processes using the {ref}`process-secret` directive. For example:
 
 ```nextflow
 process my_task {

docs/sharing.md

@@ -22,11 +22,11 @@ For example, given a bare repository at `/shared/projects/hello.git`, Nextflow i
 nextflow run file:/shared/projects/hello.git
 ```
 
-See [Git documentation](https://git-scm.com/book/en/v2/Git-on-the-Server-Getting-Git-on-a-Server) for more details about how create and manage bare repositories.
+See [Git documentation](https://git-scm.com/book/en/v2/Git-on-the-Server-Getting-Git-on-a-Server) for more details about how to create and manage bare repositories.
 
 ## Publishing your pipeline
 
-In order to publish your Nextflow pipeline to GitHub (or any other supported platform) and allow other people to use it, you only need to create a GitHub repository containing all your project script and data files. If you don't know how to do it, follow this simple tutorial that explains how [create a GitHub repository](https://help.github.com/articles/create-a-repo).
+In order to publish your Nextflow pipeline to GitHub (or any other supported platform) and allow other people to use it, you only need to create a GitHub repository containing all your project script and data files. If you don't know how to do it, follow this simple tutorial that explains how to [create a GitHub repository](https://help.github.com/articles/create-a-repo).
 
 Nextflow only requires that the main script in your pipeline project is called `main.nf`. A different name can be used by specifying the `manifest.mainScript` attribute in the `nextflow.config` file that must be included in your project. For example:
 
@@ -38,7 +38,7 @@ To learn more about this and other project metadata information, that can be def
 
 Once you have uploaded your pipeline project to GitHub other people can execute it simply using the project name or the repository URL.
 
-For example, if your GitHub account name is `acme` and you have uploaded a project into a repository named `hello` the repository URL will be `http://github.com/acme/hello` and people will able to download and run it by using either the command:
+For example, if your GitHub account name is `acme` and you have uploaded a project into a repository named `hello` the repository URL will be `http://github.com/acme/hello` and people will be able to download and run it by using either the command:
 
 ```bash
 nextflow run acme/hello

docs/spack.md

@@ -9,7 +9,7 @@
 
 Nextflow has built-in support for Spack that allows the configuration of workflow dependencies using Spack recipes and environment files.
 
-This allows Nextflow applications to build packages from source on the compute infrastructure in use, whilst taking advantage of the configuration flexibility provided by Nextflow. At shared compute facilities where Spack has been configured by the administrators, this may result in optimized builds without user intervention. With appropriate options, this also permits end users to customize binary optimizations by themselves.
+This allows Nextflow applications to build packages from source on the compute infrastructure in use, while taking advantage of the configuration flexibility provided by Nextflow. At shared compute facilities where Spack has been configured by the administrators, this may result in optimized builds without user intervention. With appropriate options, this also permits end users to customize binary optimizations by themselves.
 
 ## Prerequisites
 

docs/vscode.md

@@ -78,7 +78,7 @@ To preview the DAG of a workflow, select the **Preview DAG** CodeLens above the
 
 ### Automatic code migration
 
-The extension can automatiicaly migrate scripts to static types. See {ref}`migrating-static-types` for details.
+The extension can automatically migrate scripts to static types. See {ref}`migrating-static-types` for details.
 
 To migrate a script, open the Command Palette, search for **Convert script to static types**, and select it.