Streamline KEP + PRR process for non-API changes

[eddiezane]

The KEP template has grown to a point where a majority of the sections are primarily focused on API server enhancements and are less relevant to others. This is a pretty negative experience for myself as a maintainer and certainly even more confusing for folks that are new to the project.

Enhancements to the Kubernetes project entail more than serverside components. I think that the KEP template should be concise and limited to sections that are actually required/relevant to the proposed change.

One option we could consider is moving the PRR section to its own location as a supplement with clear criteria when it is necessary. Another is how we can tie in scopes.

I want to understand how we can streamline the process for features that don't interact with the API. For example, we plan to eventually add colors to the output of kubectl. We want to do a KEP as a design doc for collaboration but the process seems heavy handed for a change like that.

Other examples:

• https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/3136-beta-apis-off-by-default#production-readiness-review-questionnaire
• KEP-3104: Introduce kuberc #3392
• https://github.com/kubernetes/enhancements/tree/master/keps/sig-cli/2953-kustomize-plugin-graduation#production-readiness-review-questionnaire
• https://github.com/kubernetes/enhancements/tree/master/keps/sig-release/3027-slsa-compliance
• https://github.com/kubernetes/enhancements/tree/master/keps/sig-release/3031-signing-release-artifacts#production-readiness-review-questionnaire

cc @kubernetes/production-readiness @kubernetes/enhancements

[mrbobbytables]

/sig architecture
/area enhancements

[thockin]

PRR is there to force people to think about the questions, not because there's always something to say.

I ACK that policy KEPs don't need it and should be able to delete or "N/A" it (but should they be able to bypass it?)

Or maybe we want a SMALL number of templates, e.g. README-tech.md vs README-nontech.md ?

[mrbobbytables]

We've tossed around multiple templates (+versioning them) etc in the past with general support. Part of the original goal for keptctl was to provide scaffolding for creating/updating KEPs based on what they're impacting. That largely didn't get driven forward due to lack of bandwidth / community consensus =/

I'd LOVE to overhaul and streamline the KEP process, its just everyone that knows the ins and outs has really been blocked on time.

[thockin]

I'd also like to restructure the template some - I find the ordering to be weird and sometimes repetitive. That said, PRR is verbose because there are a lot of edge cases that people tend to forget about (myself included).

…

On Wed, Jun 22, 2022 at 4:35 PM Bob Killen ***@***.***> wrote: We've tossed around multiple templates (+versioning them) etc in the past with general support. Part of the original goal for keptctl was to provide scaffolding for creating/updating KEPs based on what they're impacting. That largely didn't get driven forward due to lack of bandwidth / community consensus =/ I'd LOVE to overhaul and streamline the KEP process, its just everyone that knows the ins and outs has really been blocked on time. — Reply to this email directly, view it on GitHub <#3399 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKWAVFK2WK3H6ASAAVZOJ3VQOPKHANCNFSM5Y5BELDA> . You are receiving this because you were assigned.Message ID: ***@***.***>

[kikisdeliveryservice]

I've been working on a KEP template for process changes/non-technical changes but I think grouping those in this convo with more feature oriented KEPs is a bit misplaced. For now we don't actually have many process KEPs so it's not a terribly blocking issue for them to just n/a those sections and work is underway to have a better path for that.

Focusing more on technical KEPS and PRR: I'm hesitant to let authors just unilaterally opt-out across the board for actual features. As @thockin noted above, it's there to indicate to authors important things to think about and consider. N/A-ing (with an explanation of why it's n/a) feels like the safer option, rather than letting authors just pick a KEP template that doesn't include it from the start. I've put an agenda item on the Enhancements meeting for July 7th to discuss both.

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues and PRs.

This bot triages issues and PRs according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue or PR as fresh with /remove-lifecycle stale
• Mark this issue or PR as rotten with /lifecycle rotten
• Close this issue or PR with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale