KEP: Enhance the KEP implementation

[justaugustus]

Kubernetes Enhancement Proposal Implementation

• One-line feature description (can be used as a release note): A standardized process for describing / presenting / delivering enhancements to the Kubernetes ecosystem
• Primary contact (assignee): @justaugustus
• Responsible SIGs:
  /sig architecture
• KEP link(s): KEP-1a, KEP-1
• Link to e2e and/or unit tests: N/A
• Reviewer(s) - (for LGTM) recommend having 2+ reviewers (at least one from code-area OWNERS file) agreed to review. Reviewers from multiple companies preferred: @jdumars @calebamiles
• Approver (likely from SIG/area to which feature belongs): @bgrant0607 @jbeda
• Feature target (which target equals to which milestone):
  • Beta release target (1.13)
  • Stable release target (1.14 / 1.15 - tentative)

/kind feature
/milestone v1.13

---

Project tracking board

https://github.com/orgs/kubernetes/projects/5

---

High-level implementation plan

Define

• Refine existing KEP documentation #620
  • Glossary of terms: enhancement, KEP, feature, etc. #2517
  • Proposing a scope field for KEP metadata #2311
  • Define KEP [DACI]
  • KEP Workflow
  • KEP states
  • Entry / exit criteria
  • Exceptions Process #2519
  • create PR templates #2518

Before a KEP gets filed

• Standardize an intra-KEP denotation for "not resolved"
  • SIGs need process for socializing an idea / discussing it before a KEP is drafted
    • AI: To document: someone requests a feature, who triages that and how (SIGs to own, decide). Put help-wanted tag on it? needs-triage should be other SIGs’ responsibility.
    • @thockin did second run of this KEP. Not sure how many people used this notation. You don't know if it's unresolved via the Markdown input. Some sort of comment format visible in Markdown and HTML. Do we still want this?

Organize

• Change the names of KEPs
• Remove some fields from metadata
• Metadata split from KEP text—in progress
  - Stricter validation for KEPs — time to ratchet up presubmits -- can do it, but need to ensure it’s nonblocking as a presubmit so people can slowly fix these things. Secondary presubmit report? Flag or boolean option in kepeval tool?
  - Acceptance criteria: all KEPs are actually in proper forma
• Formalize one-enhancement == one-KEP for Alpha/Beta/GA
• Move KEPs from flat-files to a directory structure/Perform survey of KEPs and identify those needing update to directory format #2725
• Move existing KEPs into [k/features]
• Update README.md #7: Adjust GitHub Tooling for KEPs
  • Create a kind/kep label for [k/community] and [k/features]
• For k/community:
  • Label incoming KEPs as kind/kep (done via owner file) - no longer relevant
  • Enable searches of org:kubernetes label:kind/kep, so we can identify active PRs to k/community and reroute the PR authors to k/enhancements (depending on the state)

For k/enhancements (fka k/features):

• Label incoming KEPs as kind/kep
• Classify KEP submissions / tracking issues as kind/kep, differentiating them from kind/feature
• Move existing design proposals into [k/features]
• Move existing architectural documents into [k/features] (process TBD) #2565
  • Follow up, SIG Arch -- where are arch decisions made? Beyond a particular KEP, where do they go to live
• Deprecate design proposals
  • “We have blockade configured to prevent new design proposals from landing. We do still need to audit the docs and decide which should go into our devel docs and which should be migrated to k/enhancements for long term archival”— @mrbobbytables - blockade is configured, next step is separate sig-arch task
• Rename [k/features] to [k/enhancements]
• Create tombstones / redirects to [k/enhancements]
• Prevent new KEPs and design proposals from landing in [k/community]
• Remove kind/kep from [k/community] once KEP migration is complete
• Correlate existing Feature tracking issues with links to KEPs
• Fix [KEP numbering races] by using the GitHub issue number of the KEP tracking issue
• Coordination of existing KEPs to use new directory structure

Visibility and Automation

• #2140, receipts process
• Create tooling to:
  • Generate KEP directories and associated metadata
  • Present KEPs, through some easy to use mechanism e.g., https://enhancements.k8s.io. This would be a redesigned version of https://contributor.kubernetes.io/keps/. We envision this site / repo having at least three directories:
  • keps/ (KEPs)
  • design-proposals/ (historical design proposals from https://git.k8s.io/community/contributors/design-proposals)
  • arch[itecture]|design/ (design principles of Kubernetes, derived from reorganizing https://git.k8s.io/community/contributors/devel, mentioned here)
• Enable project tracking across SIGs

Improve KEP Template to drive consistent user experience and minds

• Update KEP template #2154
• Capture and iterate on KEP template feedback #822
  • get more feedback/input from SIGs Arch and Testing about what a more detailed testing plan

Other to-do's for this to become stable

• full validation of KEP metadata
  - [ ] Enable versioning and consistent data validation for KEPs #2348
• a KEP website /community #2095
• tooling to support the process
  • Automate graduating, tracking, validating KEPs through approval phase

[justaugustus]

/assign @justaugustus @calebamiles @jdumars

[justaugustus]

/stage beta

[justaugustus]

...because the label exists now:
/kind kep
:)

[jberkus]

Why not go all the way and move them to a database? That's pretty clearly where we're eventually going. And it would solve the autonumbering problem.

[vbatts]

Looking over the points, it looks like much of this is done. (Perhaps checkboxes could be clearer)
Would this graduate the KEP process from beta?

[justaugustus]

Hey @vbatts! :)

We've still got some work to do here before I'd consider the process stable:

• qualify what it means for the process to be stable
• full validation of KEP metadata
• a KEP website
• tooling to support the process

That said, you're right, we should get this issue updated! Will handle.
/unassign @calebamiles @jdumars
/assign @mrbobbytables @jeremyrickard @johnbelamaric

[vbatts]

Right on!

[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

[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

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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 rotten

[justaugustus]

@kubernetes/enhancements -- spoke w/ Lauri earlier and I think we should:

• define exit criteria
• get this closed out
• open tracking issues/additional enhancements for future improvements e.g, [keps] Enable versioning and consistent data validation for KEPs #2348, [keps] Proposing a scope field for KEP metadata #2311

Sound good?
/remove-lifecycle rotten

[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

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

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

Send feedback to sig-contributor-experience at kubernetes/community.
/lifecycle rotten

[k8s-triage-robot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-contributor-experience at kubernetes/community.
/close

[k8s-ci-robot]

@k8s-triage-robot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

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.