aap-20548: UI parity update for managing content in hub

downstream/assemblies/hub/assembly-managing-cert-valid-content.adoc

@@ -6,56 +6,70 @@ ifdef::context[:parent-context: {context}]
 :context: managing-cert-validated-content
 
 [role="_abstract"]
-{CertifiedName} are included in your subscription to {PlatformName}. Red Hat Ansible content includes two types of content: {CertifiedName} and {Valid}.
-Using {HubNameMain}, you can access and curate a unique set of collections from all forms of Ansible content.
+{CertifiedName} are included in your subscription to {PlatformName}. Using {HubNameMain}, you can access and curate a unique set of collections from all forms of Ansible content.
 
 Red Hat Ansible content contains two types of content:
 
 * {CertifiedName}
 * {Valid} collections
 
-Ansible validated collections are available in your {PrivateHubName} through the Platform Installer.
-When you download {PlatformName} with the bundled installer, validated content is pre-populated into the {PrivateHubName} by default, but only if you enable the {PrivateHubName} as part of the inventory.
+You can use both {CertifiedName} or {Valid} collections to build your automation library. For more information on the differences between {CertifiedName} and {Valid} collections, see the Knowledgebase article link:https://access.redhat.com/support/articles/ansible-automation-platform-certified-content[{CertifiedName} and {Valid}], or xref:assembly-validated-content[{Valid}] in this guide.
 
-If you are not using the bundle installer, you can use a Red Hat supplied Ansible playbook to install validated content.
-For further information, see xref:assembly-validated-content[{Valid}].
+// hherbly--removed, see aap-20548  
+// Ansible validated collections are available in your {PrivateHubName} through the platform installer.
+// When you download {PlatformName} with the bundled installer, validated content is pre-populated into the {PrivateHubName} by default, but only if you enable the {PrivateHubName} as part of the inventory.
+
+// If you are not using the bundle installer, you can use a Red Hat supplied Ansible playbook to install validated content.
+
+// For further information, see xref:assembly-validated-content[{Valid}].
 
 You can update these collections manually by downloading their packages.
 
+//hherbly: removing as this is specific to partners, not a general user audience. see aap-20548  
+
 [discrete]
-== Why certify Ansible collections?
 
-The Ansible certification program enables a shared statement of support for {CertifiedCon} between Red Hat and the ecosystem partner.
-An end customer, experiencing trouble with Ansible and certified partner content, can open a support ticket, for example, a request for information, or a problem with Red Hat, and expect the ticket to be resolved by Red Hat and the ecosystem partner.
+// == Why certify Ansible collections?
 
-Red Hat offers go-to-market benefits for Certified Partners to grow market awareness, generate demand, and sell collaboratively.
+// The Ansible certification program represents a shared statement of support for {CertifiedCon} between Red Hat and the ecosystem partner.
+// An end customer experiencing trouble with Ansible and certified partner content can, for example, open a support ticket describing a request for information, or a problem with Red Hat, and expect the ticket to be resolved by Red Hat and the ecosystem partner.
 
-Red Hat {CertifiedName} are distributed through {HubNameMain} (subscription required), a centralized repository for jointly supported Ansible Content.
-As a certified partner, publishing collections to {HubNameMain} provides end customers the power to manage how trusted automation content is used in their production environment with a well-known support life cycle.
+// Red Hat offers go-to-market benefits for Certified Partners to grow market awareness, generate demand, and sell collaboratively.
 
-For more information about getting started with certifying a solution, see link:https://connect.redhat.com/en/partner-with-us/red-hat-ansible-automation-certification[Red Hat Partner Connect].
+// Red Hat {CertifiedName} are distributed through {HubNameMain} (subscription required), a centralized repository for jointly supported Ansible Content.
+// As a certified partner, publishing collections to {HubNameMain} gives end customers the power to manage how trusted automation content is used in their production environment with a well-known support life cycle.
 
-[discrete]
-== How do I get a collection certified?
+// For more information about getting started with certifying a solution, see link:https://connect.redhat.com/en/partner-with-us/red-hat-ansible-automation-certification[Red Hat Partner Resources].
 
-For instructions on certifying your collection, see the Ansible certification policy guide on link:http://www.ansible.com/partners[Red Hat Partner Connect].
+// [discrete]
+// == How do I get a collection certified?
 
