Capture and iterate on KEP template feedback #822
Description
AIs from #703:
-
(@jbeda) "Biggest comment is that this is no longer really a template but rather instructions. Perhaps break out into a new doc and/or update https://github.com/kubernetes/enhancements/blob/master/keps/0001-kubernetes-enhancement-proposal-process.md?
Or merge this into the first kep?"
-
(@mattfarina) "How do we deal with differing release processes? For example, when kubectl is broken out into its own repo and has a release process and timing that is different from k8s/k8s?"
-
(@lavalamp) On filing Enhancement Issues, in addition to writing KEPs... "Honestly from the perspective of people wanting to file KEPs this seems like obscure busywork. Why don't we make a bot to file these issues?"
-
(@pbarker) "Questions have been raised here over adding iterative features. If a KEP is marked as 'implementable' and then a feature is added, it inherits the implementable status. Would be nice to have some structure around these changes if it makes sense to do in this revision."
-
(@lavalamp) "I still don't really understand why the "approvers" and "reviewers" section of KEPs exist.
If it's about people who are supposed to approve/review the KEP itself, don't we have owners files for that? KEPs are in separate directories now.If it's about people who are going to help approve and/or review the code changes (e.g., demonstrating that you've lined up sufficient bandwidth in the schedules of busy folks to actually get the changes made), it's probably named wrong.
Actually IMO it's totally ambiguous right now and that section of the KEP could either be renamed or have a comment to make it clear what it means."
-
(@lavalamp) "Are KEPs design docs or requirements docs?
People have said "both" but I'm not convinced that's a good answer. There is no reason to suppose that the set of people who know what good goals are has a lot of overlap with the set of people who will be good at charting a path to achieving the goals.
I personally feel that it's reasonable to hold a vote on goals (i.e. requirements), as long as they're appropriately phrased (e.g., "is problem X an important problem for the project to solve" NOT "is changing the frobber API to interoperate with the thingy a good idea"). It is not a good idea to vote on solutions (designs), that should be handled by the right technical folks. (I think any formal specification of this distinction can be gamed, unfortunately.)"
-
(@mattfarina) "Could we explicitly state that a single KEP is for all maturity levels through graduation and that the graduation criteria should be described for the transition between each level. The examples below share this but some explicit direction could help clear up what @bgrant0607 noticed and I realized may be implicitly communicated."
@justaugustus "@mattfarina -- I'm wondering if that's a better fit for the front documentation on KEPs (which I'm planning to work on once this lands)?
A KEP captures details of an enhancement and is meant to be the steel thread to capture all implementation states. There should only be one KEP per enhancement.
Happy to add something if that thought isn't really captured well."
/sig pm
/assign
/milestone keps-beta