-
Notifications
You must be signed in to change notification settings - Fork 210
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.
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
Establishing Comprehensive Guidelines for Component Maturity in Kubeflow #709
Comments
@akgraner maybe you can add some perspective based on your experience from other communities. |
@StefanoFioravanzo thanks for this work. My initial view is that the original guidelines are a good starting place. They should be updated and they may need to be adapted to incorporate the CNCF graduation requirements. I like initially focusing on the stable, 1.0, graduated guidelines because of our outstanding CNCF workload and requirements. I think many components are considered stable and having a checklist will be a best practice to help deliver consistent quality and user experience. My concern with starting with alpha is that some components might want to build functionality rather than admin functionality (i.e. full multi-user), and I kinda would like to leave the alpha, beta definitions somewhat flexible, but I am open other opinions. |
Historically, we never had an extensive and clearly defined maturity model for our components, covering the entire lifecycle from “new alpha” all the way to “stable with long term support”. We need a well-defined framework to gauge component maturity, now more than ever, to set expectations right, to allow Kubeflow release teams to have a decision making playbook and work together with WG leads to ensure the quality and stability of components.
Current State and Challenges:
Despite having a versioning scheme indicating alpha, beta, and stable stages, as documented in our support policies, Kubeflow currently lacks detailed guidelines for component maturity. This absence makes it challenging for component owners to understand what is required to progress through these stages. Moreover, the original guidelines on what constitutes a "stable" component, available here, are outdated and were crafted by contributors who are no longer active in our community.
The critical missing parts are definitions of requirements to qualify a component as “alpha” but ready to be included in a release, and the graduation criteria to beta and then stable. Tying together this maturity model with the support model is also required.
Why Better Guidelines are Important:
Guideline Development:
My proposal is to rework our outdated “Guidelines for Applications Requirements”, focusing first on “alpha” requirements for new components to be accepted in a release. Some high level topics that these guidelines should focus on (some of these are already addressed in existing doc) are: code stability, testing infrastructure, documentation, upgrades and multi-version support, community and user adoption, feature completeness, working group maturity.
Additional Considerations:
Please share your thoughts @jbottum @andreyvelich @terrytangyuan @johnugeorge @james-jwu @kubeflow/release-managers
The text was updated successfully, but these errors were encountered: