Docs - Spelling and Wording

CONTRIBUTING.md

@@ -55,12 +55,12 @@ Configure `myvalues.yaml` to suit your needs.
 # Be aware, the internet version is likely newer than the Iron Bank version
 ./hack/flux-install.sh
 
-# Apply a local version of the umbrella chart
+# Apply a local version of the Big Bang chart
 # NOTE: This is the alternative to deploying a HelmRelease and having flux manage it, we use a local copy to avoid having to commit every change
 helm upgrade -i bigbang chart -n bigbang --create-namespace -f myvalues.yaml
 
-# A convenience development script is provided to force fluxv2 to reconcile all helmreleases within the cluster insteading of waiting for the next polling interval.
-hack/sync.sh
+# It may take Big Bang up to 10 minutes to recognize your changes and start to deploy them.  This is based on the flux `interval` value set for polling.  You can force Big Bang to immediately check for changes by running the ./hack/sync.sh script.
+./hack/sync.sh
 ```
 
 For more extensive development, use the [Development Guide](docs/c_development.md).
@@ -73,7 +73,7 @@ Follow the [Big Bang documentation](./docs) for testing a full deployment of Big
 
 ## DNS
 
-To ease with local development, the TLD `bigbang.dev` has been purchased with the following CNAME record:
+To ease with local development, the TLD `bigbang.dev` is maintained by the Big Bang team with the CNAME record:
 
 `CNAME: *.bigbang.dev -> 127.0.0.1`
 

charter/GitOpsEngine.md

@@ -6,7 +6,7 @@ Big Bang will be deployed and managed with [Flux 2](https://github.com/fluxcd/fl
 
 ### Big Bang and Flux
 
-Big Bang is composed of several Open Source and licensed products.  [Helm](https://helm.sh/), as a member of the [CNCF](https://www.cncf.io/), is the de facto standard for packaging applications for Kubernetes.  As a result, several vendors support the release of their product **as helm charts** and have built their packaging and lifecycle management to expect to be the engine for driving that management.  As a result, Big Bang has adopted Helm as its internal deployment framework for BigBang packages and requires Helm to be treated as a first class citizen.
+Big Bang is composed of several Open Source and licensed products.  [Helm](https://helm.sh/), as a member of the [CNCF](https://www.cncf.io/), is the de facto standard for packaging applications for Kubernetes.  As a result, several vendors support the release of their product **as helm charts** and have built their packaging and lifecycle management to expect to be the engine for driving that management.  As a result, Big Bang has adopted Helm as its internal deployment framework for Big Bang packages and requires Helm to be treated as a first class citizen.
 
 The Flux2 Engine has native Helm support, meaning the controller deployed as part of "Flux 2" leverages the same Helm code as the CLI.
 

charter/GitlabLabels.md

@@ -13,11 +13,11 @@ The kind label shows the type of work that needs to be accomplished
 
 #### `kind::bug`
 
-Issues related to Bigbang not functioning as expected
+Issues related to Big Bang not functioning as expected
 
 #### `kind::chore`
 
-Catch all kind that captures administrative tasking for the BigBang project
+Catch all kind that captures administrative tasking for the Big Bang project
 
 #### `kind:ci`
 
@@ -29,7 +29,7 @@ Issues related to documentation
 
 #### `kind::feature`
 
-Creation of a new capability for BigBang and/or one of its packages
+Creation of a new capability for Big Bang and/or one of its packages
 
 #### `kind::enhancement`
 

docs/configuration.md

@@ -80,7 +80,7 @@ Registry credentials are used to pull images for Big Bang.  By default, it point
 
 ### `flux`
 
-Flux settings are used to setup the default continuos deployment configuration for Big Bang packages.
+Flux settings are used to setup the default continuous deployment configuration for Big Bang packages.
 
 | Key | Description | Type | Default |
 |--|--|--|--|

docs/developer/ci-workflow.md

@@ -111,7 +111,7 @@ More information on the full set of infrastructure tests are below:
 
 For each cloud, a BigBang owned network will be created that conform with the appropriate set of tests about to be ran.  For example, to validate that Big Bang deploys in a connected environment on AWS, a VPC, subnets, route tables, etc... are created, and the outputs are made available through terraform's remote `data` source.
 
-At this time the infrastructue testing pipeline is only utilizing internet-connect AWS govcloud.
+At this time the infrastructure testing pipeline is only utilizing internet-connect AWS govcloud.
 
 #### Cluster Creation
 
@@ -119,7 +119,7 @@ The infrastructure pipeline is currently setup to standup an `rke2` cluster by d
 
 An `rke2` cluster is created that leverages the upstream [terraform modules](https://repo1.dso.mil/platform-one/distros/rancher-federal/rke2/rke2-aws-terraform)
 
-It is a hard requriement at this stage that every cluster outputs an admin scoped `kubeconfig` as a gitlab ci artifact.  This artifact will be leveraged in the following stages for interacting with the created cluster.
+It is a hard requirement at this stage that every cluster outputs an admin scoped `kubeconfig` as a gitlab ci artifact.  This artifact will be leveraged in the following stages for interacting with the created cluster.
 
 #### Big Bang Installation
 

docs/developer/develop-package.md

@@ -60,7 +60,7 @@ Package is the term we use for an application that has been prepared to be deplo
 
 1. Add a VirtualService if your application has a back-end API or a front-end GUI. Create the VirtualService in the sub-directory  "chart/templates/bigbang/VirtualService.yaml". You will need to manually create the "bigbang" directory. It is convenient to copy VirtualService code from one of the other Packages and then modify it. You should be able to load the application in your browser if all the configuration is correct.
 
-1. Add NetworkPolices templates in the sub-directory "chart/templates/bigbang/networkpolicies/*.yaml". The intent is to lock down all ingress and egress traffic except for what is required for the application to function properly. Start with a deny-all policy and then add additionl policies to open traffic as needed. Refer to the other Packages code for examples. The [Gitlab package](https://repo1.dso.mil/platform-one/big-bang/apps/developer-tools/gitlab/-/tree/main/chart/templates/bigbang/networkpolicies) is a good/complete example.
+1. Add NetworkPolices templates in the sub-directory "chart/templates/bigbang/networkpolicies/*.yaml". The intent is to lock down all ingress and egress traffic except for what is required for the application to function properly. Start with a deny-all policy and then add additional policies to open traffic as needed. Refer to the other Packages code for examples. The [Gitlab package](https://repo1.dso.mil/platform-one/big-bang/apps/developer-tools/gitlab/-/tree/main/chart/templates/bigbang/networkpolicies) is a good/complete example.
 
 1. Add a continuous integration (CI) pipeline to the Package. A Package should be able to be deployed by itself, independently from the BigBang chart. The Package pipeline takes advantage of this to run a Package pipeline test. The package testing is done with a helm test library. Reference the [pipeline documentation](https://repo1.dso.mil/platform-one/big-bang/pipeline-templates/pipeline-templates#using-the-infrastructure-in-your-package-ci-gitlab-pipeline) for how to create a pipeline and also [detailed instructions](https://repo1.dso.mil/platform-one/big-bang/apps/library-charts/gluon/-/blob/master/docs/bb-tests.md) in the gluon library. Instructions are not repeated here.