attribute chnages reverting the must-should conundrum to original

abhatt-rh · abhatt-rh · commit 50d315a2feef · 2023-11-20T11:30:44.000Z
diff --git a/content/learn/about-pattern-tiers-types.adoc b/content/learn/about-pattern-tiers-types.adoc
@@ -13,25 +13,26 @@ aliases: /learn/pattern-tier-overview
 include::modules/comm-attributes.adoc[]
 
 [id="pattern-type"]
-== About the Validated Pattern tiers
+== About the {solution-name-upstream} tiers
 
-To know about the patterns that you can contribute and use, understand the following different pattern tiers:
+To know about the patterns that you can contribute and use, understand the following pattern tiers:
 
 |===
 |Pattern tier|Description
 
-|Sandboxed
-|A work in progress, might not yet include a demonstration. A Customer business problem has potentially not been identified or fully solved
+|{sandbox-tier-first}
+|A pattern under the {sandbox} tier or a {sandbox} pattern is one that might be in a work-in-progress state. , might not yet include a demonstration. A customer business problem has potentially not been identified or fully solved
 Might have been manually tested, and on a limited set of platforms
 Not yet reviewed by Red{nbsp}Hat
 
 
-|Tested
-|Clear business problem with demo
+|{tested-tier-first}
+The {tested} tier provides you with additional collateral and reassurance that the pattern was known to be recently working on at least one recent version of {rh-ocp}. Inclusion in this tier requires some additional work for the pattern’s owner - which might be a partner or a sufficiently motivated Subject Matter Expert (SME).|
+Clear business problem with demo
 All components are supportable*, and any Red Hat product usage signed-off by BUs
 Test plan (manual or automated) that passes at least once for each new OpenShift minor version within 3 months of GA
 
-|Maintained
+|{maintained-tier-first}
 |Group 2 plus…
 Formal release process with z-streams
 CI automation (either weekly or event driven at a similar interval)
diff --git a/content/learn/implementation.adoc b/content/learn/implementation.adoc
@@ -2,19 +2,19 @@
 menu:
   learn:
     parent: Workflow
-title: Implementation Requirements
+title: Implementation requirements
 weight: 42
 aliases: /requirements/implementation/
 ---
 
 :toc:
 
 [id="technical-requirements"]
-== Technical Requirements
+== Technical requirements
 
 Additional requirements specific to the implementation for all Community, and Validated patterns
 
-[id="must"]
+[id="must-implementation-requirements"]
 === Must
 
 . Patterns *MUST* include one or more Git repositories, in a publicly accessible location, containing configuration elements that can be consumed by the OpenShift GitOps operator (ArgoCD) without supplying custom ArgoCD images.
@@ -33,7 +33,7 @@ We distinguish between the provisioning and configuration requirements of the in
 . Managed clusters *MUST* operate on the premise of "`eventual consistency`" (automatic retries, and an expectation of idempotence), which is one of the essential benefits of the GitOps model.
 . Imperative elements *MUST* be implemented as idempotent code stored in Git
 
-[id="should"]
+[id="should-implementation-requirements"]
 === Should
 
 . Patterns SHOULD include sample application(s) to demonstrate the business problem(s) addressed by the pattern.
@@ -61,7 +61,7 @@ For example, Bucket Notification is a capability in the Medical Diagnosis patter
 . Imperative elements SHOULD be implemented as Ansible playbooks
 . Imperative elements SHOULD be driven declaratively -- by which we mean that the playbooks should be triggered by Jobs and/or CronJobs stored in Git and delivered by OpenShift GitOps.
 
-[id="can"]
+[id="can-implementation-requirements"]
 === Can
 
 . Patterns CAN include additional configuration and/or demo elements located in one or more additional private git repos.
diff --git a/content/learn/maintained.adoc b/content/learn/maintained.adoc
@@ -2,7 +2,7 @@
 menu:
   learn:
     parent: Workflow
