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 1 commit
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
49 changes: 49 additions & 0 deletions docs/component-stability.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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.
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 the thay have
been reviewed and replied to appropriately.
Loading