Skip to content

[docs/component-stability.md] Add criteria for graduating between stability levels #11864

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 12 commits into from
Apr 14, 2025
Merged

[docs/component-stability.md] Add criteria for graduating between stability levels #11864

Changes from 9 commits
Commits
Show all changes
12 commits
Select commit Hold shift + click to select a range
09fda80
Add criteria for graduating between stability levels
mx-psi Dec 12, 2024
dd4de0b
Apply suggestions from code review
mx-psi Dec 12, 2024
b25a19a
make even more explicit that the component needs to fulfill the requi…
mx-psi Dec 12, 2024
859ece3
Merge branch 'main' into mx-psi/codeowner-requirements
mx-psi Dec 12, 2024
dc12edb
Merge branch 'main' into mx-psi/codeowner-requirements
mx-psi Dec 17, 2024
d551fa7
Merge remote-tracking branch 'origin/main' into mx-psi/codeowner-requ…
mx-psi Dec 19, 2024
a607b68
Merge branch 'main' into mx-psi/codeowner-requirements
mx-psi Dec 24, 2024
8b96cc9
Merge branch 'main' into mx-psi/codeowner-requirements
mx-psi Jan 8, 2025
14ee096
Merge branch 'main' into mx-psi/codeowner-requirements
mx-psi Mar 24, 2025
98b969f
Remove mentions to vendor-specific components
mx-psi Apr 9, 2025
58b2aff
Merge branch 'main' into mx-psi/codeowner-requirements
mx-psi Apr 9, 2025
a95cdcb
Merge branch 'main' into mx-psi/codeowner-requirements
mx-psi Apr 10, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
38 changes: 38 additions & 0 deletions docs/component-stability.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -260,6 +260,44 @@ To move within the 'Maintained' ladder ("graduate"), the process for doing so is
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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think there should be a commitment from codeowners that there is a SLA for first response on bug issues.
The commitment should be measured in days.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This raises some questions for me including:

  • What happens when people go on vacation/have a kid/[insert activity here that leads to a prolonged period of absence]?
  • What happens if people don't follow this SLA? Typically an SLA means that you pay if you don't meet a certain standard, how do you "pay" here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It also raises the question of how we measure that. Do we have any automation in place for it?

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.

## Deprecation Information

When a component is moved to deprecated, a deprecation section should indicate the date it was deprecated
Expand Down
Loading