-title: Validated Patterns - Maintained Tier
+title: Validated Patterns - Maintained tier
 weight: 45
 aliases: /requirements/maintained/
 aliases: /requirements/validated/
@@ -13,9 +13,9 @@ aliases: /requirements/validated/
 include::modules/comm-attributes.adoc[]
 
 [id="about-maintained-tier"]
-= About the {maintained-tier}
+= About the {maintained-tier-first}
 
-The {maintained-tier} is intended to provide consumers with additional "sales" collateral and reassurance that the pattern was known to be functional on all currently supported LTS versions of OpenShift. Inclusion in this tier may require additional work for the pattern's owner - which might be a partner or sufficiently motivated SME.
+The {maintained} tier is intended to provide consumers with additional "sales" collateral and reassurance that the pattern was known to be functional on all currently supported LTS versions of OpenShift. Inclusion in this tier may require additional work for the pattern's owner - which might be a partner or sufficiently motivated SME.
 
 [id="nominating-a-community-pattern-to-become-validated"]
 == Nominating a maintained pattern for promotion to a validated pattern
@@ -38,16 +38,16 @@ specified for the link:/requirements/tested/[Tested tier]
 [id="must-maintained-tier"]
 === Must
 
-. {maintained-pattern} *MUST* continue to meet the following criteria to remain in Maintained Tested tier
-. {maintained-pattern} *MUST* conform to the common technical link:/requirements/implementation/[implementation requirements]
-. {maintained-pattern} *MUST* only make use of components that are either supported, or easily substitued for supportable equivalents (eg. HashiCorp vault which has community and enterprise variants)
-. {maintained-pattern} *MUST NOT* rely on functionality in tech-preview, or hidden behind feature gates
-. {maintained-pattern} *MUST* have their architectures reviewed by the PM, TPM, or TMM of each Red Hat product they consume to ensure consistency with the product teams` intentions and roadmaps
-. {maintained-pattern} *MUST* include a presentation deck oriented around the business problem being solved and intended for use by the field to sell and promote the solution
-. {maintained-pattern} *MUST* include test plan automation that runs on every change to the pattern, or a schedule no less frequently than once per week
-. {maintained-pattern} *MUST* be tested on all currently supported OpenShift LTS releases
-. {maintained-pattern} *MUST* fix breakage in a "timely" manner
-. {maintained-pattern} *MUST* document their support policy
+. {maintained} pattern *MUST* continue to meet the following criteria to remain in Maintained Tested tier
+. {maintained} pattern *MUST* conform to the common technical link:/requirements/implementation/[implementation requirements]
+. {maintained} pattern *MUST* only make use of components that are either supported, or easily substitued for supportable equivalents (eg. HashiCorp vault which has community and enterprise variants)
+. {maintained} pattern *MUST NOT* rely on functionality in tech-preview, or hidden behind feature gates
+. {maintained} pattern *MUST* have their architectures reviewed by the PM, TPM, or TMM of each Red Hat product they consume to ensure consistency with the product teams` intentions and roadmaps
+. {maintained} pattern *MUST* include a presentation deck oriented around the business problem being solved and intended for use by the field to sell and promote the solution
+. {maintained} pattern *MUST* include test plan automation that runs on every change to the pattern, or a schedule no less frequently than once per week
+. {maintained} pattern *MUST* be tested on all currently supported OpenShift LTS releases
+. {maintained} pattern *MUST* fix breakage in a "timely" manner
+. {maintained} pattern *MUST* document their support policy
 +
 The individual products used in a Validated Pattern are backed by the full Red Hat support experience conditional on the customer's subscription to those products, and the individual products`' support policy.
 +
@@ -57,7 +57,7 @@ The {solution-name-upstream} team is very motivated to address any problems in t
 +
 TODO: Create an aDoc version of our support statement slide
 
