Disable issue creation and update README

[andreyvelich]

Related: #7549

In accordance of @kubeflow/kubeflow-steering-committee suggestion, I disabled issue creation and updated README.

That should help us with migration, since new users won't use kubeflow/kubeflow to open issues. After migration of existing issues, we can disable issue creation.

I am happy to improve language after we finalize statement in this PR: kubeflow/website#3755.

/assign @kubeflow/kubeflow-steering-committee @kubeflow/wg-manifests-leads @kubeflow/wg-training-leads @kubeflow/wg-pipeline-leads @kubeflow/wg-training-leads @kubeflow/wg-automl-leads @kubeflow/wg-notebooks-leads

/hold for review

[thesuperzapper]

@andreyvelich just want to say, we MUST NOT merge this until we have migrated the code to the kubeflow/notebooks and kubeflow/dashboard.

[andreyvelich]

@andreyvelich just want to say, we MUST NOT merge this until we have migrated the code to the kubeflow/notebooks and kubeflow/dashboard.

Can you explain what is your major concern to not merge this PR @thesuperzapper ?
This will just redirect users to the correct repos to create issues and help WG leads to triage them in the future.
Otherwise, users will still use kubeflow/kubeflow to create issues, and it will slow-down the migration.

[terrytangyuan]

+1

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: terrytangyuan

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [terrytangyuan]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[andreyvelich]

cc @kubeflow/wg-data-leads for feedback

[juliusvonkohout]

@thesuperzapper you can still continue with PRs and development, this is just for new issues.
In general
/lgtm

[juliusvonkohout]

I recently cleaned up 15 issues there in #7549 (comment) , but they keep coming (again 15+ new ones)

[juliusvonkohout]

@andreyvelich I recommend do add this stalebot PR to kubeflow/kubeflow as well kubeflow/manifests#2760 .

[andreyvelich]

stalebot PR to kube

@juliusvonkohout Do you think we still need stalebot if we can just go over 197 issues and close the idle issues ?

[thesuperzapper]

This is incorrect, only the following apps (see #7549) are going to be in kubeflow/dashboard:

• Central Dashboard
• Profile Controller
• KFAM
• PodDefaults

The CRUD Web Apps and PVC Viewer will live in kubeflow/notebooks.

[andreyvelich]

@thesuperzapper @kimwnasptd Why are we planning to maintain CRUD Web Apps in kubeflow/notebooks since it is used in almost all Kubeflow UIs (Katib, Models WebApp, Notebooks, PVC Viewer) ?

[thesuperzapper]

@andreyvelich we discussed it a lot in #7549, but the gist of it is that the biggest usage of the CRUD code is in Kubeflow Notebooks. Also, stuff like the PVC Viewer is seen as "part of Kubeflow notebooks" so it will also be in kubeflow/notebooks.

Really all that matters is that the common CRUD code stays maintained, and its easiest for the Notebooks WG to do that in the kubeflow/notebooks repo.

Finally, the kubeflow/dashboard repo is for the things which make the dashboard work, it has no dependency on the CRUD code, so makes no sense for the CRUD code to live there.

[andreyvelich]

@thesuperzapper How did you conclude that the biggest usage of CRUD is in kubeflow/notebooks ?

The common web apps handle an ability to communicate between dashboard and other web apps: https://github.com/kubeflow/kubeflow/tree/2898d0f61edf193209c82cf673608cf97c247c3a/components/crud-web-apps/common#frontend.
When @kubeflow/arrikto initiated this component, the intention was to provide unify styles across all Kubeflow web apps. So users will get similar experience by using various Kubeflow UIs.

If we don't maintain it in the dashboard repository, how can we make sure that other UIs are functional and problems can be addressed ?
For example, Katib UI CI is broken since April 19th by migrating to the latest Kubeflow commit version: kubeflow/katib#2313
cc @orfeas-k

[StefanoFioravanzo]

It's not just the Katib web app, let's not forget about KServe web app, which makes extensive use of this common code.

@ederign this conversation is very relevant to our recent discussion. How and where we maintain this common code will influence the success of these various web apps. I think we should align the conversation and if you want to take the lead on defining broad best practices and recommendation, this may be a good place to start

[thesuperzapper]

We need to wait (for turning off issues on kubelfow/kubeflow) until we actually create kubeflow/dashboard as otherwise there will be no place for people to raise issues about the dashboard. Also, even though the kubeflow/notebooks repo has been created, it's probably not the best place for notebooks issues until after the code has migrated.

Since I don't want to block other updates proposed in this PR (like adding links to the components and updating the readme), let's just keep the issues for Notebooks and Dashboard pointed at kubeflow/kubeflow for now.

@kimwnasptd as the other Notebook lead (since we maintain these components) can you please share your opinion.

---

Also, there are lots of people who use the kubeflow/kubeflow repo to ask questions about all kinds of things, perhaps we should enable GitHub Discussions and point people to them for general discussions not related to any component.

And kubeflow/community for cross-project discussions.

[andreyvelich]

We need to wait (for turning off issues on kubelfow/kubeflow) until we actually create kubeflow/dashboard as otherwise there will be no place for people to raise issues about the dashboard.

We can create kubeflow/dashboard repo this week. @zijianjoy can help us with it.

Also, even though the kubeflow/notebooks repo has been created, it's probably not the best place for notebooks issues until after the code has migrated.

Why it is not the best place ?
Eventually, all Kubeflow Notebooks issues should be in this repo since users won't be able to create issues in the kubeflow/kubeflow.
During the migration, we can just track issues in kubeflow/notebooks and kubeflow/dashboard.

let's just keep the issues for Notebooks and Dashboard pointed at kubeflow/kubeflow for now.

@thesuperzapper Can you explain why do you need it if that will just slow down the migration for us ?

[andreyvelich]

Also, there are lots of people who use the kubeflow/kubeflow repo to ask questions about all kinds of things, perhaps we should enable GitHub Discussions and point people to them for general discussions not related to any component

Sure, this is good idea.
I can add this to the README and issue template.
If users have any questions about Kubeflow Community or Kubeflow Project overall, they can use kubeflow/community repo.

I feel that opening GitHub Discussions should be a separate discussion, since first of all we should solve the problem when users ask questions somewhere, and they don't get any response from the Kubeflow community.

[juliusvonkohout]

stalebot PR to kube

@juliusvonkohout Do you think we still need stalebot if we can just go over 197 issues and close the idle issues ?

It is about adding a single file and enforces it. If not for kubeflow/kubeflow then at least for the new repositories.

[juliusvonkohout]

If users have any questions about Kubeflow Community or Kubeflow Project overall, they can use kubeflow/community repo.

I feel that opening GitHub Discussions should be a separate discussion, since first of all we should solve the problem when users ask questions somewhere, and they don't get any response from the Kubeflow community.

Yes i think kubeflow/kubeflow should only be a landing page with with redirect information without discussions or issues.

[andreyvelich]

It is about adding a single file and enforces it. If not for kubeflow/kubeflow then at least for the new repositories.

Yes, for the new repos we should enable it, like we did for other repos.

[rimolive]

/lgtm