[keps] Proposing a `scope` field for KEP metadata

[justaugustus]

I've mentioned in some of the recent Enhancements subproject meetings, but filing an issue now, as I was reminded by a line of code in #2280.

As we've used KEPs for some time as a community, we've seen them implemented to capture changes in:

• kubernetes/kubernetes (in-tree)
• out-of-tree components
• infrastructure
• policy

For non-in-tree enhancements, much of the metadata/enforcement for KEPs may not be relevant to proposing/implementing a change in policy, infrastructure, out-of-tree components.

Suggesting here that we introduce a scope field to KEP metadata to allow for scenarios where we might want to skip stricter validation checks.
Proposed values for the scope field:

• in-tree (assumed if not populated)
• out-of-tree
• policy

(Somewhat related to kubernetes/community#3795 and kubernetes/sig-release#486.)

---

From @jeremyrickard in #1783:

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 [kubernetes/community#3795](https://github.com/kubernetes/community/issues/3795).

cc: @kubernetes/enhancements @spiffxp
PRR: @johnbelamaric @deads2k @wojtek-t

[justaugustus]

/sig architecture

[wojtek-t]

I'm not sure about exact values the fields should be able to have, but I like the idea of the field itself.

[BenTheElder]

I'm also unsure of the exact types, but I think this is a good idea, and recently observed that we now have all of the PRR stuff which seems like a good idea for kubernetes/kubernetes features with feature gates etc. but largely superfluous for KEPs that are meta / not affecting production.

[spiffxp]

enhancement_type or scope? to avoid clashing with something super generic like type or kind (you know, so we can one day make these a fully fledged CRD...)

Policy feels ambiguous but I guess it's a good catch-all for project process changes, build / test changes, etc.