-. {maintained-pattern} *DO NOT* imply an obligation of support for partner or community operators by Red Hat.
+. {maintained} pattern *DO NOT* imply an obligation of support for partner or community operators by Red Hat.
 
 [id="can-maintained-tier"]
 === Can
diff --git a/content/learn/sandbox.adoc b/content/learn/sandbox.adoc
@@ -2,7 +2,7 @@
 menu:
   learn:
     parent: Workflow
-title: Validated Patterns - Sandbox Tier
+title: Validated Patterns - Sandbox tier
 weight: 43
 aliases: /requirements/community/
 aliases: /requirements/sandbox/
@@ -14,9 +14,9 @@ aliases: /requirements/sandbox/
 include::modules/comm-attributes.adoc[]
 
 [id="about-sandbox-tier"]
-= About the {sandbox-tier}
+= About the {sandbox-tier-first}
 
-The {sandbox-tier} is an inclusive and low-risk way to become associated with the {solution-name-upstream} project. The minimum requirement to qualify for the {sandbox-tier} is that you must start with the patterns framework and include some minimal documentation.
+The {sandbox} tier is an inclusive and low-risk way to become associated with the {solution-name-upstream} project. The minimum requirement to qualify for the {sandbox} tier is that you must start with the patterns framework and include some minimal documentation.
 
 [id="onboarding-existing-implementations"]
 == Onboarding existing implementations
@@ -40,26 +40,26 @@ General requirements for all {solution-name-upstream}
 [id="must-sandbox-tier"]
 === Must
 
-. {sandbox-pattern} *MUST* continue to meet the following criteria to remain in the Sandbox tier
-. {sandbox-pattern} *MUST* conform to the common technical link:/requirements/implementation/[implementation requirements]
-. {sandbox-pattern} *MUST* be able to be deployed onto a freshly deployed OpenShift cluster without prior modification or tuning
-. {sandbox-pattern} *MUST* include a top-level README highlighting the business problem and how the pattern solves it
-. {sandbox-pattern} *MUST* include an architecture drawing. The specific tool/format is flexible as long as the meaning is clear.
-. {sandbox-pattern} *MUST* undergo an informal technical review by a community leader to ensure that it meets basic reuse standards
-. {sandbox-pattern} *MUST* undergo an informal architecture review by a community leader to ensure that the solution has the right components, and they are generally being used as intended.
+. {sandbox} pattern *MUST* continue to meet the following criteria to remain in the Sandbox tier
+. {sandbox} pattern *MUST* conform to the common technical link:/requirements/implementation/[implementation requirements]
+. {sandbox} pattern *MUST* be able to be deployed onto a freshly deployed OpenShift cluster without prior modification or tuning
+. {sandbox} pattern *MUST* include a top-level README highlighting the business problem and how the pattern solves it
+. {sandbox} pattern *MUST* include an architecture drawing. The specific tool/format is flexible as long as the meaning is clear.
+. {sandbox} pattern *MUST* undergo an informal technical review by a community leader to ensure that it meets basic reuse standards
+. {sandbox} pattern *MUST* undergo an informal architecture review by a community leader to ensure that the solution has the right components, and they are generally being used as intended.
 +
 For example: not using a database as a message bus.
 As community leaders, contributions from within Red Hat may be subject to a higher level of scrutiny.
 While we strive to be inclusive, the community will have quality standards and generally using the framework does not automatically imply a solution is suitable for the community to endorse/publish.
-. {sandbox-pattern} *MUST* document their support policy
+. {sandbox} pattern *MUST* document their support policy
 +
-It is anticipated that most{sandbox-pattern} will be supported by the community on a best-effort basis, but this should be stated explicitly.
+It is anticipated that most{sandbox} pattern will be supported by the community on a best-effort basis, but this should be stated explicitly.
 The {solution-name-upstream} team commits to maintaining the framework but will also accept help.
 
 
 [id="can-sandbox-tier"]
 === Can
 
