I would move this doc to how-to section: https://github.com/kubeflow/community/tree/master/how-to.

I am wondering what should be the goal of community repo vs Kubeflow website ?
We discussed before with @StefanoFioravanzo @hbelmiro @kubeflow/kubeflow-steering-committee that we want to move all governance docs to the https://www.kubeflow.org.

So maybe:

• Proposals should be located in community repo
• Actual documents should be on kubeflow.org

Any thoughts ?

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.

Can you add a Title for this doc, e.g.

# KEP-748: Donating projects to Kubeflow ecosystem

I would decrease the scope of this proposal to only: Project Donation.
I feel that we need more discussions whether we should include any other projects in the Kubeflow Manifests and Kubeflow documentation as add on.

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.

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.

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.

Let me share how I think about this.

On the Kubeflow main page, we have:

Kubeflow makes artificial intelligence and machine learning simple, portable, and scalable. We are an ecosystem of Kubernetes based components for each stage in the AI/ML Lifecycle with support for best-in-class open source tools and frameworks.

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. :)

CC @terrytangyuan @jbottum @thesuperzapper

@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?

Argo, Tekton, Airflow is not a single example. There are many other projects that have overlaps: Ray and Training Operator/KServe/Katib, Volcano vs Training Operator, Kaito vs KServe, MLFlow vs Model Registry, etc.
Eventually, we have users who just use native Kubernetes workloads for MLOps/LLMOps.

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.

Would you want to make a Kubeflow Feature Store or use Feast?

I agree that it is always better to consolidate effort to solve the specific problem instead of building something new.
Unfortunately, it is hard to consolidate effort between cloud native, AI/ML, and Kubeflow communities.

@franciscojavierarceo What are your thoughts on the conformance program for Kubeflow distribution in that case?
When distribution can call themself Kubeflow Certified ?

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.

I assume you're suggesting a conformance program similar to what's available for Kubernetes (https://github.com/cncf/k8s-conformance/tree/master)

Yeah, my question is how do you think we should design this conformance program for distributions if we have add-ons in Kubeflow ecosystem ?
Should every Kubeflow distribution support all add-ons and who will create the test suites for those add-ons ?

As I said, this might be out of scope of this proposal.

None can't be an option, isn't ?

I think, this should be a requirement, isn't ?

What kind of support is required for this ?

I think, we also require to establish process for Project Onboarding if Kubeflow community accepted this project.
For example, for Spark Operator we had this tracking issue: kubeflow/spark-operator#1928

List integrations with Kubeflow Core components?

One question should be on list of maintainers and affiliation to prove diversity

Will update