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