From 17ad1ee7510b2b68c86c81d14a8475a39c88387d Mon Sep 17 00:00:00 2001 From: Himadri Bisht Date: Thu, 12 Dec 2024 15:24:22 +0530 Subject: [PATCH 1/4] Moved patterns from learn to contribute section --- content/learn/about-pattern-tiers-types.adoc | 6 +++--- content/learn/implementation.adoc | 10 +++++----- content/learn/maintained.adoc | 14 +++++++------- content/learn/sandbox.adoc | 15 +++++++-------- content/learn/tested.adoc | 16 ++++++++-------- 5 files changed, 30 insertions(+), 31 deletions(-) diff --git a/content/learn/about-pattern-tiers-types.adoc b/content/learn/about-pattern-tiers-types.adoc index 948adfb88..483098382 100644 --- a/content/learn/about-pattern-tiers-types.adoc +++ b/content/learn/about-pattern-tiers-types.adoc @@ -22,20 +22,20 @@ The different tiers of {solution-name-upstream} are designed to facilitate ongoi |Icon|Pattern tier|Description |image:pattern-tier-sandbox.png[] -|link:/requirements/sandbox/[{sandbox-tier-first}] +|link:/contribute/sandbox/[{sandbox-tier-first}] |A pattern categorized under the {sandbox} tier provides you with an entry point to onboard to {solution-name-upstream}. The minimum requirement to qualify for the {sandbox} tier is to start with the patterns framework and include minimal documentation. The patterns in this tier might be in a work-in-progress state; and they might have been manually tested on a limited set of platforms. |image:pattern-tier-tested.png[] -|link:/requirements/tested/[{tested-tier-first}] +|link:/contribute/tested/[{tested-tier-first}] |A pattern categorized under the {tested} tier implies that the pattern might have been recently working on at least one recent version of {rh-ocp}. Qualifying for this tier might require additional work for the pattern’s owner, who might be a partner or a motivated subject matter expert (SME). The patterns in this tier might have a defined business problem with a demonstration. The patterns might have a manual or automated test plan, which passes at least once for each new {rh-ocp} minor version. |image:pattern-tier-maintained.png[] -|link:/requirements/maintained/[{maintained-tier-first}] +|link:/contribute/maintained/[{maintained-tier-first}] |A pattern categorized under the {maintained} tier implies that the pattern might have been functional on all currently supported extended update support (EUS) versions of {rh-ocp}. Qualifying for this tier might require additional work for the pattern’s owner who might be a partner or a motivated SME. The patterns in this tier might have a formal release process with patch releases. They might have continuous integration (CI) automation testing. diff --git a/content/learn/implementation.adoc b/content/learn/implementation.adoc index 8068e712a..f5ce2675a 100644 --- a/content/learn/implementation.adoc +++ b/content/learn/implementation.adoc @@ -1,14 +1,14 @@ --- menu: - learn: - parent: Workflow + contribute: + parent: Contributing and managing patterns title: Implementation requirements -weight: 62 -aliases: /requirements/implementation/ +weight: 51 +aliases: /contribute/implementation/ --- :toc: - +:imagesdir: /images :_content-type: ASSEMBLY include::modules/comm-attributes.adoc[] diff --git a/content/learn/maintained.adoc b/content/learn/maintained.adoc index ce2a5af17..ab3a49f54 100644 --- a/content/learn/maintained.adoc +++ b/content/learn/maintained.adoc @@ -1,14 +1,14 @@ --- menu: - learn: - parent: Workflow + contribute: + parent: Contributing and managing patterns title: Validated Patterns - Maintained tier -weight: 65 -aliases: /requirements/maintained/ +weight: 54 +aliases: /contribute/maintained/ --- :toc: - +:imagesdir: /images :_content-type: ASSEMBLY include::modules/comm-attributes.adoc[] @@ -36,7 +36,7 @@ In limited cases, the {solution-name-upstream} team may consider taking on that == Requirements for the {maintained} tier The {maintained} patterns have deliverable and requirements in addition to those -specified for the link:/requirements/tested/[Tested tier]. +specified for the link:/contribute/tested/[Tested tier]. The requirements are categorized as follows: @@ -52,7 +52,7 @@ These are optional or desirable features, but their absence does not hinder the A {maintained} pattern must continue to meet the following criteria to remain in {maintained} tier: -* A {maintained} pattern must conform to the common technical link:/requirements/implementation/[implementation requirements]. +* A {maintained} pattern must conform to the common technical link:/contribute/implementation/[implementation requirements]. * A {maintained} pattern must only make use of components that are either supported, or easily substituted for supportable equivalents, for example, HashiCorp vault which has community and enterprise variants. * A {maintained} pattern must *not* rely on functionality in tech-preview, or hidden behind feature gates. * A {maintained} pattern must have their architectures reviewed by a representative of each Red Hat product they consume to ensure consistency with the product teams` intentions and roadmaps. Your patterns SME (eg. services rep) can help coordinate this. diff --git a/content/learn/sandbox.adoc b/content/learn/sandbox.adoc index 32fd936fb..125df9602 100644 --- a/content/learn/sandbox.adoc +++ b/content/learn/sandbox.adoc @@ -1,15 +1,14 @@ --- menu: - learn: - parent: Workflow + contribute: + parent: Contributing and managing patterns title: Validated Patterns - Sandbox tier -weight: 63 -aliases: /requirements/community/ -aliases: /requirements/sandbox/ +weight: 52 +aliases: /contribute/sandbox/ --- :toc: - +:imagesdir: /images :_content-type: ASSEMBLY include::modules/comm-attributes.adoc[] @@ -48,7 +47,7 @@ These are optional or desirable features, but their absence does not hinder the === Must A {sandbox} pattern must continue to meet the following criteria to remain in the {sandbox} tier: -* A {sandbox} pattern must conform to the common technical link:/requirements/implementation/[implementation requirements]. +* A {sandbox} pattern must conform to the common technical link:/contribute/implementation/[implementation requirements]. * A {sandbox} pattern must be able to be deployed onto a freshly deployed OpenShift cluster without prior modification or tuning. * A {sandbox} pattern must include a top-level README file that highlights the business problem and how the pattern solves it. * A {sandbox} pattern must include an architecture drawing. The specific tool or format is flexible as long as the meaning is clear. @@ -69,4 +68,4 @@ The {solution-name-upstream} team commits to maintaining the framework, but will * A {sandbox} pattern (including works-in-progress) can be hosted in the link:https://github.com/validatedpatterns-sandbox[https://github.com/validatedpatterns-sandbox] GitHub organization. * A {sandbox} pattern can be listed on the link:https://validatedpatterns.io[https://validatedpatterns.io] site. -* A {sandbox} pattern meeting additional criteria can be nominated for promotion to the link:/learn/tested/[Tested tier]. +* A {sandbox} pattern meeting additional criteria can be nominated for promotion to the link:/contribute/tested/[Tested tier]. diff --git a/content/learn/tested.adoc b/content/learn/tested.adoc index 4e4ed7a7d..3fa95d9fa 100644 --- a/content/learn/tested.adoc +++ b/content/learn/tested.adoc @@ -1,14 +1,14 @@ --- menu: - learn: - parent: Workflow + contribute: + parent: Contributing and managing patterns title: Validated Patterns - Tested tier -weight: 64 -aliases: /requirements/tested/ +weight: 53 +aliases: /contribute/tested/ --- :toc: - +:imagesdir: /images :_content-type: ASSEMBLY include::modules/comm-attributes.adoc[] @@ -35,7 +35,7 @@ In limited cases, the {solution-name-upstream} team may consider taking on that [id="requirements-tested-tier"] == Requirements for the {tested} tier -A {tested} patterns have deliverable and requirements in addition to those specified for the link:/requirements/sandbox/[Sandbox tier]. +A {tested} patterns have deliverable and requirements in addition to those specified for the link:/contribute/sandbox/[Sandbox tier]. The requirements are categorized as follows: @@ -51,7 +51,7 @@ These are optional or desirable features, but their absence does not hinder the A {tested} pattern must continue to meet the following criteria to remain in the {tested} tier: -* A {tested} pattern must conform to the common technical link:/requirements/implementation/[implementation requirements]. +* A {tested} pattern must conform to the common technical link:/contribute/implementation/[implementation requirements]. * A {tested} pattern must be meaningful without specialized hardware, including flavors of architectures not explicitly supported. + Qualification is a {solution-name-upstream} Technical Oversight Committee (TOC) decision with input from the pattern owner. @@ -88,4 +88,4 @@ Teams creating {tested} pattern can provide their own service level agreement (S A technical document for Quality Engineering (QE) team that defines how to validate if the pattern has been successfully deployed and is functionally operational. For example, see link:https://docs.google.com/document/d/12KQhdzjVIsxRURTnWAckiEMB3_96oWBjtlTXi1q73cg/view[Validating an Industrial Edge Deployment]. -A {tested} pattern meeting additional criteria can be nominated for promotion to the link:/learn/maintained/[Maintained tier]. +A {tested} pattern meeting additional criteria can be nominated for promotion to the link:/contribute/maintained/[Maintained tier]. From ceb8f50927e7fcf01447af12a00252aa521f31a3 Mon Sep 17 00:00:00 2001 From: Himadri Bisht Date: Thu, 12 Dec 2024 15:41:59 +0530 Subject: [PATCH 2/4] Corrected the tested tier title --- content/learn/tested.adoc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/learn/tested.adoc b/content/learn/tested.adoc index 3fa95d9fa..3620bde76 100644 --- a/content/learn/tested.adoc +++ b/content/learn/tested.adoc @@ -18,7 +18,7 @@ include::modules/comm-attributes.adoc[] 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-pattern-for-tested-tier"] -== Nominating a a pattern for the {tested} tier +== Nominating a pattern for the {tested} tier If your pattern qualifies or meets the criteria for {tested} tier, submit your nomination to mailto:validatedpatterns@googlegroups.com[validatedpatterns@googlegroups.com]. From adb43eaa1502f590257e0b70dfcb9c3bd87eca1e Mon Sep 17 00:00:00 2001 From: Himadri Bisht Date: Thu, 12 Dec 2024 16:07:28 +0530 Subject: [PATCH 3/4] moved content under contribute folder --- content/{learn => contribute}/implementation.adoc | 0 content/{learn => contribute}/maintained.adoc | 2 +- content/{learn => contribute}/sandbox.adoc | 0 content/{learn => contribute}/tested.adoc | 0 4 files changed, 1 insertion(+), 1 deletion(-) rename content/{learn => contribute}/implementation.adoc (100%) rename content/{learn => contribute}/maintained.adoc (96%) rename content/{learn => contribute}/sandbox.adoc (100%) rename content/{learn => contribute}/tested.adoc (100%) diff --git a/content/learn/implementation.adoc b/content/contribute/implementation.adoc similarity index 100% rename from content/learn/implementation.adoc rename to content/contribute/implementation.adoc diff --git a/content/learn/maintained.adoc b/content/contribute/maintained.adoc similarity index 96% rename from content/learn/maintained.adoc rename to content/contribute/maintained.adoc index ab3a49f54..033bb3006 100644 --- a/content/learn/maintained.adoc +++ b/content/contribute/maintained.adoc @@ -29,7 +29,7 @@ Each {maintained} pattern represents an ongoing maintenance, support, and testin For this reason we have designed the tiers and our processes to facilitate this to occur outside of the team by any sufficiently motivated party, including other parts of Red Hat, partners, and even customers. -In limited cases, the {solution-name-upstream} team may consider taking on that work, however, it is recommended that you contact the team at least 4 weeks prior to the end of a given quarter for the necessary work to be considered as part of the following quarter's planning process. +In limited cases, the {solution-name-upstream} team may consider taking on that work, however, it is recommended that you contact the team at least 4 weeks before the end of a given quarter for the necessary work to be considered as part of the following quarter's planning process. [id="requirements-maintained-tier"] diff --git a/content/learn/sandbox.adoc b/content/contribute/sandbox.adoc similarity index 100% rename from content/learn/sandbox.adoc rename to content/contribute/sandbox.adoc diff --git a/content/learn/tested.adoc b/content/contribute/tested.adoc similarity index 100% rename from content/learn/tested.adoc rename to content/contribute/tested.adoc From 4a74890cc2e0c40670de28f0b51da8868a121547 Mon Sep 17 00:00:00 2001 From: Himadri Bisht Date: Fri, 13 Dec 2024 18:58:34 +0530 Subject: [PATCH 4/4] moved testing artifacts from learn to contribute section --- content/contribute/implementation.adoc | 2 +- content/contribute/maintained.adoc | 22 ++++++++-------- content/contribute/sandbox.adoc | 22 ++++++++-------- .../{learn => contribute}/test-artifacts.adoc | 8 +++--- content/contribute/tested.adoc | 26 +++++++++---------- 5 files changed, 40 insertions(+), 40 deletions(-) rename content/{learn => contribute}/test-artifacts.adoc (95%) diff --git a/content/contribute/implementation.adoc b/content/contribute/implementation.adoc index f5ce2675a..a8d070ac1 100644 --- a/content/contribute/implementation.adoc +++ b/content/contribute/implementation.adoc @@ -3,7 +3,7 @@ menu: contribute: parent: Contributing and managing patterns title: Implementation requirements -weight: 51 +weight: 52 aliases: /contribute/implementation/ --- diff --git a/content/contribute/maintained.adoc b/content/contribute/maintained.adoc index 033bb3006..21fae666b 100644 --- a/content/contribute/maintained.adoc +++ b/content/contribute/maintained.adoc @@ -3,7 +3,7 @@ menu: contribute: parent: Contributing and managing patterns title: Validated Patterns - Maintained tier -weight: 54 +weight: 55 aliases: /contribute/maintained/ --- @@ -52,15 +52,15 @@ These are optional or desirable features, but their absence does not hinder the A {maintained} pattern must continue to meet the following criteria to remain in {maintained} tier: -* A {maintained} pattern must conform to the common technical link:/contribute/implementation/[implementation requirements]. -* A {maintained} pattern must only make use of components that are either supported, or easily substituted for supportable equivalents, for example, HashiCorp vault which has community and enterprise variants. -* A {maintained} pattern must *not* rely on functionality in tech-preview, or hidden behind feature gates. -* A {maintained} pattern must have their architectures reviewed by a representative of each Red Hat product they consume to ensure consistency with the product teams` intentions and roadmaps. Your patterns SME (eg. services rep) can help coordinate this. -* A {maintained} pattern must include a link to a hosted presentation (Google Slides or similar) intended to promote the solution. The focus should be on the architecture and business problem being solved. No customer, or otherwise sensitive, information should be included. -* A {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. -* A {maintained} pattern must be tested on all currently supported {rh-ocp} extended update support (EUS) releases. -* A {maintained} pattern must fix breakage in timely manner. -* A {maintained} pattern must document their support policy. +. A {maintained} pattern must conform to the common technical link:/contribute/implementation/[implementation requirements]. +. A {maintained} pattern must only make use of components that are either supported, or easily substituted for supportable equivalents, for example, HashiCorp vault which has community and enterprise variants. +. A {maintained} pattern must *not* rely on functionality in tech-preview, or hidden behind feature gates. +. A {maintained} pattern must have their architectures reviewed by a representative of each Red Hat product they consume to ensure consistency with the product teams` intentions and roadmaps. Your patterns SME (eg. services rep) can help coordinate this. +. A {maintained} pattern must include a link to a hosted presentation (Google Slides or similar) intended to promote the solution. The focus should be on the architecture and business problem being solved. No customer, or otherwise sensitive, information should be included. +. A {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. +. A {maintained} pattern must be tested on all currently supported {rh-ocp} extended update support (EUS) releases. +. A {maintained} pattern must fix breakage in timely manner. +. A {maintained} pattern must document their support policy. + The individual products used in a {solution-name-upstream} are backed by the full {redhat} support experience conditional on the customer's subscription to those products, and the individual products`s support policy. @@ -79,4 +79,4 @@ The {maintained} patterns *do not* imply an obligation of support for partner or [id="can-maintained-tier"] === Can -* If you are creating {solution-name-upstream}, you can provide your own SLA. +. If you are creating {solution-name-upstream}, you can provide your own SLA. diff --git a/content/contribute/sandbox.adoc b/content/contribute/sandbox.adoc index 125df9602..dc75c7242 100644 --- a/content/contribute/sandbox.adoc +++ b/content/contribute/sandbox.adoc @@ -3,7 +3,7 @@ menu: contribute: parent: Contributing and managing patterns title: Validated Patterns - Sandbox tier -weight: 52 +weight: 53 aliases: /contribute/sandbox/ --- @@ -47,15 +47,15 @@ These are optional or desirable features, but their absence does not hinder the === Must A {sandbox} pattern must continue to meet the following criteria to remain in the {sandbox} tier: -* A {sandbox} pattern must conform to the common technical link:/contribute/implementation/[implementation requirements]. -* A {sandbox} pattern must be able to be deployed onto a freshly deployed OpenShift cluster without prior modification or tuning. -* A {sandbox} pattern must include a top-level README file that highlights the business problem and how the pattern solves it. -* A {sandbox} pattern must include an architecture drawing. The specific tool or format is flexible as long as the meaning is clear. -* A {sandbox} pattern must undergo an informal technical review by a community leader to ensure that it meets basic reuse standards. -* A {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. +. A {sandbox} pattern must conform to the common technical link:/contribute/implementation/[implementation requirements]. +. A {sandbox} pattern must be able to be deployed onto a freshly deployed OpenShift cluster without prior modification or tuning. +. A {sandbox} pattern must include a top-level README file that highlights the business problem and how the pattern solves it. +. A {sandbox} pattern must include an architecture drawing. The specific tool or format is flexible as long as the meaning is clear. +. A {sandbox} pattern must undergo an informal technical review by a community leader to ensure that it meets basic reuse standards. +. A {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 {redhat} might 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. -* A {sandbox} pattern must document their support policy. +. A {sandbox} pattern must document their support policy. [NOTE] ==== @@ -66,6 +66,6 @@ The {solution-name-upstream} team commits to maintaining the framework, but will [id="can-sandbox-tier"] === Can -* A {sandbox} pattern (including works-in-progress) can be hosted in the link:https://github.com/validatedpatterns-sandbox[https://github.com/validatedpatterns-sandbox] GitHub organization. -* A {sandbox} pattern can be listed on the link:https://validatedpatterns.io[https://validatedpatterns.io] site. -* A {sandbox} pattern meeting additional criteria can be nominated for promotion to the link:/contribute/tested/[Tested tier]. +. A {sandbox} pattern (including works-in-progress) can be hosted in the link:https://github.com/validatedpatterns-sandbox[https://github.com/validatedpatterns-sandbox] GitHub organization. +. A {sandbox} pattern can be listed on the link:https://validatedpatterns.io[https://validatedpatterns.io] site. +. A {sandbox} pattern meeting additional criteria can be nominated for promotion to the link:/contribute/tested/[Tested tier]. diff --git a/content/learn/test-artifacts.adoc b/content/contribute/test-artifacts.adoc similarity index 95% rename from content/learn/test-artifacts.adoc rename to content/contribute/test-artifacts.adoc index 316be92fa..ab904a617 100644 --- a/content/learn/test-artifacts.adoc +++ b/content/contribute/test-artifacts.adoc @@ -1,10 +1,10 @@ --- menu: - learn: - parent: Workflow + contribute: + parent: Contributing and managing patterns title: Testing Artifacts -weight: 50 -aliases: /requirements/tested/ +weight: 51 +aliases: /contribute/test-artifacts/ --- :toc: diff --git a/content/contribute/tested.adoc b/content/contribute/tested.adoc index 3620bde76..c1da48ef0 100644 --- a/content/contribute/tested.adoc +++ b/content/contribute/tested.adoc @@ -3,7 +3,7 @@ menu: contribute: parent: Contributing and managing patterns title: Validated Patterns - Tested tier -weight: 53 +weight: 54 aliases: /contribute/tested/ --- @@ -51,23 +51,23 @@ These are optional or desirable features, but their absence does not hinder the A {tested} pattern must continue to meet the following criteria to remain in the {tested} tier: -* A {tested} pattern must conform to the common technical link:/contribute/implementation/[implementation requirements]. -* A {tested} pattern must be meaningful without specialized hardware, including flavors of architectures not explicitly supported. +. A {tested} pattern must conform to the common technical link:/contribute/implementation/[implementation requirements]. +. A {tested} pattern must be meaningful without specialized hardware, including flavors of architectures not explicitly supported. + Qualification is a {solution-name-upstream} Technical Oversight Committee (TOC) decision with input from the pattern owner. -* A {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. -* A {tested} pattern must include a standardized architecture drawing, created with (or at least conforming to) the standard {solution-name-upstream} tooling. -* A {tested} pattern must include a written guide for others to follow when demonstrating the pattern. -* A {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. +. A {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. +. A {tested} pattern must include a standardized architecture drawing, created with (or at least conforming to) the standard {solution-name-upstream} tooling. +. A {tested} pattern must include a written guide for others to follow when demonstrating the pattern. +. A {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: link:https://docs.google.com/document/d/12KQhdzjVIsxRURTnWAckiEMB3_96oWBjtlTXi1q73cg/view[Validating an Industrial Edge Deployment]. - ++ //TODO: Convert above link to adoc -* A {tested} pattern must nominate at least one currently supported {rh-ocp} release to test against. -* A {tested} pattern must ensure the test plan passes at least once per quarter. -* A {tested} pattern must create a publicly available JSON file (for example, in an AWS bucket) that records the result of the latest test for each combination of pattern, platform, and {rh-ocp} version. See link:/learn/test-artifacts/[testing artifacts]. +. A {tested} pattern must nominate at least one currently supported {rh-ocp} release to test against. +. A {tested} pattern must ensure the test plan passes at least once per quarter. +. A {tested} pattern must create a publicly available JSON file (for example, in an AWS bucket) that records the result of the latest test for each combination of pattern, platform, and {rh-ocp} version. See link:/contribute/test-artifacts/[testing artifacts]. [NOTE] ==== @@ -77,8 +77,8 @@ A {tested} pattern *does not* imply an obligation of support for partner or comm [id="should-tested-tier"] === Should -* A {tested} pattern should be broadly applicable. -* A {tested} pattern should focus on functionality not performance. +. A {tested} pattern should be broadly applicable. +. A {tested} pattern should focus on functionality not performance. [id="can-tested-tier"] === Can