Correctly hyphenate (or join) words

dictionary-octopus.txt

@@ -9,6 +9,8 @@ ALLUSERSPROFILE
 anglin
 anotherdir
 Antiforgery
+antipattern
+antipatterns
 apikey
 apikeys
 appcmd
@@ -33,8 +35,10 @@ australiaeast
 australiasoutheast
 Authentik
 auths
+autoconfigured
 autodeployoverride
 autologin
+autopopulate
 awsaccount
 azureaccount
 azureactivedirectory
@@ -286,7 +290,9 @@ msiexec
 mssqldb
 MSSQLSERVER
 MTTR
+multifactor
 Multipath
+multistep
 myagent
 myapplication
 Myatt
@@ -507,6 +513,7 @@ storyblok
 strconv
 struct
 stylesheet
+subcomponent
 subcontext
 sunsetting
 swaggerui

src/pages/docs/administration/spaces/index.mdx

@@ -130,7 +130,7 @@ When you log into the Octopus Web Portal, the first item on the navigation menu
 
 ## System scoped or space scoped \{#system-scope-space-scoped}
 
-There is a hard barrier between spaces, so, for instance, a deployment target configured for Space-A isn't available to projects in Space-B. However, there are some things that aren't scoped to a space, and are available system wide.
+There is a hard barrier between spaces, so, for instance, a deployment target configured for Space-A isn't available to projects in Space-B. However, there are some things that aren't scoped to a space, and are available system-wide.
 
 The following table shows which Octopus resources are space-scoped, system-scoped, or scoped to both.
 
@@ -157,6 +157,6 @@ If a resource isn't listed below, then it's space-scoped.
 
 ## Automation changes to be aware of \{#automation-changes}
 
