Add KEP template to be used by wider Kubeflow community

[anishasthana]

cc @andreyvelich

[andreyvelich]

Thank you for doing this @anishasthana, this should significantly improve Kubeflow proposals process.
cc WG leads for review
@kubeflow/wg-training-leads @kubeflow/wg-data-leads @kubeflow/wg-pipeline-leads @kubeflow/kubeflow-steering-committee @kubeflow/wg-manifests-leads @kubeflow/wg-notebooks-leads @kubeflow/wg-deployment-leads @Electronic-Waste @kannon92 @astefanutti @franciscojavierarceo @juliusvonkohout

[kannon92]

In k8s, we usually have some make targets to help make sure the TOC is up-to-date. May be worth bringing that in.

[andreyvelich]

In k8s, we usually have some make targets to help make sure the TOC is up-to-date. May be worth bringing that in.

@kannon92 Can you show example of make targets please?

[kannon92]

In k8s, we usually have some make targets to help make sure the TOC is up-to-date. May be worth bringing that in.

@kannon92 Can you show example of make targets please?

Kueue has https://github.com/kubernetes-sigs/kueue/blob/main/hack/update-toc.sh

And they have a hack/verify-toc.sh.

There are make files that call these scripts to verify that toc.

[andreyvelich]

Kueue has https://github.com/kubernetes-sigs/kueue/blob/main/hack/update-toc.sh

And they have a hack/verify-toc.sh.

There are make files that call these scripts to verify that toc.

@kannon92 oh I see, my point was that since GitHub natively supports TOC do we really need it as I mentioned here: #805 (comment)
E.g. it can help us to avoid unnecessary sync scripts: update-toc.

[kannon92]

Kueue has https://github.com/kubernetes-sigs/kueue/blob/main/hack/update-toc.sh
And they have a hack/verify-toc.sh.
There are make files that call these scripts to verify that toc.

@kannon92 oh I see, my point was that since GitHub natively supports TOC do we really need it as I mentioned here: #805 (comment) E.g. it can help us to avoid unnecessary sync scripts: update-toc.

I just copy and paste this for jobset/kueue. I don't really know what it does.

[andreyvelich]

Thank you for doing this @anishasthana!
/lgtm

[anishasthana]

@andreyvelich should we think about lazy consensus for this PR? Don't want it to hang around forever :)

[franciscojavierarceo]

+1 i think we should think about lazy consensus probably more generally.

We have way too many PRs growing stale because someone forgot stuff. Terrible experience for users.

[thesuperzapper]

I have no opinion on this specific PR, but I want to highlight that code PRs must be reviewed by an approver who has worked on the code before, so they couldn't be done by lazy consensus.

[andreyvelich]

Sure, let's move forward with this, but I agree with @thesuperzapper that we need to have more eyes on the important PRs before merging them.
/hold cancel

[andreyvelich]

/approve

[google-oss-prow]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: andreyvelich

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 [andreyvelich]

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

[franciscojavierarceo]

Sure, let's move forward with this, but I agree with @thesuperzapper that we need to have more eyes on the important PRs before merging them. /hold cancel

Yeah, I agree.