Skip to content
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

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

Draft
wants to merge 4 commits into
base: main
Choose a base branch
from
Draft

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

Changes from all commits
Commits
Show all changes
4 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
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
50 changes: 50 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,53 @@ 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.
mx-psi marked this conversation as resolved.
Show resolved Hide resolved
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.
Comment on lines +115 to +119
Copy link
Contributor

Choose a reason for hiding this comment

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

this is formalizing the existing practice and I agree with it.


## Beta to stable
mx-psi marked this conversation as resolved.
Show resolved Hide resolved

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?

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.
Loading