-As always, using our client libraries offer the best chance of a successful upgrade for your existing automation, and our latest release of Octopus Client has all the changes required to inter-operate with any version of Octopus, as do most of our plugins for other build systems. However, due to the depth and breadth of the changes required to make spaces a reality, we weren't able to maintain backwards compatibility for the REST API in all cases.
+As always, using our client libraries offer the best chance of a successful upgrade for your existing automation, and our latest release of Octopus Client has all the changes required to interoperate with any version of Octopus, as do most of our plugins for other build systems. However, due to the depth and breadth of the changes required to make spaces a reality, we weren't able to maintain backwards compatibility for the REST API in all cases.
 
 Please refer to [release notes](https://octopus.com/downloads/compare?from=2018.12.1&to=2019.1.0) for a complete list of breaking changes.

src/pages/docs/best-practices/deployments/environments-and-deployment-targets-and-roles.md

@@ -84,7 +84,7 @@ Our recommendations for environments are:
 - If you have between one and five data centers (including cloud regions), it's okay to have an environment per data center. For example, **Production - AU** for a data center in Australia and **Production - Central US** for the Azure Central US region. If you have more than five data centers, consider [tenants](/docs/tenants) where each data center is a tenant.
 - It's okay to have team-specific environments, similar to data center environments. Although if you have more than five or six teams, consider [tenants](//docs/tenants/) where each team is a tenant.
 
-Anti-patterns to avoid are:
+Antipatterns to avoid are:
 
 - Project names in your environments. An environment name of **QA - OctoPetShop** indicates you need to either have more specific target tags on your deployment targets or you need to leverage spaces to isolate that application. Project-specific environments are a good indicator to consider [spaces](/docs/administration/spaces).
 - Branch names in your environment names. Consider using temporary [tenants](/docs/tenants) for your branch names or storing your branch name in a pre-release tag in the release version.

src/pages/docs/best-practices/deployments/lifecycles-and-environments.md

@@ -42,7 +42,7 @@ Two lifecycles allow you to have your standard workflow, where all the feature b
 We **_never_** recommend having a lifecycle with only **production**.  Any deployment to **production** must deploy to at least one other environment to verify the fix.  Skipping straight to **production**, especially during an emergency, will make a bad situation worse.
 
 :::div{.hint}
-A lifecycle with a single phase is an anti-pattern.  We typically see this when users strictly adhere to the [git flow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) branching strategy.  If you create a new build, that build should be deployed to at least one environment to ensure it will work in **production**.  
+A lifecycle with a single phase is an anti-pattern. We typically see this when users strictly adhere to the [git flow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) branching strategy. If you create a new build, that build should be deployed to at least one environment to ensure it will work in **production**.  
 :::
 
 ## Production approval

src/pages/docs/best-practices/deployments/projects-and-project-groups.md

@@ -32,9 +32,9 @@ If you want to have a project per component, you need to ensure each component i
 Previous versions of this guide recommended having a project per component.  Octopus Deploy now includes new features, including ITSM integration, Config as Code, and more options for variable run conditions.  There is also a logistical overhead with a project per component.  That recommendation was made in 2021.  At that time, a project per component made sense.  It is no longer applicable with the 2023 version of Octopus Deploy.
 :::
 
-## Anti-patterns to avoid
+## Antipatterns to avoid
 
-A project should deploy all the coupled components of an application (WebUI, WebAPI, Service, Database).  Some common anti-patterns we've seen you should avoid are:
+A project should deploy all the coupled components of an application (WebUI, WebAPI, Service, Database).  Some common antipatterns we've seen you should avoid are:
 
 - A project per component in an application.  If the components are referenced in the same "solution" or built in the same build configuration, they need to be deployed together.
 - A project per application, per environment, such as `OctoPetShop_Dev`, `OctoPetShop_Test`, and so on.  That is impossible to maintain and track versions.

src/pages/docs/best-practices/deployments/variables.md

@@ -87,7 +87,7 @@ Octopus Deploy can set an environment variable or configuration value during dep
 A common scenario we've talked to customers about is restricting variable edit access to specific environments.  For example, a developer can edit any variables scoped to **development** and **test** environments, but not **staging** or **production** environments.  On paper this makes sense, in practice this causes messy handovers and claims of "it worked on my machine."  The developers working on the application know all the various settings and variables required for their application to work.
 
 Our recommendations for variable edit permissions are:
-- Variable edit permissions should be all or nothing, either a person can edit variables, or they cannot.  Don't scope permissions to environments.  Anyone responsible for the application should have permission to update variables (developers, lead developers, DB developers, etc.) along with operations (DBAs, web admins, sys admins) who can create and update service accounts and passwords.  
+- Variable edit permissions should be all or nothing, either a person can edit variables, or they cannot.  Don't scope permissions to environments.  Anyone responsible for the application should have permission to update variables (developers, lead developers, DB developers, etc.) along with operations (DBAs, web admins, sysadmins) who can create and update service accounts and passwords.  
 - Variable Sets can be shared across multiple projects.  Limit who can edit variable set variables to more experienced Octopus Deploy users, or people who understand "with great power comes great responsibility."  Typically, we see senior or lead developers along with operations people who have these permissions.  If you want to isolate an application, consider using [spaces](/docs/administration/spaces).
 - Leverage [sensitive variables](/docs/projects/variables/sensitive-variables) to encrypt and hide sensitive values such as usernames and passwords.  Sensitive variables are write-only in the Octopus UI and Octopus API.  
 - Use [composite variables](/docs/projects/variables/variable-substitutions/#binding-variables) to combine sensitive and non-sensitive values.  A typical use case is database connection strings.  Each language has a specific syntax.  In the screenshot below `Project.Database.ConnectionString` is the composite variable, with the username and password referenced by the composite variable, but they are separate sensitive variables. 

src/pages/docs/best-practices/octopus-administration/partition-octopus-with-spaces.md

@@ -34,9 +34,9 @@ Internally we have opted for a space per application suite.
 - Integrations Space (build servers, issue trackers, etc.)
 - And so on
 
-## Anti-patterns
+## Antipatterns
 
-We've also found several anti-patterns with the Spaces feature you should avoid.
+We've also found several antipatterns with the Spaces feature you should avoid.
 
 - A space per team (Team A Space, Team B space, etc.).  In larger corporations, applications typically move between teams; a space per team would require you to move projects between spaces. The project export/import makes this easier, but it doesn't copy everything.  You'd need to move packages, deployment targets, and workers.  Release and Deployment history is not moved either.
 - A space per environment (Development Space, Production Space, Test Space, etc.).  Spaces were not designed, nor do they support this scenario.  You would need a way to keep the deployment process in sync across multiple spaces.  Such a syncing process is [difficult to create and maintain](/docs/administration/sync-instances).

src/pages/docs/deployments/aws/ecs/index.md

@@ -159,7 +159,7 @@ Specify additional options for the running container, such as `Entry Point`, `Wo
 
 In this section, you can specify mount points for the running container. Mount points can refer to the volumes specified in the **Volumes** section of the ECS step.
 
-For container logging the step can either auto-configure CloudWatch logs, or you can provide logging configuration manually. If you choose to have CloudWatch logs auto-configured, please ensure that you have specified a Task Execution Role ARN for this step. 
+For container logging the step can either autoconfigure CloudWatch logs, or you can provide logging configuration manually. If you choose to have CloudWatch logs autoconfigured, please ensure that you have specified a Task Execution Role ARN for this step. 
 
 :::figure
 ![ECS Step Container Definition Storage and Logging](/docs/img/deployments/aws/ecs/images/ecs-container-storage-and-logging.png)

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

@@ -14,7 +14,7 @@ Octopus Deploy includes dedicated integration with Amazon Web Services (AWS) to
 - [Deploy an AWS CloudFormation Template](/docs/deployments/aws/cloudformation) allows you to create or update a CloudFormation stack. It offers more flexibility than the UI step.
 - [Delete an AWS CloudFormation stack](/docs/deployments/aws/removecloudformation) deletes existing CloudFormation stacks.
 - [Upload a package to an AWS S3 bucket](/docs/deployments/aws/s3) allows you to upload files and packages to S3 buckets.
-- [Run an AWS CLI Script](/docs/deployments/custom-scripts/aws-cli-scripts) runs a custom script with AWS credentials pre-loaded.
+- [Run an AWS CLI Script](/docs/deployments/custom-scripts/aws-cli-scripts) runs a custom script with AWS credentials preloaded.
 
 :::div{.hint}
 **Where do AWS Steps execute?**

src/pages/docs/deployments/azure/deploying-a-package-to-an-azure-web-app/using-deployment-slots-with-azure-web-apps.md

@@ -21,7 +21,7 @@ Deployment Slots are only available to Azure Web Apps running in Standard or Pre
 ## Walk-Through {#UsingDeploymentSlotsWithAzureWebApps-Walk-Through}
 
 Here we will give an example of how to setup a Blue-Green deployment for an Azure Web App using Deployment Slots.
-The scripts below assume you have a variable named 'WebSite' that contains the name of your Azure Web Site and 'ResourceGroup' that contains the Azure Resource Group Name.
+The scripts below assume you have a variable named 'WebSite' that contains the name of your Azure Web App and 'ResourceGroup' that contains the Azure Resource Group Name.
 
 ### Step 1: Create an Azure Web App Deployment Target
 

src/pages/docs/deployments/certificates/wildfly-certificate-import.md

@@ -66,7 +66,7 @@ The `KeyStore alias` field defines a custom alias under which the certificate an
 
 ## Deploying a certificate to a domain
 
-Domains can be used to distribute the configuration required to access a KeyStore, but can not be used to distribute the KeyStore files themselves. Since each slave in the domain needs to have access to the KeyStore file, configuring certificates is therefor a two step process:
+Domains can be used to distribute the configuration required to access a KeyStore, but can not be used to distribute the KeyStore files themselves. Since each slave in the domain needs to have access to the KeyStore file, configuring certificates is therefor a two-step process:
 
 1. Deploying a KeyStore file to all slave instances.
 2. Configuring the profiles managed by the domain controller to reference the KeyStore files.

src/pages/docs/deployments/custom-scripts/run-a-script-step.md

@@ -141,7 +141,7 @@ Write-Host "ExtractedPath: $ExtractedPath"
 
 #### Package files {#referencing-packages-package-files}
 
-If the package reference was configured to be extracted, then the package will be extracted to a sub-directory in the working-directory of the script. This directory will be named the same as the package-reference.  For example, a package reference named `Acme` would be extracted to directory similar to `C:\Octopus\Work\20180821060923-7117-31\Acme` (this is obviously a Windows directory; a script executing on a Linux target may have a path such as `/home/ubuntu/.octopus/Work/20180821062148-7121-35/Acme`).
+If the package reference was configured to be extracted, then the package will be extracted to a subdirectory in the working-directory of the script. This directory will be named the same as the package-reference.  For example, a package reference named `Acme` would be extracted to directory similar to `C:\Octopus\Work\20180821060923-7117-31\Acme` (this is obviously a Windows directory; a script executing on a Linux target may have a path such as `/home/ubuntu/.octopus/Work/20180821062148-7121-35/Acme`).
 
 If the package reference was _not_ configured to be extracted, then the un-extracted package file will be placed in the working directory. The file will be named as the package reference name, with the same extension as the original package file.  For example, for a package reference named `Acme`, which resolved to a zip package, the file would be copied to a path such as `C:\Octopus\Work\20180821060923-7117-31\Acme.zip` (for Linux: `/home/ubuntu/.octopus/Work/20180821062148-7121-35/Acme.zip`).
 

src/pages/docs/deployments/custom-scripts/scripts-in-packages/index.md

@@ -19,7 +19,7 @@ You can add any of the following script files in any of the scripting languages
 - `PostDeploy.<ext>`
 - `DeployFailed.<ext>`
 
-Where `<ext>` is the appropriate extension for your scripting language of choice. Also note these file names will be case sensitive on certain operating systems.
+Where `<ext>` is the appropriate extension for your scripting language of choice. Also note these file names will be case-sensitive on certain operating systems.
 
 Octopus will detect these scripts and invoke them at the appropriate time during the step. Which file you use depends on when you need your custom activity to run; see the section on [what order are conventions run in](/docs/deployments/packages/package-deployment-feature-ordering/) for details. Your scripts can do anything your scripting language supports, as well as setting [output variables](/docs/projects/variables/output-variables/) and [collecting artifacts](/docs/projects/deployment-process/artifacts).
 

src/pages/docs/deployments/databases/common-patterns/index.md

@@ -18,7 +18,7 @@ Learn more about [manual approvals](/docs/deployments/databases/common-patterns/
 
 ## Automatic approvals
 
-Manual approvals are a great starting point, when the number of projects that require approval is low.  The number of notifications will exponentially grow as time goes on.  It is common for the frequency of deployments to go from once a quarter to once a week, and it is important for the signal to noise ratio to remain high.  Having a DBA spend time approving minor stored procedure changes is not productive.  This section shows you how to take the manual approval process and add logic for automated approvals.
+Manual approvals are a great starting point, when the number of projects that require approval is low.  The number of notifications will exponentially grow as time goes on.  It is common for the frequency of deployments to go from once a quarter to once a week, and it is important for the signal-to-noise ratio to remain high.  Having a DBA spend time approving minor stored procedure changes is not productive.  This section shows you how to take the manual approval process and add logic for automated approvals.
 
 Learn more about [automatic approvals](/docs/deployments/databases/common-patterns/automatic-approvals).
 

src/pages/docs/deployments/databases/common-patterns/manual-approvals.md

@@ -108,7 +108,7 @@ That sample uses `Notification.Base.Url` instead of the system variable `Octopus
 
 A separate variable, such as `Notification.Base.Url` provides a lot more options.  For example, you can set that to a publicly exposed URL the approvers can use to approve changes from home.  
 
-## Keeping the signal to noise ratio low
+## Keeping the signal-to-noise ratio low
 
 Imagine a message is sent to the team for every deployment to `Development` and `Test`.  At first, that is a good idea.  But as time goes on, the number of deployments per day will increase.  They are now deploying 20 times a day to each environment.  Those notifications went from being useful to being noise.  
 

src/pages/docs/deployments/databases/mysql-flyway/index.md

@@ -24,7 +24,7 @@ The Flyway download comes with everything it needs to execute, including a versi
 :::
 
 :::div{.hint}
-If Flyway doesn't find Java installed on the machine (detected by the presence of the JAVA_HOME environment variable), it will fall back to the included JRE.  The included version of the JRE has the .exe and .dll files located within a `bin` sub-directory.  It is often the case that source control will ignore any directory with the name `bin`, so be careful when including a Flyway project and you need the included JRE.
+If Flyway doesn't find Java installed on the machine (detected by the presence of the JAVA_HOME environment variable), it will fall back to the included JRE.  The included version of the JRE has the .exe and .dll files located within a `bin` subdirectory.  It is often the case that source control will ignore any directory with the name `bin`, so be careful when including a Flyway project and you need the included JRE.
 :::
 
 ## Add scripts to your Flyway project

src/pages/docs/deployments/databases/sql-server/redgate.md

@@ -228,7 +228,7 @@ In Octopus Deploy, that process will look like the following screenshot.  This e
 ![Deployment process overview in Octopus Deploy](/docs/img/deployments/databases/sql-server/images/redgate-octopus-deploy-deployment-process-overview.png)
 :::
 
-Before adding steps to the process, a number of variables need to be created.  We recommend namespacing the variables using [ProjectName].[Component].[Sub-component].
+Before adding steps to the process, a number of variables need to be created.  We recommend namespacing the variables using [ProjectName].[Component].[Subcomponent].
 
 - **Project.Database.Name**: The name of the database on the SQL Server to deploy to.
 - **Project.Database.Password**: The password of the user account who has permissions to deploy.  This is not required if you're using integrated security.

src/pages/docs/deployments/packages/stage-package-uploads.md

@@ -24,7 +24,7 @@ When the deployment runs, Octopus will insert an "Acquire" step to execute as pa
 - Run another script
 - Deploy package C
 
-During the acquire packages stage, Octopus will upload all NuGet packages used in the deployment to all servers. We do this because package uploads can be time consuming, so we want to minimize the downtime between installing packages A and B in this example.
+During the acquire packages stage, Octopus will upload all NuGet packages used in the deployment to all servers. We do this because package uploads can be time-consuming, so we want to minimize the downtime between installing packages A and B in this example.
 
 If you have a small window for downtime, you might like to **pre-stage** your packages. An easy way to do this is to use a [manual intervention step](/docs/projects/built-in-step-templates/manual-intervention-and-approvals). The deployment process would become: