[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.

[justaugustus]

Going with scope, as Aaron suggested.
Not ready for review yet, but implementation PR is here: #2480

[justaugustus]

From @johnbelamaric in #1783 (comment):

I am thinking three types:

* Feature

* Process

* Tooling

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

[kikisdeliveryservice]

I think Feature/Process/Tooling is broad enough to cover most keps and specific enough to put them all in an appropriate general bucket. 👍

[justaugustus]

So the current ideas are:

• in-tree
• out-of-tree
• policy

And:

• feature
• process
• tooling

Thinking from the "people --> process --> tools" standpoint...
process should give way to tooling; they're not separate.

More importantly, the people are always the first concern.

Success here is getting a clear indication of who needs to action on something, so to me, at a baseline, there are two buckets:

1. Things that need to be reviewed by the Release Team and PRR approvers (in-tree)
2. Everything else

Also, just because something is out-of-tree, doesn't necessarily mean it's not a "feature".

I'm going to move forward with:

• in-tree (needs to be tracked by RT and approved by PRR)
• out-of-tree (doesn't need to be tracked/approved: non-k/k)
• process (doesn't need to be tracked/approved: could be related to in-tree, out-of-tree efforts, policies, infra changes)

Additionally, we should match our repo labels to this, so:

• tracked/{yes,no}
• scope/{in-tree,out-of-tree,process}

If anyone has objections, let me know.

EDIT -- Slack thread: https://kubernetes.slack.com/archives/C1L57L91V/p1613086744161300

[johnbelamaric]

Are, for example, build scripts in-tree or out-of-tree? Or process? What about things like kepctl? From the "tooling is subsumed by process" they would be process changes, I guess. But that really doesn't seem clear to me; I tend to think of process of not having any code attached, but maybe that's just too narrow of a view?

[justaugustus]

More discussion here: https://kubernetes.slack.com/archives/C1L57L91V/p1615412485006300

Current thoughts:

• kep-type: code|process
• scope : in-tree|out-of-tree

Anything that hits the in-tree scope is something that needs deeper review from RT + (potentially) PRR.
kep-type determines the template you might use (only one template exists today, but we could create another that is process -specific)

With those permutations, I see:

• in-tree + code: needs RT tracking + PRR review + uses "default"/current template
• in-tree + process: needs RT tracking + maybe PRR or RelEng/Testing review + uses a TBD "process" template
• out-of-tree + code: doesn't require RT tracking or PRR review + may use "default"/current template w/ RT checklist + PRR sections elided
• out-of-tree + process: doesn't require RT tracking or PRR review + uses a TBD "process" template

[ehashman]

Are, for example, build scripts in-tree or out-of-tree? Or process? What about things like kepctl? From the "tooling is subsumed by process" they would be process changes, I guess. But that really doesn't seem clear to me; I tend to think of process of not having any code attached, but maybe that's just too narrow of a view?

I think @johnbelamaric hit the nail right on the head: we need a concrete definition of what changes constitute in-tree for this to work. What is our working proposal? I think the meaning is implied and I'd like to make it explicit :)

[jeremyrickard]

This is relevant to #2567.

One thing that has come out of that is that I think we need a follow on issue to this that provides some concrete guidance around the use of stage/milestone things that are policy.

[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-contributor-experience at kubernetes/community.
/lifecycle stale

[k8s-triage-robot]

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:

• 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 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 rotten

[spiffxp]

/remove-lifecycle rotten
I'm going through and refreshing SIG Testing KEPs, we have many that don't fit "in-tree" if that means "involves changes to code in kubernetes/kubernetes that is compiled into artifacts distributed as part of a kubernetes release"

I'm not sure I see consensus on how we should categorize our stuff instead:

• (in-tree|out-of-tree) + (code|process)?
• in-tree|out-of-tree|policy?
• in-tree|out-of-tree|process?

I noticed there is a PR out that assumes scope could be in-tree #2480

I think at the very least I'm going to propose I add scope: out-of-tree for changes that are primarily kubernetes/test-infra code, code primarily in support of job config changes, etc. Can refine if there is consensus

[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

[k8s-triage-robot]

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:

• 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 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 rotten

[k8s-triage-robot]

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:

• 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:

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

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

/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

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:

• 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:

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

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

/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.

[justaugustus]

This is coming up every cycle...

/reopen
/remove-lifecycle rotten
/lifecycle frozen
ref: https://kubernetes.slack.com/archives/CPNHUMN74/p1642427639015900

[k8s-ci-robot]

@justaugustus: Reopened this issue.

In response to this:

This is coming up every cycle...

/reopen
/remove-lifecycle rotten
/lifecycle frozen
ref: https://kubernetes.slack.com/archives/CPNHUMN74/p1642427639015900

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.

[justaugustus]

cc: @kubernetes/enhancements @kubernetes/release-team @kubernetes/production-readiness