增强功能跟踪与待办事项
用于 Kubernetes 发布的增强跟踪仓库。由 SIG Architecture 负责维护。
本仓库包含问题和 KEPs。这些问题是用于跟踪将添加到 Kubernetes 的新增强的伞式问题。一个增强通常需要多个发布周期才能完成。并且，一个增强可以在工作开始之前作为待办事项进行跟踪。当至少一个 Kubernetes SIG 达成共识时，可以提交一个增强。
我的功能算增强吗？
我们正在努力确定增强的确切形态。在此之前，这里有一些粗略的判断标准。
增强是指任何满足以下条件的内容：
- 发布后会有博客文章对其进行介绍（例如 minikube、StatefulSets、rkt 容器运行时）
- 需要多方/SIG/负责人参与才能完成（例如 GPU 调度 [API、Core 和 Node]、StatefulSets [Storage 和 API]）
- 将从一个阶段过渡到另一个阶段（例如从 alpha 到 beta，从 beta 到 GA）
- 需要大量工作或以显著方式改变 Kubernetes（例如需要 10 人周来实现、引入或重新设计系统组件，或引入 API 变更）
- 对 Kubernetes 的用户体验或操作产生重大影响，以至于使用 Kubernetes 的工程师需要重新培训
- 用户会注意到并依赖它
如果属于以下情况，则不太可能是一项增强功能：
- 使用
CustomResourceDefinition实现 - 修复不稳定的测试
- 重构代码
- 性能改进，用户仅能感知为更快的 API 操作或更快的控制循环
- 添加错误消息或事件
如果不确定，请咨询您最初传播该想法的 SIG 中的某人。如果他们也不确定，请加入 Slack 上的 #enhancements 或联系 OWNERS 中列出的某人。
何时创建新的增强功能问题
在满足以下条件后，请在此仓库中创建一个 issue：
- 已传播你的想法以查看是否有兴趣
- 通过社区会议、SIG 会议、SIG 邮件列表，或 github.com/kubernetes/kubernetes 中的一个 issue
- （可选）已在自己的 fork 中完成原型
- 已确定同意参与该增强功能开发的人员
- 许多增强功能需要多个版本才能通过 Alpha、Beta 和 Stable 阶段
- 你和你的团队应准备好投入大约 9 个月至 1 年的时间，以推进至 Stable 状态
- 已准备好担任该增强功能的项目经理
为什么要跟踪增强功能
一旦用户采用某项增强功能，他们期望在较长时间内使用它。因此，我们对新增强功能保持高标准的概念完整性，并要求与系统的其他部分保持一致、进行彻底测试以及提供完整的文档。随着项目的增长，没有任何一个人能够跟踪所有这些要求是否得到满足。
增强功能的开发通常跨越三个阶段：Alpha、Beta 和 Stable。增强功能跟踪 Issue 提供了一个检查清单，允许为不同方面设置不同的审批人，并确保在增强功能整个开发生命周期中不会遗漏任何事项。
何时在增强功能 Issue 上发表评论
请在增强功能问题中评论以：
- 请求对流程进行审查或澄清
- 更新增强功能工作的状态
- 链接到其他仓库中的相关问题
请勿在增强功能问题中评论以：
- 讨论设计、代码或文档的细节。请使用链接的问题或 PR 来处理
增强功能跟踪看板
自 1.26 版本发布以来，本仓库的增强功能在增强功能跟踪看板中可视化。
链接：
增强功能跟踪电子表格
在 1.26 版本发布之前，本仓库的增强功能使用增强功能跟踪电子表格进行可视化。
请参阅 增强功能跟踪电子表格存档 以获取 这些表格的链接。
流程： 待定
当前发布周期
增强功能里程碑日期的例外情况
例外流程由发布团队处理，请参阅其 文档 以获取更多详细信息。
标签
| 标签名称 | 用途 | 如何使用此标签 | 谁应使用此标签 |
|---|---|---|---|
sig/foo | 表示拥有此增强功能的 SIG——例如，SIG Foo | 使用评论 /sig foo（单独一行）设置标签 | 任何人 |
kind/feature | 表示该问题应作为增强功能进行跟踪（所有增强功能问题都应标记此标签） | 使用评论 /kind feature（单独一行）设置标签 | 任何人 |
stage/{alpha,beta,stable} | 表示问题在功能流程中的阶段 | 使用评论 /stage alpha（单独一行）设置标签 | 任何人 |
术语表
请参阅 术语表 以获取增强功能子项目中使用的任何术语和缩写的定义。