-[discrete]
-== How does the joint support agreement on Certified Collections work?
+// For instructions on certifying your collection, see the Ansible certification policy guide on link:http://www.ansible.com/partners[Red Hat Partner Connect].
 
-If a customer raises an issue with the Red Hat support team about a certified collection, Red Hat support assesses the issue and checks whether the problem exists within Ansible or Ansible usage.
-They also check whether the issue is with a certified collection.
-If there is a problem with the certified collection, support teams transfer the issue to the vendor owner of the certified collection through an agreed upon tool such as TSANet.
+// [discrete]
+// == How does the joint support agreement on Certified Collections work?
 
-[discrete]
-== Can I create and certify a collection containing only Ansible Roles?
+// If a customer raises an issue with the Red Hat support team about a certified collection, Red Hat support assesses the issue and checks whether the problem is with Ansible or Ansible usage.
+// They also check whether the issue is with a certified collection.
+// If there is a problem with the certified collection, support teams transfer the issue to the vendor owner of the certified collection through an agreed-upon tool such as TSANet.
 
-You can create and certify collections that contain only roles.
-Current testing requirements are focused on collections containing modules, and additional resources are currently in progress for testing collections only containing roles.
-Contact [email protected] for more information.
+// [discrete]
+// == Can I create and certify a collection containing only Ansible Roles?
+
+// You can create and certify collections that contain only roles.
+// Current testing requirements are focused on collections containing modules, and additional resources are currently in progress for testing collections containing only roles.
+// Contact [email protected] for more information.
+
+You can use {HubNameMain} to distribute the relevant {CertifiedColl}s to your users by creating a requirements file or a synclist. Use a requirements file to install collections to your {HubName}, as synclists can only be managed by users with platform administrator privileges. 
+
+Before you can use a requirements file to install content, you must: 
+
+. xref:proc-obtaining-org-collection-url[Obtain an automation hub API token]
+. xref:proc-set-rhcertified-remote.adoc[Use the API token to configure a remote repository in your local hub]
+. Then, xref:proc-create-requirements-file[Create a requirements file].
 
-include::assembly-synclists.adoc[leveloffset=+1]
 include::assembly-syncing-to-cloud-repo.adoc[leveloffset=+1]
+include::assembly-synclists.adoc[leveloffset=+1]
 include::assembly-collections-and-content-signing-in-pah.adoc[leveloffset=+1]
 //include::assembly-faq.adoc[leveloffset=+1]
 include::assembly-validated-content.adoc[leveloffset=+1]

downstream/assemblies/hub/assembly-managing-collections-hub.adoc

@@ -6,9 +6,9 @@ ifdef::context[:parent-context: {context}]
 :context: managing-collections-hub
 
 [role="_abstract"]
-As a content creator, you can use namespaces in {HubName} to curate and manage collections for the following purposes:
+As a content creator, you can use namespaces in {HubName} to curate and manage collections. For example, you can:
 
-* Create groups with permissions to curate namespaces and upload collections to {PrivateHubName}
+* Create teams with permissions to curate namespaces and upload collections to {PrivateHubName}
 * Add information and resources to the namespace to help end users of the collection in their automation tasks
 * Upload collections to the namespace
 * Review the namespace import logs to determine the success or failure of uploading the collection and its current approval status

downstream/assemblies/hub/assembly-repo-management.adoc

@@ -6,7 +6,7 @@ ifdef::context[:parent-context: {context}]
 :context: repo-management
 
 [role="_abstract"]
-As an {HubName} administrator, you can create, edit, delete, and move automation content collections between repositories.
+As a platform administrator, you can create, edit, delete, and move automation content collections between repositories.
 
 == Types of repositories in automation hub
 
@@ -16,7 +16,7 @@ Staging repositories:: Any user with permission to upload to a namespace can pub
 
 Custom repositories:: Any user with write permissions on the repository can publish collections to these repositories. Custom repositories can be public where all users can see them, or private  where only users with view permissions can see them. These repositories are not displayed on the approval dashboard. If the repository owner enables search, the collection can appear in search results.
 
-By default, {HubName} ships with one staging repository that is automatically used when a repository is not specified for uploading collections. Users can create new staging repositories during xref:proc-create-repository[repository creation].
+By default, {HubName} includes one staging repository that is automatically used when a repository is not specified for uploading collections. Users can create new staging repositories during xref:proc-create-repository[repository creation].
 
 include::hub/con-approval-pipeline.adoc[leveloffset=+1]
 include::hub/con-repo-rbac.adoc[leveloffset=+1]

