Ensure comma proceeds "by default"

src/pages/docs/administration/managing-infrastructure/server-configuration-and-file-storage/manually-uninstall-octopus-server.md

@@ -45,7 +45,7 @@ These steps will remove all traces of Octopus Server from your computer:
     * This will stop and uninstall the Octopus Server windows service.
 2. Now uninstall the MSI.
     * This will remove the application files.
-3. Find and delete the Octopus Home folder. By default this is in **`%SYSTEMDRIVE%\Octopus`**.
+3. Find and delete the Octopus Home folder. By default, this is in **`%SYSTEMDRIVE%\Octopus`**.
 4. Find and delete the Octopus registry entries from **`HKLM\SOFTWARE\Octopus`**.
 5. Find and delete any Octopus folders from:
     * **`%ProgramData%\Octopus`** - could be used for log files when a Home Directory cannot be discovered

src/pages/docs/administration/managing-infrastructure/service-watchdog.md

@@ -31,7 +31,7 @@ The scheduled task's name for the above will be **Octopus Watchdog Tentacle**.
 
 :::div{.hint}
 **Tips:**
-- By default the task will be configured to run as the Local System account, but that can be changed using the Windows Task Scheduler.
+- By default, the task will be configured to run as the Local System account, but that can be changed using the Windows Task Scheduler.
 - If the watchdog has already been configured, running the command again will reconfigure the instances and interval for the scheduled task.  Any other values that have been changed in Windows Task Scheduler will not be changed.
 
 - To specify only the default instance, use the name **Tentacle**. For example:

src/pages/docs/administration/managing-infrastructure/tentacle-configuration-and-file-storage/index.md

@@ -7,7 +7,7 @@ description: Octopus Tentacle configuration command reference including how to s
 navOrder: 1200
 ---
 
-Occasionally it may be necessary to change the location at which Tentacle stores its configuration and data, called the **Tentacle Home Directory**. By default your applications will be deployed into a folder under the Tentacle Home Directory, but you can configure this to be at a different location. This page will explain what each of the folders used by Tentacle are, how you can change the Tentacle configuration, and how you can clean up after upgrading from an earlier version of Tentacle.
+Occasionally it may be necessary to change the location at which Tentacle stores its configuration and data, called the **Tentacle Home Directory**. By default, your applications will be deployed into a folder under the Tentacle Home Directory, but you can configure this to be at a different location. This page will explain what each of the folders used by Tentacle are, how you can change the Tentacle configuration, and how you can clean up after upgrading from an earlier version of Tentacle.
 
 :::div{.problem}
 

src/pages/docs/administration/managing-infrastructure/tentacle-configuration-and-file-storage/manually-uninstall-tentacle.md

@@ -47,7 +47,7 @@ These steps will remove all traces of Octopus Tentacle from your computer:
    - This will stop and uninstall the Tentacle windows service.
 2. Now uninstall the MSI.
    - This will remove the application files.
-3. Find and delete the Octopus Home folder. By default this is in **`%SYSTEMDRIVE%\Octopus`**.
+3. Find and delete the Octopus Home folder. By default, this is in **`%SYSTEMDRIVE%\Octopus`**.
    :::div{.problem}
 
    This will also remove your deployed applications if you have not configured Tentacle to use a different Application folder. See below for more details.

src/pages/docs/administration/retention-policies/index.mdx

