enhancements

本仓库是 Kubernetes 版本的增强功能跟踪仓库，由 SIG Architecture 负责。它包含 issue 和 KEP（Kubernetes Enhancement Proposals，Kubernetes 增强提案），作为添加到 Kubernetes 的新增强功能的伞形议题。一个增强功能通常跨越多个版本，可以在工作开始前作为待办事项进行跟踪；当至少一个 Kubernetes SIG 达成共识后即可提交。 README 通过粗略的启发式规则定义了什么算作增强功能。增强功能通常是发布后会撰写博客文章的内容，需要多方/SIG/负责人共同完成，从一个阶段毕业到另一个阶段（alpha 到 beta，beta 到 GA），需要大量工作或大幅改变 Kubernetes，对用户体验或运维的影响足以让用户需要重新培训，或者是用户会注意到并依赖的功能。如果通过 CustomResourceDefinition 实现、修复不稳定的测试、重构代码、仅提升性能（表现为更快的 API 操作或控制循环），或仅添加错误消息或事件，则不太可能算作增强功能。 新的增强功能 issue 应在传播想法（社区会议、SIG 会议、邮件列表或 kubernetes/kubernetes 的 issue）、可选地在 fork 中进行原型开发、确定愿意参与工作的人员，并准备好担任项目经理角色之后创建。README 指出，许多增强功能需要经过数个版本，大约 9 个月到一年才能达到 Stable 阶段。 增强功能之所以被跟踪，是因为用户期望长期依赖它们，因此项目对它们有很高的标准要求，包括概念完整性、一致性、充分测试和完整文档。跟踪 issue 提供了一个检查清单，在 Alpha、Beta 和 Stable 各阶段的不同方面有不同的审批人。 增强功能 issue 上的评论用于请求审查或澄清流程、更新状态，或链接其他仓库中的相关 issue；设计、代码或文档细节应在关联的 issue 或 PR 中讨论。 从 1.26 版本开始，增强功能在 Enhancements Tracking Boards 中可视化展示，提供从 1.26 到 1.38 的里程碑链接。在 1.26 之前使用跟踪电子表格，并引用了这些表格的存档。当前发布周期指向 sig-release 仓库中的 1.38 版本信息。增强功能里程碑日期的例外情况由 Release Team 根据其文档处理。 标签包括用于所属 SIG 的 `sig/foo`、用于将 issue 标记为增强功能的 `kind/feature`，以及用于功能流程阶段的 `stage/{alpha,beta,stable}`，每个标签通过评论命令设置。一份术语表文档定义了 Enhancements 子项目中使用的术语和缩写。