From 09fda8090defe66d1e79a209db8b2bf000238d8b Mon Sep 17 00:00:00 2001 From: Pablo Baeyens Date: Thu, 12 Dec 2024 12:46:04 +0100 Subject: [PATCH 1/4] Add criteria for graduating between stability levels --- docs/component-stability.md | 49 +++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) diff --git a/docs/component-stability.md b/docs/component-stability.md index 1039b90eed4..51666abd264 100644 --- a/docs/component-stability.md +++ b/docs/component-stability.md @@ -78,3 +78,52 @@ Components that were accepted based on being vendor-specific components will be they have no active code owners from the vendor even if there are other code owners listed. As part of being marked unmaintained, we'll attempt to contact the vendor to notify them of the change. Other active code owners may petition for its continued maintenance if they want, at which point the component will no longer be considered vendor-specific. + +## Graduating between stability levels + +Components can graduate between stability levels. The process for doing so is as follows: + +1. One of the component owners should file an issue with the 'Graduation' issue template to request + the graduation. +2. An approver is assigned in a rotating basis to evaluate the request and provide feedback. For + vendor specific components, the approver should be from a different employer to the one owning + the component. +3. If approved, a PR to change the stability level should be opened and MUST be approved by all + listed code owners. + +## Graduation criteria + +In addition to the requirements outlined above, additional criteria should be met before a component +can graduate to a higher stability level. These ensure that the component is ready for the increased +usage and scrutiny that comes with a higher stability level, and that the community around it is +sufficiently healthy. + +If the graduation criteria are not met, the approver should provide feedback on what is missing and +how to address it. The component owners can then address the feedback and re-request graduation on +the same issue. + +## In development to alpha + +No additional criteria are required to graduate from development to alpha. + +## Alpha to beta + +To graduate any signal from alpha to beta on a component: +1. The component MUST have at least two active code owners. +2. The code owners for non-vendor-specific components SHOULD have at least two different employers. +3. Within the 30 days prior to the graduation request, the code owners MUST have reviewed and + replied to at least 80% of the issues and pull requests opened against the component. This + excludes general PRs or issues that are not specific to the component itself (e.g. repo-wide API + updates). It is not necessary that the issues and PRs are closed or merged, but the thay have + been reviewed and replied to appropriately. + +## Beta to stable + +To graduate any signal from beta to stable on a component: +1. The component MUST have at least three active code owners. +2. The code owners for non-vendor-specific components SHOULD have at least two different employers. +3. Within the 60 days prior to the graduation request, the code owners MUST have reviewed and + replied to at least 80% of the issues and pull requests opened against the component. This + excludes general PRs or issues that are not specific to the component itself (e.g. repo-wide API + updates). It is not necessary that the issues and PRs are closed or merged, but the thay have + been reviewed and replied to appropriately. From dd4de0bb7e7a556bc010ed202a317187585b52c8 Mon Sep 17 00:00:00 2001 From: Pablo Baeyens Date: Thu, 12 Dec 2024 13:19:21 +0100 Subject: [PATCH 2/4] Apply suggestions from code review Co-authored-by: Christos Markou --- docs/component-stability.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/component-stability.md b/docs/component-stability.md index 51666abd264..7a73fd3bfcb 100644 --- a/docs/component-stability.md +++ b/docs/component-stability.md @@ -114,7 +114,7 @@ To graduate any signal from alpha to beta on a component: 3. Within the 30 days prior to the graduation request, the code owners MUST have reviewed and replied to at least 80% of the issues and pull requests opened against the component. This excludes general PRs or issues that are not specific to the component itself (e.g. repo-wide API - updates). It is not necessary that the issues and PRs are closed or merged, but the thay have + updates). It is not necessary that the issues and PRs are closed or merged, but that they have been reviewed and replied to appropriately. ## Beta to stable @@ -125,5 +125,5 @@ To graduate any signal from beta to stable on a component: 3. Within the 60 days prior to the graduation request, the code owners MUST have reviewed and replied to at least 80% of the issues and pull requests opened against the component. This excludes general PRs or issues that are not specific to the component itself (e.g. repo-wide API - updates). It is not necessary that the issues and PRs are closed or merged, but the thay have + updates). It is not necessary that the issues and PRs are closed or merged, but that they have been reviewed and replied to appropriately. From b25a19ad93ed85a1436801dae43f03a4a9a764df Mon Sep 17 00:00:00 2001 From: Pablo Baeyens Date: Thu, 12 Dec 2024 17:29:08 +0100 Subject: [PATCH 3/4] make even more explicit that the component needs to fulfill the requirements to be graduated --- docs/component-stability.md | 1 + 1 file changed, 1 insertion(+) diff --git a/docs/component-stability.md b/docs/component-stability.md index 7a73fd3bfcb..e56789b455b 100644 --- a/docs/component-stability.md +++ b/docs/component-stability.md @@ -105,6 +105,7 @@ the same issue. ## In development to alpha No additional criteria are required to graduate from development to alpha. +The component still needs to meet the general requirements for alpha components. ## Alpha to beta From cf39cdc93002d8aa6d82215a719b01e5686685c8 Mon Sep 17 00:00:00 2001 From: Pablo Baeyens Date: Tue, 17 Dec 2024 14:26:51 +0100 Subject: [PATCH 4/4] [chore][docs/component-stability.md] Add a 'Moving between stability levels' section --- docs/component-stability.md | 60 +++++++++++++------------------------ 1 file changed, 20 insertions(+), 40 deletions(-) diff --git a/docs/component-stability.md b/docs/component-stability.md index a8f7d8d3431..599ae6978f6 100644 --- a/docs/component-stability.md +++ b/docs/component-stability.md @@ -188,9 +188,27 @@ they have no active code owners from the vendor even if there are other code own owners may petition for its continued maintenance if they want, at which point the component will no longer be considered vendor-specific. -## Graduating between stability levels +## Moving between stability levels -Components can graduate between stability levels. The process for doing so is as follows: +Components can move between stability levels. The valid transitions are described in the following diagram: + +```mermaid +stateDiagram-v2 + state Maintained { + InDevelopment --> Alpha + Alpha --> Beta + Beta --> Stable + } + + InDevelopment: In Development + + Maintained --> Unmaintained + Unmaintained --> Maintained + Maintained --> Deprecated + Deprecated --> Maintained: (should be rare) +``` + +To move within the 'Maintained' ladder ("graduate"), the process for doing so is as follows: 1. One of the component owners should file an issue with the 'Graduation' issue template to request the graduation. @@ -200,44 +218,6 @@ Components can graduate between stability levels. The process for doing so is as 3. If approved, a PR to change the stability level should be opened and MUST be approved by all listed code owners. -## Graduation criteria - -In addition to the requirements outlined above, additional criteria should be met before a component -can graduate to a higher stability level. These ensure that the component is ready for the increased -usage and scrutiny that comes with a higher stability level, and that the community around it is -sufficiently healthy. - -If the graduation criteria are not met, the approver should provide feedback on what is missing and -how to address it. The component owners can then address the feedback and re-request graduation on -the same issue. - -## In development to alpha - -No additional criteria are required to graduate from development to alpha. -The component still needs to meet the general requirements for alpha components. - -## Alpha to beta - -To graduate any signal from alpha to beta on a component: -1. The component MUST have at least two active code owners. -2. The code owners for non-vendor-specific components SHOULD have at least two different employers. -3. Within the 30 days prior to the graduation request, the code owners MUST have reviewed and - replied to at least 80% of the issues and pull requests opened against the component. This - excludes general PRs or issues that are not specific to the component itself (e.g. repo-wide API - updates). It is not necessary that the issues and PRs are closed or merged, but that they have - been reviewed and replied to appropriately. - -## Beta to stable - -To graduate any signal from beta to stable on a component: -1. The component MUST have at least three active code owners. -2. The code owners for non-vendor-specific components SHOULD have at least two different employers. -3. Within the 60 days prior to the graduation request, the code owners MUST have reviewed and - replied to at least 80% of the issues and pull requests opened against the component. This - excludes general PRs or issues that are not specific to the component itself (e.g. repo-wide API - updates). It is not necessary that the issues and PRs are closed or merged, but that they have - been reviewed and replied to appropriately. - ## Versioning Components are Go modules and as such follow [semantic versioning](https://semver.org/). Go API stability guarantees are covered in the [VERSIONING.md](../VERSIONING.md) document.