-. {sandbox-pattern} (including works-in-progress) CAN be hosted in the link:https://github.com/validatedpatterns-sandbox[https://github.com/validatedpatterns-sandbox] GitHub organization
-. {sandbox-pattern} CAN be listed on the link:https://validatedpatterns.io[https://validatedpatterns.io] site
-. {sandbox-pattern} meeting additional criteria CAN be nominated for promotion to the link:/learn/tested/[Tested tier]
+. {sandbox} pattern (including works-in-progress) CAN be hosted in the link:https://github.com/validatedpatterns-sandbox[https://github.com/validatedpatterns-sandbox] GitHub organization
+. {sandbox} pattern CAN be listed on the link:https://validatedpatterns.io[https://validatedpatterns.io] site
+. {sandbox} pattern meeting additional criteria CAN be nominated for promotion to the link:/learn/tested/[Tested tier]
diff --git a/content/learn/tested.adoc b/content/learn/tested.adoc
@@ -2,7 +2,7 @@
 menu:
   learn:
     parent: Workflow
-title: Validated Patterns - Tested Tier
+title: Validated Patterns - Tested tier
 weight: 44
 aliases: /requirements/tested/
 ---
@@ -13,9 +13,9 @@ aliases: /requirements/tested/
 include::modules/comm-attributes.adoc[]
 
 [id="about-tested-tier"]
-= About the {tested-tier}
+= About the {tested-tier-first}
 
-The {tested-tier} provides you with additional collateral and reassurance that the pattern was known to be recently working on at least one recent version of {rh-ocp}. Inclusion in this tier requires some additional work for the pattern's owner - which might be a partner or a sufficiently motivated Subject Matter Expert (SME).
+The {tested} tier provides you with additional collateral and reassurance that the pattern was known to be recently working on at least one recent version of {rh-ocp}. Inclusion in this tier requires some additional work for the pattern's owner - which might be a partner or a sufficiently motivated Subject Matter Expert (SME).
 
 [id="nominating-a-community-pattern-to-become-maintained"]
 == Nominating a tested pattern for promotion to a maintained pattern
@@ -32,45 +32,45 @@ In limited cases, the {solution-name-upstream} team may consider taking on that
 [id="requirements-tested-tier"]
 == Requirements
 
-{tested-pattern} have deliverable and requirements *in addition* to those
+{tested} pattern have deliverable and requirements *in addition* to those
 specified for the link:/requirements/sandbox/[Sandbox tier]
 
 [id="must-tested-tier"]
 === Must
 
-. {tested-pattern} *MUST* continue to meet the following criteria to remain in the {tested-tier}
-. {tested-pattern} *MUST* conform to the common technical link:/requirements/implementation/[implementation requirements]
-. {tested-pattern} *MUST* be meaningful without specialized hardware, including flavors of architectures not explicitly supported.
+. {tested} pattern *MUST* continue to meet the following criteria to remain in the {tested} tier
+. {tested} pattern *MUST* conform to the common technical link:/requirements/implementation/[implementation requirements]
+. {tested} pattern *MUST* be meaningful without specialized hardware, including flavors of architectures not explicitly supported.
 +
 Qualification is a {solution-name-upstream} TOC decision with input from the pattern owner.
 