@@ -53,7 +53,7 @@ Note that if you use the [Custom Installation Directory](/docs/projects/steps/co
 Packages that are transferred during the deployment are managed based on quantities of packages and version to keep. By default, Octopus keeps all packages, with a maximum of 2 versions of each.
 These options can be configured for each machine under the Machine Policy.
 
-To configure quantity to keep, create a custom [Machine Policy](/docs/infrastructure/deployment-targets/machine-policies) and set the `Package Cache` policy to `Keep a limited number`. This will allow you to specify a number of versions to keep per package in the cache. By default this number of versions will be kept for all packages in the cache.
+To configure quantity to keep, create a custom [Machine Policy](/docs/infrastructure/deployment-targets/machine-policies) and set the `Package Cache` policy to `Keep a limited number`. This will allow you to specify a number of versions to keep per package in the cache. By default, this number of versions will be kept for all packages in the cache.
 To restrict the number of packages to keep, select `From the most recently used packages`, and enter your preferred number of packages to keep. Octopus will ensure that only the least recently used packages and versions are removed.
 
 :::figure

src/pages/docs/administration/retention-policies/retention-policy-tentacle-cleanup-and-troubleshooting.md

@@ -17,7 +17,7 @@ The deployment journal on the Tentacle is the source of truth for what Octopus w
 
 If the deployment journal is deleted, on the next deployment, it will be created and contain one record. But you might have many more deployments than that on the server. If the release is not in the DeploymentJournal.xml it will not be deleted with the execution of the retention policy. Any deployments not in the deployment journal will need to be manually deleted.
 
-By default your deployment journal is located at: `<Tentacle Home>\DeploymentJournal.xml`. 
+By default, your deployment journal is located at: `<Tentacle Home>\DeploymentJournal.xml`. 
 - For Windows Tentacles, the default directory is: `C:\Octopus`
 - For Linux Tentacles, the default directory is: `/etc/octopus`
 
@@ -121,7 +121,7 @@ Tentacle instances on one machine.
 ![](/docs/img/administration/retention-policies/images/3278387.png)
 :::
 
-By default your extracted package files can be found under `<Tentacle Home>\Applications\[environment name]\[package name]\`
+By default, your extracted package files can be found under `<Tentacle Home>\Applications\[environment name]\[package name]\`
 
 If you have multiple packages, you will have multiple directories.
 

src/pages/docs/administration/upgrading/legacy/upgrading-from-octopus-2.6.5-2018.10lts/in-place-upgrade-install-over-2.6.5.mdx

@@ -84,7 +84,7 @@ See the [Migrating data from Octopus 2.6.5 to 2018.10 LTS](/docs/administration/
 
 :::div{.hint}
 **Migration taking a long time?**
-By default we migrate everything from your backup including historical data. You can use the `maxage=` argument when executing the migrator to limit the number of days to keep. For example: `maxage=90` will keep 90 days of historical data ignoring anything older.
+By default, we migrate everything from your backup including historical data. You can use the `maxage=` argument when executing the migrator to limit the number of days to keep. For example: `maxage=90` will keep 90 days of historical data ignoring anything older.
 
 To see the command syntax click the **Show script** link in the wizard.
 :::

src/pages/docs/administration/upgrading/legacy/upgrading-from-octopus-2.6.5-2018.10lts/manual-upgrade.md

@@ -66,7 +66,7 @@ See the [Migrating data from Octopus 2.6.5 to 2018.10 LTS](/docs/administration/
 
 :::div{.hint}
 **Migration taking a long time?**
-By default we migrate everything from your backup including historical data. You can use the `maxage=` argument when executing the migrator to limit the number of days to keep. For example: `maxage=90` will keep 90 days of historical data ignoring anything older.
+By default, we migrate everything from your backup including historical data. You can use the `maxage=` argument when executing the migrator to limit the number of days to keep. For example: `maxage=90` will keep 90 days of historical data ignoring anything older.
 
 To see the command syntax click the **Show script** link in the wizard
 :::

src/pages/docs/administration/upgrading/legacy/upgrading-from-octopus-2.6.5-2018.10lts/migrating-data-from-octopus-2.6.5-2018.10lts.md

@@ -62,4 +62,4 @@ You will need to transfer them to the new server to `C:\Octopus\Packages`. Once
 
 ### Migrating historical data
 
-By default we migrate everything from your backup including all historical data. Learn about [minimizing migration time](/docs/administration/upgrading/legacy/upgrading-from-octopus-2.6.5-2018.10lts/minimize-migration-time).
+By default, we migrate everything from your backup including all historical data. Learn about [minimizing migration time](/docs/administration/upgrading/legacy/upgrading-from-octopus-2.6.5-2018.10lts/minimize-migration-time).

src/pages/docs/administration/upgrading/legacy/upgrading-from-octopus-2.6.5-2018.10lts/minimize-migration-time.md

@@ -26,7 +26,7 @@ The original complete backup can always be retained if it is required for audit
 
 ## Limit historical data
 
-By default we migrate everything from your backup including all historical data. You can use the `maxage=` argument when executing the migrator via the [command-line](/docs/octopus-rest-api/octopus.migrator.exe-command-line) to limit the number of days to keep. For example: `maxage=90` will keep 90 days of historical data ignoring anything older.
+By default, we migrate everything from your backup including all historical data. You can use the `maxage=` argument when executing the migrator via the [command-line](/docs/octopus-rest-api/octopus.migrator.exe-command-line) to limit the number of days to keep. For example: `maxage=90` will keep 90 days of historical data ignoring anything older.
 
 ## RAM
 

src/pages/docs/administration/upgrading/legacy/upgrading-from-octopus-2.6.5-2018.10lts/upgrade-with-a-new-server-instance.mdx

@@ -36,7 +36,7 @@ See the [Migrating data from Octopus 2.6.5 to 2018.10 LTS](/docs/administration/
 
 :::div{.hint}
 **Migration taking a long time?**
-By default we migrate everything from your backup including historical data. You can use the `maxage=` argument when executing the migrator to limit the number of days to keep. For example: `maxage=90` will keep 90 days of historical data ignoring anything older.
+By default, we migrate everything from your backup including historical data. You can use the `maxage=` argument when executing the migrator to limit the number of days to keep. For example: `maxage=90` will keep 90 days of historical data ignoring anything older.
 
 To see the command syntax click the **Show script** link in the wizard
 :::

src/pages/docs/argo-cd/instances/index.md

@@ -76,7 +76,7 @@ The terminal Kubernetes context must have enough permissions to create namespace
 :::
 
 :::div{.warning}
-By default the Octopus Argo CD Gateway will verify TLS certificates before making a connection, if your Argo CD instance is hosted with a self-signed TLS certificate or isn't using a TLS certificate at all the Gateway will fail to connect, this can be prevented by setting one of the following value on the Helm install. 
+By default, the Octopus Argo CD Gateway will verify TLS certificates before making a connection, if your Argo CD instance is hosted with a self-signed TLS certificate or isn't using a TLS certificate at all the Gateway will fail to connect, this can be prevented by setting one of the following value on the Helm install. 
 ```bash
 # For self-signed certificates - Disables TLS certificate verification
 gateway.argocd.insecure="true"

src/pages/docs/deployments/dotnet/netcore-webapp.md

@@ -52,7 +52,7 @@ When running under IIS, ensure the .NET CLR Version is set to `No Managed Code`.
 
 ## Antiforgery cookie {#DeployingASP.NETCoreWebApplications-AntiforgeryCookie}
 
-The `.AspNetCore.Antiforgery` cookie created by ASP.NET Core uses the application path to generate its hash. By default Octopus will deploy to a new path every time, which causes a new cookie to be set every deploy. This results in many unneeded cookies in the browser. See this [blog post](http://blog.novanet.no/a-pile-of-anti-forgery-cookies/) for more details. To change this behavior, set the Antiforgery token in your `startup.cs` like this:
+The `.AspNetCore.Antiforgery` cookie created by ASP.NET Core uses the application path to generate its hash. By default, Octopus will deploy to a new path every time, which causes a new cookie to be set every deploy. This results in many unneeded cookies in the browser. See this [blog post](http://blog.novanet.no/a-pile-of-anti-forgery-cookies/) for more details. To change this behavior, set the Antiforgery token in your `startup.cs` like this:
 
 ```csharp
 public void ConfigureServices(IServiceCollection services)

src/pages/docs/deployments/java/index.md

@@ -111,7 +111,7 @@ Here is an example of a `$CATALINA_HOME/conf/tomcat-users.xml` file that defines
 See the [Tomcat documentation](https://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html#Configuring_Manager_Application_Access) for more details on the groups used by the manager application.
 
 :::div{.hint}
-By default you can only upload files of around 50MB through the manager. This is often not large enough for big packages, so you can set a higher limit by editing the `webapps/manager/WEB-INF/web.xml` file. Inside you will find a `<multipart-config>` element whose child elements define the maximum file upload size.
+By default, you can only upload files of around 50MB through the manager. This is often not large enough for big packages, so you can set a higher limit by editing the `webapps/manager/WEB-INF/web.xml` file. Inside you will find a `<multipart-config>` element whose child elements define the maximum file upload size.
 
 This example sets the maximum file upload size to 250MB.
 
@@ -142,7 +142,7 @@ The `Deploy to Tomcat via Manager` step is used to deploy a package from the Oct
 | Package feed | Yes | | The feed to use to source the Java package from. |
 | Package ID | Yes | | The Java package to deploy. |
 | Context Path | No | Defaults to the deployment file name e.g. `myapplication.1.0.0`. | The context path that the application will be deployed to. Set this value to `/` to deploy to the root context. Set it to a value like `myapplication` to deploy to the `/myapplication` context. Nested contexts are also allowed, such as `myapplication/v1.0`.<br/><br/>Leading slashes are optional;  `/myapplication` and  `myapplication` will both deploy to the  `/myapplication` context path.  |
-| Deployment Version | No | By default no Tomcat version is assigned to the deployment. | An optional field that defines the Tomcat version that the deployment will be assigned when deployed. Versions are most often used with [Tomcat parallel deployments](https://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Parallel_deployment). The version can be set to match the version of the package from Octopus, can be set to a custom version, or the deployment can have no version.<br/><br/>It is common to use either the Octopus release number as the Tomcat version using the variable `#{Octopus.Release.Number}`, or to use the version number of the package with the variable `#{Octopus.Action.Package.NuGetPackageVersion}`.|
+| Deployment Version | No | By default, no Tomcat version is assigned to the deployment. | An optional field that defines the Tomcat version that the deployment will be assigned when deployed. Versions are most often used with [Tomcat parallel deployments](https://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Parallel_deployment). The version can be set to match the version of the package from Octopus, can be set to a custom version, or the deployment can have no version.<br/><br/>It is common to use either the Octopus release number as the Tomcat version using the variable `#{Octopus.Release.Number}`, or to use the version number of the package with the variable `#{Octopus.Action.Package.NuGetPackageVersion}`.|
 | Tomcat Manager URL | Yes | | This field defines the URL of the Tomcat manager application. This is relative to the target machine performing the deployment. When the Tentacle is on the same machine as the Tomcat instance, this URL will typically reference localhost i.e. `http://localhost:8080/manager`. |
 | Management User | Yes | | The user that is supplied when logging into the Tomcat manager API. Note that this user is required to be part of the `manager-script` group. See the [Tomcat documentation](https://tomcat.apache.org/tomcat-7.0-doc/manager-howto.html#Configuring_Manager_Application_Access) for more details on the groups used by the manager application.|
 | Management Password | Yes | | The password that is supplied when logging into the Tomcat manager API. |
@@ -158,7 +158,7 @@ You have two options for authenticating with WildFly and JBoss EAP servers.
 
 The easiest solution is to use [silent authentication](https://access.redhat.com/documentation/en-us/red_hat_jboss_enterprise_application_platform/7.1/html/how_to_configure_server_security/securing_the_server_and_its_interfaces#silent-auth). Silent authentication allows local users to log into the management API without supplying any credentials, and because Octopus typically executes a deployment from the same machine that is hosting the application server, it is treated as a local user.
 
-To take advantage of silent authentication, the user running the Octopus deployment on the target machine (i.e the user assigned to the Tentacle service in Windows or the SSH user in Linux or MacOS) must have access to the `auth`  directory inside the directory defined by the `jboss.server.temp.dir` variable. By default this directory will be located at `$JBOSS_HOME/standalone/tmp/auth` or `$JBOSS_HOME/domain/tmp/auth`.
+To take advantage of silent authentication, the user running the Octopus deployment on the target machine (i.e the user assigned to the Tentacle service in Windows or the SSH user in Linux or MacOS) must have access to the `auth`  directory inside the directory defined by the `jboss.server.temp.dir` variable. By default, this directory will be located at `$JBOSS_HOME/standalone/tmp/auth` or `$JBOSS_HOME/domain/tmp/auth`.
 
 The second option is to use the application server `add-user` script to create a new user, and use these credentials in the Octopus deployment steps.
 
@@ -301,8 +301,8 @@ The following steps can be used to deploy an application via a file copy to an a
 | -------- | -------- | ---------------- | ---------------- |
 | Package feed | Yes | | The feed to use to source the Java package from. |
 | Package ID | Yes | | The Java package to deploy. |
-| Explode  | No  |   | If selected, the package will be deployed extracted. Note that the package is always extracted as part of the deployment process, to allow features such as substituting variables in files. By default the package is re-created before deploying to the destination. If the `Explode` option is selected it remains extracted.  |
-| Custom Deploy Directory   | No  |   | By default the package will be deployed to the target's application directory. This options allows setting a custom deployment directory.   |
+| Explode  | No  |   | If selected, the package will be deployed extracted. Note that the package is always extracted as part of the deployment process, to allow features such as substituting variables in files. By default, the package is re-created before deploying to the destination. If the `Explode` option is selected it remains extracted.  |
+| Custom Deploy Directory   | No  |   | By default, the package will be deployed to the target's application directory. This options allows setting a custom deployment directory.   |
 | Deploy Directory | No | The package will be copied into the local Octopus Applications directory by default e.g. `C:\Octopus\Applications\Local\myapplication\0.0.1-SNAPSHOT_8\myapplication.0.0.1-SNAPSHOT.war` | The installed package will be copied to this location on the remote machine. |
 | Deployed Package File Name | No | The file will default to the original filename from the feed. | Defines the name of the file that is copied into the destination directory. |
 | Purge  | No  |   | If selected, all files in this location will be removed before the package is copied.  |