Updates user guide page names and links

website/docs/cluster-management/profiles.mdx

@@ -65,7 +65,7 @@ When multiple Profiles are specified in an API call, with layers in the API requ
 
 The scope of the `dependsOn` calculation is limited to the set of Profiles in the API call.
 
-If only one chart is being installed, obviously no `dependsOn` is configured.
+If only one chart is being installed, no `dependsOn` is configured.
 
 If several charts are installed in the same layer, then the preceeding layer charts will be configured to depend on _all_ the charts in the succeeding layer.
 ```

website/docs/configuration/tls.md

@@ -2,9 +2,9 @@
 title: TLS and Certificates
 ---
 
-## TLS configuration
+## TLS Configuration
 
-By default the dashboard will listen on 0.0.0.0:9001 with TLS disabled and
+By default Weave GitOps Dashboard listens on 0.0.0.0:9001 with TLS disabled and
 without exposing any external connection.
 
 Exposing services without TLS if not recommended. Without a certificate, a user

website/docs/enterprise/getting-started/releases-enterprise.mdx

@@ -597,7 +597,7 @@ config
 - Weave GitOps default admin user can now “read” all objects. Why is this important? As users are trying out Weave GitOps they will most likely try it out with some of their favorite Cloud Native tools such as Crossplane, Tekton, Istio, etc. This enables them to see all of those resources and explore the full power of Weave GitOps. We still do not recommend this user for “production-use” cases, and customers should always be pushed towards implementing OIDC with scoped roles.
 
 #### Pipelines - adding Pipelines through Templates
-- From the Pipelines view you can add new Pipelines in a way which leverages GitOpsTemplates, additionally - to help users configure these, we’ve provided [documentation](../../pipelines/pipeline-templates.mdx) which has some samples.
+- From the Pipelines view you can add new Pipelines in a way which leverages GitOpsTemplates, additionally - to help users configure these, we’ve provided [documentation](../../pipelines/pipelines-templates.mdx) which has some samples.
 
 #### Support for multiple Flux instances on a single cluster
 - Support for running multiple flux instances in different namespaces on a single cluster for resource isolation.

website/docs/gitops-run/get-started.mdx → website/docs/gitops-run/gitops-run-get-started.mdx

@@ -1,5 +1,5 @@
 ---
-title: Tutorial
+title: Getting Started
 hide_title: true
 ---
 
@@ -25,7 +25,7 @@ cluster.
 - This guide uses [kubectl](https://kubernetes.io/docs/tasks/tools/#kubectl) for demonstrations, but it is not required to use GitOps Run
 - The [Flux CLI](https://fluxcd.io/flux/installation/) is the quickest way to generate resource definitions, but the files can also be created manually
 
-## Create a local Kubernetes cluster
+## Create a Local Kubernetes Cluster
 
 To get started with GitOps Run, you need a Kubernetes cluster. There
 are many tools to set up a local cluster for test and development
@@ -89,7 +89,7 @@ Then, for any `gitops beta run` command in this guide, you'll have to add the fl
 
 Before you continue, make sure `kubectl get nodes` returns a node which is `Ready`.
 
-## Create a GitOps repository
+## Create a GitOps Repository
 
 You need to set up a Git repository to put your GitOps manifests
 in. Any Git repository will do, for example create a new
@@ -132,7 +132,7 @@ The username is `admin` and the password will be the one you set above.
 In your dashboard you will be able to see what is in your cluster, including
 the resources that GitOps Run is operating.
 
-## Start modifying your deploment
+## Start Modifying Your Deployment
 
 In your local GitOps repo, you will see that GitOps Run has created a new
 directory called `podinfo`. Inside there is a single, mostly empty, `kustomization.yaml`.
@@ -250,7 +250,7 @@ reconciled, and when they're Ready you will be able to see podinfo
 [here](http://localhost:9898).
 
 
-## Update your app
+## Update Your App
 
 Now that GitOps Run is continuously watching and reconciling your
 local files onto your cluster, we can start modifying the resources.
@@ -289,7 +289,7 @@ spec:
 When you hit save, you'll see GitOps Run upload new files, and once
 it's reconciled the `podinfo` background will have been changed to a bright red.
 
-## Next steps: GitOps Mode
+## Next Steps: GitOps Mode
 
 Now that we've used this interactive environment to set up the
 resources we want, we can switch over to full GitOps mode, where Flux

website/docs/gitops-run/overview.mdx → website/docs/gitops-run/gitops-run-overview.mdx

@@ -1,5 +1,5 @@
 ---
-title: Overview
+title: GitOps Run Overview
 hide_title: true
 ---
 
@@ -10,12 +10,12 @@ import TabItem from '@theme/TabItem';
 
 ## Introduction
 
-GitOps is a powerful mechanism for creating consistent environments and having
-multiple clusters stay in sync. If you build out your infrastructure correctly
+GitOps is a powerful mechanism for creating consistent environments and keeping
+multiple clusters in sync. If you build out your infrastructure correctly,
 you get predictable behaviours for your teams and you can have new environments
 up and running quickly.
 
-However, GitOps can be challenging for the everyday developer
+However, GitOps can be challenging for developers
 to work with and it can create some friction, especially for developers who are
 less familiar with Kubernetes or Flux.
 
@@ -29,7 +29,7 @@ get started with GitOps:
 <iframe width="560" height="315" src="https://www.youtube.com/embed/2TJz7RhDtAc" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
 
 ### Additional Benefits
-* No need to run `kubectl`, `helm`, `kustomize`, or `flux` CLI commands.  Just create the manifests and we'll put them on the cluster for you.
+* No need to run `kubectl`, `helm`, `kustomize`, or `flux` CLI commands. Just create the manifests and we'll put them on the cluster for you.
 * Reduces the cycle time when configuring your cluster.  With normal GitOps
   there is a lot of commit/push/reconcile workflows that can be frustrating.
   This skips that and you can test your changes directly before committing and

website/docs/gitops-templates/quickstart-templates.mdx

@@ -67,7 +67,7 @@ templates are now available for use:
 
 ## Available Templates
 
-The following [pipeline](../pipelines/pipeline-templates.mdx) templates have
+The following [pipeline](../pipelines/pipelines-templates.mdx) templates have
 been made available on your Weave GitOps Enterprise instance:
 
 - `pipeline-view`: A template to create a sample pipeline to visualize a

website/docs/gitopssets/gitopssets-api-reference.mdx

@@ -0,0 +1,10 @@
+---
+title: API reference
+hide_title: true
+---
+
+import GeneratedAPI from './_api.mdx';
+import apiToc from './_api-toc.json';
+export const toc = apiToc;
+
+<GeneratedAPI />

website/docs/gitopssets/installation.mdx → website/docs/gitopssets/gitopssets-installation.mdx

@@ -9,16 +9,14 @@ import TierLabel from "../_components/TierLabel";
 
 The gitopssets-controller can be installed in two ways:
 
-- As part of the Weave Gitops Enterprise installation. (installed by default)
+- As part of the Weave GitOps Enterprise installation. (installed by default)
 - As a standalone installation using a Helm chart.
 
-The standalone installation can be useful for leaf clusters that don't have Weave Gitops Enterprise installed.
+The standalone installation can be useful for leaf clusters that don't have Weave GitOps Enterprise installed.
 
 ## Prerequisites
 
-Before installing the gitopssets-controller, ensure that the following is installed:
-
-- flux
+Before installing the gitopssets-controller, ensure that you've installed [Flux](https://github.com/fluxcd/flux2).
 
 ## Installing the gitopssets-controller
 
@@ -60,4 +58,4 @@ spec:
     crds: CreateReplace
 ```
 
-After adding the Namespace, HelmRepository and HelmRelease to a git repository synced by flux, commit the changes to complete the installation process.
+After adding the Namespace, HelmRepository and HelmRelease to a Git repository synced by Flux, commit the changes to complete the installation process.

website/docs/gitopssets/intro.mdx → website/docs/gitopssets/gitopssets-intro.mdx

@@ -22,21 +22,21 @@ fine-grained control over how the generated resources are applied.
 
 GitOpsSets enable Platform Operators to have a single definition for an application for multiple environments and a fleet of clusters. A single definition can be used to generate the environment and cluster-specific configuration.
 
-As an example, we can take an application that needs to be deployed to various environments (Dev, Test, Prod) built by a fleet of clusters. Each of those environments + clusters requires a specialized configuration powering the same Application. With GitOpsSets and the generators you just declare the template, you want to use, the selector that will match the cluster of the inventory, and where to get the special configuration. 
+As an example, we can take an application that needs to be deployed to various environments (Dev, Test, Prod) built by a fleet of clusters. Each of those environments + clusters requires a specialized configuration powering the same Application. With GitOpsSets and the generators you just declare the template you want to use, the selector that will match the cluster of the inventory, and where to get the special configuration. 
 
-GitOpsSets will create out of the single resource all the objects and Flux primitives that are required to successfully deploy this application. An operation that required the editing of 100s files can be done now with a single command. 
+GitOpsSets will create out of the single resource all the objects and Flux primitives that are required to successfully deploy this application. An operation that required the editing of hundreds of files can now be done with a single command. 
 
 **The initial generators that are coming with the preview release are:**
 
-- [List Generator](./guide.mdx#list-generator): The simplest generator. Provide a list of Key/Value pairs that you want to feed the template with.
-- [Git Generator](./guide.mdx#gitrepository-generator): Enable to extract a set of files (environment-specific configurations) from a Flux GitRepository, and make the contents of these available to the templates, this would let you have config in *app-dev.json*, *app-staging.json* and *app-production.json* for example, and the contents of these would be available to the templates.
-- [Matrix Generator](./guide.mdx#matrix-generator): Combine slices of generators into the desired compounded input.
-- [Pull request Generator](./guide.mdx#pullrequests-generator): Automatically discover open pull requests within a repository to generate a new deployment.
-- [API Client Generator](./guide.mdx#apiclient-generator): Poll an HTTP endpoint and parse the result as the generated values.
+- [List Generator](templating-from-generators.mdx#list-generator): The simplest generator. Provide a list of Key/Value pairs that you want to feed the template with.
+- [Git Generator](templating-from-generators.mdx#gitrepository-generator): Enables you to extract a set of files (environment-specific configurations) from a Flux GitRepository and make their contents available to the templates. This lets you have config in *app-dev.json*, *app-staging.json*, and *app-production.json*, for example.
+- [Matrix Generator](templating-from-generators.mdx#matrix-generator): Combine slices of generators into the desired compounded input.
+- [Pull request Generator](templating-from-generators.mdx#pullrequests-generator): Automatically discover open pull requests within a repository to generate a new deployment.
+- [API Client Generator](templating-from-generators.mdx#apiclient-generator): Poll an HTTP endpoint and parse the result as the generated values.
 
 
-## Use cases
+## Use Cases
 
 - Single application definition for different environments (EU-West, North America, Germany)
 - Deployment of a single definition across fleet of clusters matching any cluster based on a label (Production) 
-- Separation of concerns between teams (Teams managing different artifacts flowing into a single definition via generators)
+- Separation of concerns between teams (teams managing different artifacts flowing into a single definition via generators)

website/docs/gitopssets/releases.mdx → website/docs/gitopssets/gitopssets-releases.mdx

@@ -10,13 +10,13 @@ import TierLabel from "../_components/TierLabel";
 ## v0.8.0
 2023-04-13
 
-- Add events recording to gitopssets
+- Add events recording to GitOpsSets
 - Fix updating of ConfigMaps
 
 ## v0.7.0
 2023-03-30
 
-- Implement custom delimiters.
+- Implement custom delimiters
 
 ## v0.6.1
 2023-03-20

website/docs/pipelines/authorization.mdx

@@ -10,15 +10,8 @@ import AlphaWarning from "../_components/_alpha_warning.mdx";
 
 <AlphaWarning/>
 
-This section provides a recommended way to configure RBAC in the context of pipelines. It is oriented to the journey
-that you expect your users to have.
-
-## View pipelines
-
-In order to view pipelines, users would need to have read access to the `pipeline` resource and the underlying `application` resources.
-
-An example of configuration to achieve this purpose could be seen below with `pipeline-reader` role and `search-pipeline-reader`
-role-binding to allow a group `search-developer` to access pipeline resources within `search` namespace.
+To view pipelines, users need read access to the `pipeline` resource and the underlying `application` resources. This sample configuration shows a recommended way to configure RBAC to provide such access. The `pipeline-reader` role and the `search-pipeline-reader`
+role-binding allow a group `search-developer` to access pipeline resources within the `search` namespace.
 
 ```yaml
 apiVersion: rbac.authorization.k8s.io/v1