downstream/assemblies/hub/assembly-syncing-to-cloud-repo.adoc

@@ -5,22 +5,20 @@ Use remote configurations to configure your {PrivateHubName} to synchronize with
 
 [IMPORTANT]
 ====
-As of the 2.4 release you can still synchronize content, but synclists are deprecated, and will be removed in a future version.
-
-To synchronize content, you can now upload a manually-created requirements file from the rh-certified remote. 
+To synchronize content, you can now upload a manually-created requirements file from the rh-certified remote. Remotes are configurations that allow you to synchronize content to your custom repositories from an external collection source.
 
-Remotes are configurations that allow you to synchronize content to your custom repositories from an external collection source.
+As of the 2.4 release you can still synchronize content, but synclists are deprecated, and will be removed in a future version.
 ====
 
 [discrete]
 == What’s the difference between {Galaxy} and {HubNameMain}?
 
 Collections published to {Galaxy} are the latest content published by the Ansible community and have no joint support claims associated with them. 
-{Galaxy} is the recommended frontend directory for the Ansible community accessing content.
+{Galaxy} is the recommended frontend directory for the Ansible community to access content.
 
-Collections published to {HubNameMain} are targeted for joint customers of Red Hat and selected partners. 
+Collections published to {HubNameMain} are targeted to joint customers of Red Hat and selected partners. 
 Customers need an Ansible subscription to access and download collections on {HubNameMain}. 
-A certified collection means that Red Hat and partners have a strategic relationship in place and are ready to support joint customers, and may have had additional testing and validation done against them.
+A certified collection means that Red Hat and partners have a strategic relationship in place and are ready to support joint customers, and that the collections may have had additional testing and validation done against them.
 
 [discrete]
 == How do I request a namespace on {Galaxy}?
@@ -37,12 +35,14 @@ After users are added as administrators of the namespace, you can use the self-s
 [discrete]
 == Are there any restrictions for {Galaxy} namespace naming?
 
-Collection namespaces must follow python module name convention. 
+Collection namespaces must follow Python module name convention. 
 This means collections should have short, all lowercase names. 
 You can use underscores in the collection name if it improves readability.
 
 include::hub/con-remote-repos.adoc[leveloffset=+1]
 
+include::hub/proc-create-requirements-file.adoc[leveloffset=+1]
+
 include::hub/proc-obtaining-org-collection-url.adoc[leveloffset=+1]
 
 include::hub/proc-set-rhcertified-remote.adoc[leveloffset=+1]

downstream/assemblies/hub/assembly-synclists.adoc

@@ -3,14 +3,11 @@
 
 [IMPORTANT]
 ====
-As of the 2.4 release you can still synchronize content, but synclists are deprecated, and will be removed in a future version.
-
 To synchronize content, you can now upload a manually-created requirements file from the rh-certified remote.
-
 Remotes are configurations that enable you to synchronize content to your custom repositories from an external collection source.
-====
 
-You can use {HubNameMain} to distribute the relevant {CertifiedColl}s to your users by creating synclists or a requirements file. For more information about using requirements files, see link:https://docs.ansible.com/ansible/latest/collections_guide/collections_installing.html#install-multiple-collections-with-a-requirements-file[Install multiple collections with a requirements file] in the _Using Ansible collections_ guide.
+As of the 2.4 release you can still synchronize content, but synclists are deprecated, and will be removed in a future version.
+====
 
 include::hub/con-rh-certified-synclist.adoc[leveloffset=+1]
 include::hub/proc-create-synclist.adoc[leveloffset=+1]

downstream/assemblies/hub/assembly-validated-content.adoc

@@ -14,17 +14,17 @@ Validated collections are uploaded into the `validated` repository.
 You can change to default configuration by using two variables:
 
 * `automationhub_seed_collections` is a boolean that defines whether or not preloading is enabled.
-* `automationhub_collection_seed_repository`. A variable that enables you to specify the type of content to upload when it is set to `true`.
+* `automationhub_collection_seed_repository`is a variable that enables you to specify the type of content to upload when it is set to `true`.
 Possible values are `certified` or `validated`.
-If missing both content sets will be uploaded.
+If this variable is missing, both content sets will be uploaded.
 
 == Installing validated content using the tarball
 
-If you are not using the bundle installer, you can use a standalone tarball, `ansible-validated-content-bundle-1.tar.gz`.
-You can also use this standalone tarball later to update validated contents in any environment, when a newer tarball becomes available, without having to re-run the bundle installer.
+If you are not using the bundle installer, you can use a standalone .tar file, `ansible-validated-content-bundle-1.tar.gz`.
+You can also use this standalone .tar file later to update validated contents in any environment, when a newer .tar file becomes available, without having to re-run the bundle installer.
 
 .Prerequisites
-You require the following variables to run the playbook.
+Use the following required variables to run the playbook.
 
 [cols="50%,50%",options="header"]
 |====
@@ -40,7 +40,7 @@ This variable is set to `true` by the installer.
 |====
 
 .Procedure
-. To obtain the tarball, navigate to the link:{PlatformDownloadUrl}[{PlatformName} download] page and select *Ansible Validated Content*.
+. To obtain the .tar file, navigate to the link:{PlatformDownloadUrl}[{PlatformName} download] page and select *Ansible Validated Content*.
 . Upload the content and define the variables (this example uses `automationhub_api_token`):
 +
 [options="nowrap" subs="+quotes,attributes"]

downstream/assemblies/hub/assembly-working-with-namespaces.adoc

@@ -6,15 +6,15 @@ Namespaces are unique locations in {HubName} to which you can upload and publish
 
 You can use namespaces in {HubName} to organize collections developed within your organization for internal distribution and use.
 
-If you are working with namespaces, you must have a group that has permissions to create, edit and upload collections to namespaces. Collections uploaded to a namespace require administrative approval before you can publish them and make them available for use.
+If you are working with namespaces, you must have a team that has permissions to create, edit and upload collections to namespaces. Collections uploaded to a namespace require administrative approval before you can publish them and make them available for use.
 
 include::hub/proc-create-content-developers.adoc[leveloffset=+1]
 
 include::hub/proc-create-namespace.adoc[leveloffset=+1]
 
 include::hub/proc-edit-namespace.adoc[leveloffset=+1]
 
-When you create a namespace, groups with permissions to upload to it can start adding their collections for approval. Collections in the namespace appear in the *Published* repository after approval.
+When you create a namespace, teams with permissions to upload to it can start adding their collections for approval. Collections in the namespace appear in the *Published* repository after approval.
 
 include::hub/proc-uploading-collections.adoc[leveloffset=+1]
 

downstream/modules/hub/con-approval-pipeline.adoc

@@ -6,7 +6,7 @@
 
 = Approval pipeline for custom repositories in {HubName}
 
-In {HubName} you can approve collections into any repository marked with the `pipeline=approved` label. By default, {HubName} ships with one repository for approved content, but you have the option to add more from the repository creation screen. You cannot directly publish into a repository marked with the `pipeline=approved` label. A collection must first go through a staging repository and be approved before being published into a 'pipleline=approved' repository. 
+In {HubName} you can approve collections into any repository marked with the `pipeline=approved` label. By default, {HubName} includes one repository for approved content, but you have the option to add more from the repository creation screen. You cannot directly publish into a repository marked with the `pipeline=approved` label. A collection must first go through a staging repository and be approved before being published into a 'pipleline=approved' repository. 
 
 Auto approval::
 When auto approve is enabled, any collection you upload to a staging repository is automatically promoted to all of the repositories marked as `pipeline=approved`.

downstream/modules/hub/con-rh-certified-synclist.adoc

@@ -2,10 +2,10 @@
 
 = Explanation of Red Hat {CertifiedName} synclists
 
-A synclist is a curated group of Red Hat Certified Collections that is assembled by your organization administrator.
+A synclist is a curated group of Red Hat Certified Collections assembled by your organization administrator.
 It synchronizes with your local {HubNameMain}. 
 Use synclists to manage only the content that you want and exclude unnecessary collections.
 Design and manage your synclist from the content available as part of Red Hat content on {Console}
 
-Each synclist has its own unique repository URL that you can use to designate as a remote source for content in {HubName}.
+Each synclist has its own unique repository URL that you can designate as a remote source for content in {HubName}.
 You securely access each synclist by using an API token.