KEP Types: Feature vs Policy vs ???

[jeremyrickard]

Over the course of the last few releases, we've seen some Enhancement issues/KEPs that are really focused on policy or tooling changes. These often don't really align with a release / milestone like KEPs that represent new features that can graduate stages within the cadence of a release. As we add more validation to kepval, there are also things in the KEP template that may or may not be applicable to a given KEP. This seems like a good opportunity to evolve the KEP template and process.

A recent example is the [Increase Kubernetes support window to one year]
(#1498 (comment)) KEP. This doesn't really fit into a release like a feature would, but has been discussed in terms of a KEP. This comment suggests that as it doesn't fit into normal graduation criteria, it is just being marked stable and is either "delivered" or not "delivered" within a given release.

There is a related issue in k/community raising the question: Should KEPs be used for process changes?, that would be good to discuss as well.

I propose two things to address this:

• As a first step, perhaps we can add a type field to the KEP metadata with some values like "feature", "policy", "tooling" or "other" so we can apply appropriate validations. These can be evolved as new types are identified. Perhaps we can also provide multiple KEP templates that are tailored for the type of "enhancement". This would allow proper validation of various KEP types.

• Additionally, we should provide some guidance/documentation about using KEPs for things like policy changes or non-feature tooling changes to address questions like Should KEPs be used for process changes? community#3795.

[jeremyrickard]

/sig architecture
/area enhancements

[justaugustus]

We should also consider what PRRApprover validation looks like in in-tree and out-of-tree scenarios.
(ref: #1813 (review), cc: @wojtek-t)

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[palnabarun]

/remove-lifecycle stale

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[palnabarun]

/remove-lifecycle stale

[johnbelamaric]

I am thinking three types:

• Feature
• Process
• Tooling

PRR, for example, would only apply to Feature KEPs.

[justaugustus]

@johnbelamaric -- Moving the discussion to #2311, since it's the more lively thread of the two.

(Work already in flight here: #2480)

/close

[k8s-ci-robot]

@justaugustus: Closing this issue.

In response to this:

@johnbelamaric -- Moving the discussion to #2311, since it's the more lively thread of the two.

(Work already in flight here: #2480)

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.