Adding a proposal for new projects to be included in KF #741
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change | ||||
|---|---|---|---|---|---|---|
| @@ -0,0 +1,182 @@ | ||||||
| # New Project Project Application | ||||||
|
There was a problem hiding this comment. I am wondering what should be the goal of community repo vs Kubeflow website ? So maybe:
Any thoughts ? There was a problem hiding this comment. That works for me! In the community repo we could just leave this as the template, right? I'd be happy to create a website PR to incorporate this once the leads approve the process. |
||||||
|
|
||||||
| Please see the [proposals/new-project-addition-process.md](Documentation) to | ||||||
|
There was a problem hiding this comment.
Suggested change
|
||||||
| better understand the full process for submitting a new project. | ||||||
|
|
||||||
| In short, copy this Application Template and populate the document. | ||||||
| --!> | ||||||
|
|
||||||
|
|
||||||
| ## Background information | ||||||
|
There was a problem hiding this comment. Should we try to learn something from CNCF action items: https://github.com/cncf/toc/blob/main/.github/ISSUE_TEMPLATE/template-incubation-application.md#required ?
|
||||||
|
|
||||||
| 1. Submitter Name | ||||||
| - | ||||||
|
|
||||||
| 2. Submitter’s relationship to project / title | ||||||
| - | ||||||
|
|
||||||
| 3. Project Name | ||||||
| - | ||||||
|
|
||||||
| 4. Why this project is valuable to the Kubeflow Community | ||||||
|
There was a problem hiding this comment. List integrations with Kubeflow Core components? |
||||||
| - | ||||||
|
|
||||||
| 5. Short Description / Functionality | ||||||
| - | ||||||
|
|
||||||
| 6. Website | ||||||
| - | ||||||
|
|
||||||
| 7. GitHub repository | ||||||
| - | ||||||
|
|
||||||
| 8. 1st Release date | ||||||
| - | ||||||
|
|
||||||
| 9. Project Meeting Times | ||||||
| - | ||||||
|
|
||||||
| 10. Meeting Notes (link) | ||||||
| - | ||||||
|
|
||||||
| 11. Installation Documentation (provide status and link) | ||||||
| - | ||||||
|
|
||||||
| 12. Application Documentation (provide status and link) | ||||||
|
There was a problem hiding this comment. Is it architecture documents ? |
||||||
| - | ||||||
|
|
||||||
| 13. Security Profile (CVE scanning) | ||||||
| - | ||||||
|
|
||||||
| 14. Ownership / Legal Profile (license type, any potential issues for CNCF) | ||||||
| - | ||||||
|
|
||||||
| 15. Kubernetes native (K8s version) | ||||||
|
There was a problem hiding this comment. We need to explain what do we mean here by K8s native. Does it mean being cloud native/micro-service architecture or something else ? |
||||||
| - | ||||||
|
|
||||||
| 16. AuthN/Z, Isolation mechanisms | ||||||
| - | ||||||
|
|
||||||
| 17. Project Roadmap | ||||||
| - | ||||||
|
|
||||||
| 18. Other Information | ||||||
| - | ||||||
|
|
||||||
| ## Metrics | ||||||
|
|
||||||
| Number of Contributors | ||||||
|
There was a problem hiding this comment. Probably, we should explain how these metrics should be measured. For example, number of PRs from different contributors in the last year. |
||||||
| - [ ] 1 | ||||||
| - [ ] <10 | ||||||
| - [ ] 10+ | ||||||
|
|
||||||
| Number of Users | ||||||
| - [ ] 1 | ||||||
| - [ ] <10 | ||||||
| - [ ] 10+ | ||||||
|
|
||||||
| GitHub Pull Requests in the last 90 days | ||||||
| - [ ] 1 | ||||||
| - [ ] <10 | ||||||
| - [ ] 10+ | ||||||
|
|
||||||
| Number of Releases | ||||||
| - [ ] No release | ||||||
| - [ ] 1 release | ||||||
| - [ ] 2+ releases | ||||||
|
|
||||||
| Downloads | ||||||
|
There was a problem hiding this comment. Download of what ? Packages, Helm Charts, Docker images. There was a problem hiding this comment. I meant packages as we could get them easily here: https://www.pepy.tech/projects/feast?versions=0.* |
||||||
| - [ ] <100 | ||||||
| - [ ] <10k | ||||||
| - [ ] 10k+ | ||||||
|
|
||||||
| ## Kubeflow Specific Questions | ||||||
|
|
||||||
| 1. Kubeflow specific Roadmap | ||||||
| - [ ] Yes | ||||||
| - [ ] No | ||||||
| - Link | ||||||
|
|
||||||
| 2. Workflows that integrate with Kubeflow Components | ||||||
| - [ ] 1 | ||||||
| - [ ] 2 | ||||||
| - [ ] 3+ | ||||||
|
|
||||||
| 3. Manifest Integration | ||||||
| - [ ] Yes | ||||||
| - [ ] No | ||||||
| - [ ] Planned | ||||||
|
Comment on lines
+105
to
+108
There was a problem hiding this comment. As I said before, from my personal perspective Kubeflow Manifests should only include the bundle of Kubeflow core components. That means, we don't need to ask this question. There was a problem hiding this comment. To be transparent, this is 99% of the reason I helped write the document with Josh, so I'd like to include this. There was a problem hiding this comment. See comment above: #741 (comment) |
||||||
|
|
||||||
| 4. Installation | ||||||
| - [ ] Testing | ||||||
| - [ ] Stand alone | ||||||
| - [ ] Part of Manifests | ||||||
| - [ ] Part of Distributions | ||||||
|
Comment on lines
+110
to
+114
There was a problem hiding this comment. I think, we should clarify this part. |
||||||
|
|
||||||
| 5. Application | ||||||
| - [ ] Testing | ||||||
| - [ ] Stand alone | ||||||
| - [ ] Part of Kubeflow workflow | ||||||
|
There was a problem hiding this comment. What do you mean by "Part of Kubeflow workflow"? |
||||||
|
|
||||||
| 6. Installation Documentation (Current Quality) | ||||||
| - [ ] Good | ||||||
| - [ ] Fair | ||||||
| - [ ] Part of Kubeflow | ||||||
|
|
||||||
| 7. Application Documentation (Current Quality) | ||||||
| - [ ] Good | ||||||
| - [ ] Fair | ||||||
| - [ ] Part of Kubeflow | ||||||
|
|
||||||
| 8. Kubeflow Website Documentation | ||||||
| - [ ] Yes | ||||||
| - [ ] No | ||||||
| - Pull Request # | ||||||
|
Comment on lines
+121
to
+134
There was a problem hiding this comment. This won't be the case since we should remove all non-Kubeflow docs from the https://www.kubeflow.org/ |
||||||
|
|
||||||
| 9. Distributions position on added testing, docs | ||||||
|
There was a problem hiding this comment. How can the project be part of Kubeflow distribution if it is not part of Kubeflow ? |
||||||
| - [ ] 0 Distribution | ||||||
| - [ ] 1 Distribution | ||||||
| - [ ] 2+ Distributions | ||||||
|
|
||||||
| 10. Blog/Social Media announcements | ||||||
| - [ ] Yes | ||||||
| - [ ] No | ||||||
| - Pull Request # | ||||||
|
Comment on lines
+141
to
+144
There was a problem hiding this comment. Do you mean if project has their own social media resources ? |
||||||
|
|
||||||
| ## Level of Integration and Support Sought by Kubeflow | ||||||
|
|
||||||
| 1. What level? | ||||||
| - [ ] Add-on | ||||||
| - [ ] Core | ||||||
|
Comment on lines
+148
to
+150
|
||||||
|
|
||||||
| 2. IP Ownerhsip | ||||||
| - [ ] Stand Alone | ||||||
| - [ ] Merge into Kubeflow/CNCF | ||||||
|
Comment on lines
+152
to
+154
There was a problem hiding this comment. As I said, this might be out of scope of this proposal. |
||||||
|
|
||||||
| 3. Kubeflow Working Group | ||||||
| - [ ] None | ||||||
| - [ ] New | ||||||
| - [ ] Part of Existing | ||||||
|
Comment on lines
+156
to
+159
There was a problem hiding this comment. None can't be an option, isn't ? |
||||||
|
|
||||||
| 4. Posting Meetings on Kubeflow Calendar | ||||||
| - [ ] Yes | ||||||
| - [ ] No | ||||||
|
Comment on lines
+161
to
+163
There was a problem hiding this comment. I think, this should be a requirement, isn't ? |
||||||
|
|
||||||
| 5. Use of Zoom Accounts | ||||||
| - [ ] Yes | ||||||
| - [ ] No | ||||||
|
|
||||||
| 6. Repository Ownership | ||||||
| - [ ] Yes | ||||||
| - [ ] No | ||||||
|
|
||||||
| 7. Pull request Approvers | ||||||
|
There was a problem hiding this comment. What kind of support is required for this ? |
||||||
| - [ ] Yes | ||||||
| - [ ] No | ||||||
|
|
||||||
| 8. Posting on Kubeflow Social Media, blog, and website | ||||||
| - [ ] Yes | ||||||
| - [ ] No | ||||||
| - [ ] Collaborate | ||||||
|
|
||||||
|
There was a problem hiding this comment. One question should be on list of maintainers and affiliation to prove diversity |
||||||
|
|
||||||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,36 @@ | ||
| ## Motivation | ||
|
There was a problem hiding this comment. Can you add a Title for this doc, e.g. There was a problem hiding this comment. I think, this proposal should also include the following:
There was a problem hiding this comment. I think, we also require to establish process for Project Onboarding if Kubeflow community accepted this project. |
||
| As Kubeflow has become a well established ecosystem and community, several | ||
| projects may want to be incorporated into Kubeflow in different capacities. | ||
|
|
||
| That may include: | ||
| 1. Project Donation | ||
| 2. Inclusion in the Manifest | ||
| 3. Inclusion in documentation as an add on | ||
|
Comment on lines
+5
to
+8
There was a problem hiding this comment. I would decrease the scope of this proposal to only: Project Donation. There was a problem hiding this comment. I think the process should probably be the same but the requested outcome should be different. I think really we're just formalizing what standards we have for Feast and KServe today and I'd like to be able to include Feast into the manifest with this process. That is my personal goal. There was a problem hiding this comment. From my point of view, this proposal should be dedicated to all future projects that want to join Kubeflow ecosystem. As we discussed before, we might want to re-consider adding external add-ons to the manifests repo, since the manifests repo should be an aggregation of Kubeflow components. There was a problem hiding this comment.
Let me share how I think about this. On the Kubeflow main page, we have:
I view Kubeflow as the best open-source MLOps platform that not only offers a community sharing best practices but also provides all the core components needed to build a successful ML platform. I think that is what drives the best outcome for both users and Kubeflow. Each component should be strong independently and work even better when deployed along with the other components. That means that components may change on occasion but it also means that a holistic platform is more important than recommending a technology that isn't good for the community. And I think that's ultimately why some add-ons should be included in the manifest. We should prioritize the MLE-experience and setting up users for success over who owns which project. That said, many of the components are already the best, we just have some gaps. :) There was a problem hiding this comment. @andreyvelich @franciscojavierarceo I want get some clarification, when you mention we need to include/or not manifests, do you guys mean as single package manifests that include core + add-ons or you are thinking both should be different repos and add-ons not even present in separate package in manifests repo? There was a problem hiding this comment.
Yeah, I agree that there are many examples for sure. I also think that we should aim to solve for like 80% of use-cases and not 20% who may always inevitably customize. In my opinion, having 80% of use cases solved by users is an impactful thing. Many organizations will benefit from this and that will help foster a healthy community. There was a problem hiding this comment.
I agree that it is always better to consolidate effort to solve the specific problem instead of building something new. @franciscojavierarceo What are your thoughts on the conformance program for Kubeflow distribution in that case? There was a problem hiding this comment. I think that would make a lot of sense. I think in order to be included into the manifest the Add-on/component/product should obviously work easily and I think it'd be the obligated of the add-on project to keep the project moving forward and working with Kubeflow or face removal. There was a problem hiding this comment. I assume you're suggesting a conformance program similar to what's available for Kubernetes (https://github.com/cncf/k8s-conformance/tree/master) There was a problem hiding this comment. Yeah, my question is how do you think we should design this conformance program for distributions if we have add-ons in Kubeflow ecosystem ? |
||
|
|
||
| This proposal aims to give guidelines and set expectations for community | ||
| members about the application process. | ||
|
|
||
| ## Goals | ||
| The goal of this proposal is to provide a clear process for being included in | ||
| the Kubeflow ecosystem. | ||
|
|
||
| ## Non-Goals | ||
| Give specific recommendations for evaluating any individual project. | ||
|
|
||
| ## UI or API | ||
| N/A | ||
|
|
||
| ## Design | ||
| Project owners or maintainers will apply for inclusion by following a four | ||
| step process. submitting the | ||
|
|
||
| The process is outlined in 4 steps: | ||
|
There was a problem hiding this comment. We might want to also ask to:
|
||
|
|
||
| 1. Submit a Pull Request with the [../add-ons/APPLICATION_TEMPLATE.md](application form). | ||
|
There was a problem hiding this comment. I would call this folder |
||
| 2. Schedule meeting with Kubeflow Community to introduce and collect feedback on | ||
| the application. | ||
| 3. Schedule meeting with Kubeflow Steering Committee for initial vote and to collect feedback. | ||
| 4. Merge or close the Pull Request depending upon the outcome of the final vote. | ||
|
|
||
| ## Alternatives Considered | ||
| N/A | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would move this doc to
how-tosection: https://github.com/kubeflow/community/tree/master/how-to.