Work with developer to install the product using the install connnected doc and the uninstall doc. 
https://github.com/stolostron/rhacm-docs/blob/2.11_stage/install/install_overview.adoc

Notes:

• Internally we started with a cluster from the cluster pool. A user would have one or check out one. 
• The release channel is the version used for the subscription.
• The disconnected would not be tested as part of this effort.
• We have too much language to say you need `oc`. We don't need to say you need the internet when the title states "connected."
• We don't need to say you need ocp when that is already in the prereqs.
• We need to know more about dedicate section.
• We also are not sure about what is used more often, the ui or CLI.
• OCM is default in the UI, in CLI doc we presume users have opinions about what name they want to use.
• UI advanced config is a bit confusing and things are deprecated. We also do not link to the adv config in the doc, which is different.
• MCE is automatically installed.
• Install is actually first installing the operator and then the objects. Unistall is a two part task in reverse.
• We need an example of approval and update release strategy for install.
• The following goes around the button to install:
  • Create the MultiClusterHub custom resource. In the {ocp-short} console navigation, select Installed Operators > Advanced Cluster Management for Kubernetes. .. Select the MultiClusterHub tab. .. Select Create MultiClusterHub. .. Update the default values in the YAML file. See options in the MultiClusterHub advanced configuration section of the documentation.

• Make clearer why user would do this:
  Note: For installing the {product-title-short} hub cluster on infrastructure nodes, the see the xref:../install/install_connected.adoc#infra-olm-sub-add-config[\{olm} Subscription additional configuration] section.
   
   

• Check in to this: 
  If you are reinstalling {product-title-short} and the pods do not start, see link:../troubleshooting/trouble_reinstall.adoc#troubleshooting-reinstallation-failure[Troubleshooting reinstallation failure] for steps to work around this problem.
   
• Confusing and wordy:

The installation also creates a namespace called `local-cluster` that is reserved for the {product-title-short} hub cluster when it is managed by itself. There cannot be an existing namespace called `local-cluster`. For security reasons, do not release access to the `local-cluster` namespace to any user who does not already have `cluster-administrator` access.
 

• Does this need to be in two part section?

installing-on-infra-node
== Installing the {product-title-short} hub cluster on infrastructure nodes

An {ocp-short} cluster can be configured to contain infrastructure nodes for running approved management components. Running components on infrastructure nodes avoids allocating {ocp-short} subscription quota for the nodes that are running those management components.

After adding infrastructure nodes to your {ocp-short} cluster, follow the xref:../install/install_connected.adoc#installing-from-the-cli[Installing from the \{ocp-short} CLI] instructions and add configurations to the {olm} subscription and `MultiClusterHub` custom resource.

adding-infra-nodes
=== Add infrastructure nodes to the {ocp-short} cluster

Follow the procedures that are described in link:https://access.redhat.com/documentation/en-us/openshift_container_platform/4.14/html/machine_management/creating-infrastructure-machinesets[Creating infrastructure machine sets] in the {ocp-short} documentation. Infrastructure nodes are configured with a Kubernetes `taint` and `label` to keep non-management workloads from running on them.

To be compatible with the infrastructure node enablement provided by {product-title-short}, ensure your infrastructure nodes have the following `taint` and `label` applied:
 
 

• Anchors are painful
• Prereqs are full of what errors the user may see and then the step to avoid them, which is very odd. All that has to be organized as imperative and not as a troubleshooting task. This was not built as a procedure.

prerequisite-detach
== Prerequisites

Before you uninstall the {product-title-short} hub cluster, you must detach all of the clusters that are managed by that hub cluster. Detach all clusters that are still managed by the hub cluster, then try to uninstall again.

• If you use Discovery, you might see the following error when you attempt uninstall:
  +

  ---

  Cannot delete MultiClusterHub resource because DiscoveryConfig resource(s) exist

  ---

  //remove this error and rewrite this organization for others like this.
   

• removing-a-multiclusterhub-instance-by-using-commands
  == Removing multiclusterhub resources by using commands

MISSING DESCRIPTION - accessibility issue and against style and general industry guidance

. Change to your project namespace by entering the following command. Replace namespace with the your project namespace:

• .. Copy the following script into a file:
  //what is in the troubleshooting if we have the script here to clean up residual objects?
   
   

• This was copied and pasted but we should not have all of this in one command, it should have been broken out: 
  . Enter the following commands to delete the `ClusterServiceVersion` and `Subscription` in the namespace where it is installed. Replace the `2.x.0` value with the selected release:

+
[source,bash]

oc get csv
NAME DISPLAY VERSION REPLACES PHASE
advanced-cluster-management.v2.x.0 Advanced Cluster Management for Kubernetes 2.x.0 Succeeded

oc delete clusterserviceversion advanced-cluster-management.v2.x.0

oc get sub
NAME PACKAGE SOURCE CHANNEL
acm-operator-subscription advanced-cluster-management acm-custom-registry release-2.x

oc delete sub acm-operator-subscription
 

• Uninstall from console needs some clarity:

//uninstall from the console, click Delete MCH to delete the object and remove all components, wait for status, then you have to delete the operator in a new step

• Remove helm, that has not been something we required for a while now.