Discuss the future of models-webapp

[rimolive]

/kind feature

Describe the solution you'd like
[A clear and concise description of what you want to happen.]
The models-webapp repo is a UI for Kubeflow to expose KServe to the Kubeflow Central Dashboard. Since KServe was moved out to KF, this repo is not maintained by anyone.

This repo is still required by Kubeflow, and we need to discuss what we should do to keep maintaining it in order to keep exposing KServe to Kubeflow Central Dashboard.

Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]

Links to the design documents:
[Optional, start with the short-form RFC template to outline your ideas and get early feedback.]
[Required, use the longer-form design doc template to specify and discuss your design in more detail]

[yuzisun]

@rimolive we are looking for people to step up to take ownership of the repo, but you are right at this point there is no active maintainer for this webapp. A lot of our kserve maintainers are backend developers and do not have much frontend experience. Also most KServe adopters may have their own requirement for the kserve UX experience which makes it hard to invest on a common UI component. If kserve webapp is an important component of Kubeflow we’d like to take whatever suggestions to keep this maintained.

[rimolive]

Can we consider as an option move this repo to kubeflow org? Since it is strongly coupled with Kubeflow UI we may consider move to kubeflow org and look for UI contributors.

[yuzisun]

I do not have strong opinion on this, would love to hear web app stakeholder's thought. cc @kimwnasptd @terrytangyuan

[terrytangyuan]

If it's strongly coupled with Kubeflow UI, then it makes sense to move to Kubeflow org. However, I am not 100% sure if that could solve the problem of lacking UI contributors though.

[rimolive]

It won't solve near-term, but I know there are some frontend developers interested in contributing with Kubeflow UI.

[terrytangyuan]

Maybe it would be a good idea to gauge some interest in Kubeflow community calls before we make a decision on whether to transfer the repo.

[yuzisun]

Maybe it would be a good idea to gauge some interest in Kubeflow community calls before we make a decision on whether to transfer the repo.

Ye let’s discuss this in the kubeflow community calls.

[StefanoFioravanzo]

@terrytangyuan I don't think that talking about this during a Kubeflow community call is a good signal as to whether we should move or not. Interested contributors may or may not participate, and may or may not even be part of the Kubeflow community just yet.

Let's think about this holistically:

1. Does it make sense to move the UI app of such an important component out of its organization? Does it help with building a UI-community longer term?
2. How does this decoupling affect roadmap sync with backend features?
3. How does this promote visibility and new contributors?

Dan said two important things:

a.

A lot of our kserve maintainers are backend developers and do not have much frontend experience.

b.

Also most KServe adopters may have their own requirement for the kserve UX experience which makes it hard to invest on a common UI component.

(a) is a problem in the Kubeflow community as well. We are not going to solve this just by moving the repo.
(b) is a different kind of problem. It's about adoption and positioning of the web app. I can see two solutions for this one

1. We move the repo to Kubeflow. This can bring more challenges in terms of longer term strategy for KServe, roadmap sync, community outreach etc. It would definitely feel a little bit out of place. But it also simplifies development in terms of UX guidelines adoptions and common components.
2. Rename the repo to kserve/kubeflow-web-app and make this app a specific Kubeflow integration project. Part of the charter of this repo can be to stay aligned with Kubeflow's design language and common components, since it's specifically targeted at Kubeflow.
   This option can be particularly effective if KServe leaders agree on promoting these efforts within the KServe community.

To @rimolive 's point

I know there are some frontend developers interested in contributing with Kubeflow UI

We can try to direct these folks to this repo, even if it's outside of Kubeflow's scope.