-. {tested-pattern} *MUST* have their implementation reviewed by the patterns team to ensure that it is sufficiently flexible to function across a variety of platforms, customer environments, and any relevant verticals.
-. {tested-pattern} *MUST* include a standardized architecture drawing, created with (or at least conforming to) the PAC tooling
-. {tested-pattern} *MUST* include a written guide for others to follow when demonstrating the pattern
-. {tested-pattern} *MUST* include a test plan covering all features or attributes being highlighted by the demonstration guide. Negative flow tests (such as resiliency or data retention in the presence of network outages) are also limited to scenarios covered by the demonstration guide.
+. {tested} pattern *MUST* have their implementation reviewed by the patterns team to ensure that it is sufficiently flexible to function across a variety of platforms, customer environments, and any relevant verticals.
+. {tested} pattern *MUST* include a standardized architecture drawing, created with (or at least conforming to) the PAC tooling
+. {tested} pattern *MUST* include a written guide for others to follow when demonstrating the pattern
+. {tested} pattern *MUST* include a test plan covering all features or attributes being highlighted by the demonstration guide. Negative flow tests (such as resiliency or data retention in the presence of network outages) are also limited to scenarios covered by the demonstration guide.
 +
 The test plan *MUST* define how to validate if the pattern has been successfully deployed and is functionally operational.
 Example: https://docs.google.com/document/d/12KQhdzjVIsxRURTnWAckiEMB3_96oWBjtlTXi1q73cg/view[Validating an Industrial Edge Deployment]
 +
 //TODO: Convert above link to adoc
 
-. {tested-pattern} *MUST* nominate at least one currently supported OpenShift release to test against
-. {tested-pattern} *MUST* ensure the test plan passes at least once per quarter
-. {tested-pattern} *MUST* create a publically available JSON file (eg. in an AWS bucket) that records the result of the latest test for each combination of pattern, platform, and OpenShift version. See link:/learn/test-artefacts/[testing artefacts]
-. {tested-pattern} *DO NOT* imply an obligation of support for partner or community operators by Red Hat or the pattern owner.
+. {tested} pattern *MUST* nominate at least one currently supported OpenShift release to test against
+. {tested} pattern *MUST* ensure the test plan passes at least once per quarter
+. {tested} pattern *MUST* create a publically available JSON file (eg. in an AWS bucket) that records the result of the latest test for each combination of pattern, platform, and OpenShift version. See link:/learn/test-artefacts/[testing artefacts]
+. {tested} pattern *DO NOT* imply an obligation of support for partner or community operators by Red Hat or the pattern owner.
 
 [id="should-tested-tier"]
 === Should
 
-. {tested-pattern} SHOULD be broadly applicable.
-. {tested-pattern} SHOULD focus on functionality not performance.
+. {tested} pattern SHOULD be broadly applicable.
+. {tested} pattern SHOULD focus on functionality not performance.
 
 [id="can-tested-tier"]
 === Can
 
-. Teams creating {tested-pattern} CAN provide their own SLA
+. Teams creating {tested} pattern CAN provide their own SLA
 +
 A document for QE that defines, at a technical level, how to validate if the pattern has been successfully deployed and is functionally operational.
 Example: https://docs.google.com/document/d/12KQhdzjVIsxRURTnWAckiEMB3_96oWBjtlTXi1q73cg/view[Validating an Industrial Edge Deployment]
 
-. {tested-pattern} meeting additional criteria CAN be nominated for promotion to the link:/learn/maintained/[Maintained tier]
+. {tested} pattern meeting additional criteria CAN be nominated for promotion to the link:/learn/maintained/[Maintained tier]
diff --git a/modules/comm-attributes.adoc b/modules/comm-attributes.adoc
@@ -9,13 +9,13 @@
 //Pattern names
 //:rh-solution-name: Validated Patterns
 :solution-name-upstream: Validated Patterns
-:sandbox-pattern: Sandbox Patterns
-:maintained-pattern: Maintained Patterns
-:tested-pattern: Tested Patterns
 //Validated Patterns tiers
-:sandbox-tier: Sandbox tier
-:maintained-tier: Maintained tier
-:tested-tier: Tested tier
+:sandbox: sandbox
+:maintained: maintained
+:tested: tested
+:sandbox-tier-first: Validated Patterns Sandbox tier
+:tested-tier-first: Validated Patterns Tested tier
+:maintained-tier-first: Validated Patterns Maintained tier
 //:solution-version: Update later when we start using versioned releases
 //Patterns
 :aeg-pattern: Ansible Edge GitOps pattern
