Open eddiezane opened 2 years ago
/sig architecture /area enhancements
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 ?
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.
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 https://github.com/kubernetes/enhancements/issues/3399#issuecomment-1163762139, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKWAVFK2WK3H6ASAAVZOJ3VQOPKHANCNFSM5Y5BELDA . You are receiving this because you were assigned.Message ID: @.***>
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.
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough active contributors to adequately respond to all issues and PRs.
This bot triages issues and PRs according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten
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:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/lifecycle rotten
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
I don't want this to die off, but it seems that nobody is paying it attention. It doesn't seem super complex, and I almost let it nerd-snipe me, but I have other things to do this afternoon. I'll un-stale it once more, but maybe only one.
@jpbetz FYI
/remove-lifecycle stale
@kikisdeliveryservice any thoughts on how to progress/reboot this? I'd like to contribute.
/assign
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
/remove-lifecycle stale
I'm going to circle back on this.
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
I have a process kep template that I've been working on. I'll pull it back out and try to get a draft up to get conversation on this going again.
Awesome. This is perpetually on my list of "stuff to think about for this cycle".
The Kubernetes project currently lacks enough contributors to adequately respond to all issues.
This bot triages un-triaged issues according to the following rules:
lifecycle/stale
is appliedlifecycle/stale
was applied, lifecycle/rotten
is appliedlifecycle/rotten
was applied, the issue is closedYou can:
/remove-lifecycle stale
/close
Please send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle stale
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:
cc @kubernetes/production-readiness @kubernetes/enhancements