Add detailed information on KEP process

[anishasthana]

cc @andreyvelich

[juliusvonkohout]

@franciscojavierarceo what do you think?

[franciscojavierarceo]

@franciscojavierarceo what do you think?

My view is that KEPs should be expected from Red Hatter's making medium to large changes. For the rest of the community, we should only encourage it. For large changes we should require it but medium changes may not warrant the overhead.

I don't expect contributors to go through the extensive writing, consensus generating, and community building that Red Hat does when most non-Red Hattters are doing this work in their leisure time.

I made some suggestions to soften the language.

All of that said though, I do think writing in general is a highly useful skill and people (of course, including myself) learn a lot from it!

[andreyvelich]

Thank you for this
cc for review
@kubeflow/wg-pipeline-leads @kubeflow/wg-training-leads @kubeflow/wg-data-leads @kubeflow/wg-automl-leads @akgraner @chasecadet @kubeflow/kubeflow-steering-committee @franciscojavierarceo @kubeflow/wg-manifests-leads @kubeflow/wg-training-leads @varodrig @kubeflow/wg-notebooks-leads @rimolive @hbelmiro

[andreyvelich]

Let's say that KEPs that affect multiple Kubeflow project should be created under kubeflow/community.
WDYT ?

[juliusvonkohout]

That does not work that well with kubeflow/manifests rootless efforts, so i would not make it a hard requirement. It can make sense in some areas, but for example helm charts, rootless, istio-cni/ambient are better located in kubeflow/manifests.

[juliusvonkohout]

See also https://github.com/kubeflow/manifests/tree/master/proposals

[andreyvelich]

@juliusvonkohout @kubeflow/wg-manifests-leads can we identify list of improvements that should be discussed under kubeflow/manifests ?
I think, if some of these features belong to manifests, we should update the @kubeflow/wg-manifests-leads charter to include it in their scope: https://github.com/kubeflow/community/blob/master/wg-manifests/charter.md#code-binaries-and-services

For example, WG Manifest is responsible to provide set of security best practices across all Kubeflow projects.
They should work with WG Leads to address them.

[juliusvonkohout]

Yes, i think the security topic. So authentication, authorization, Istio, PodSecuritystandards, Securitycontexts, multi-tenancy, RBAC, networkpolicies etc.

[andreyvelich]

@juliusvonkohout Please can you work towards updating the charter of WG Manifests to include it?
Maybe we can cross-link it from this process, so users better understand to whom they should reach out if they want to contribute new feature.

[anishasthana]

I added the following blurb:

KEPs affecting multiple Kubeflow projects that do not fit into existing cross-component projects such as kubeflow/manifests should be created under kubeflow/community

[varodrig]

/lgtm

[varodrig]

thanks @anishasthana for this.

[andreyvelich]

Thank you for this great effort @anishasthana!
/lgtm
/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