Gluten 项目改进建议（GPIP）

Gluten 项目改进提案（GPIP）文档参考了 Spark SPIP 文档。

GPIP 的目的是在整个开发过程中，让用户社区了解并参与到 Gluten 代码库的重大改进中，从而提高满足用户需求的可能性。

GPIP 应当用于重大的、面向用户的或前沿的变更，而非细小的增量改进。

如果您的提案符合 GPIP 的定义，我们建议您创建一个 GPIP，这将有助于该提案的推进与讨论；但这并非强制要求，我们欢迎任何形式的贡献与社区参与。

什么是 GPIP？

GPIP 类似于产品管理中常用的产品需求文档。

一个 GPIP：

• 是一个带有“GPIP”标签的工单，用于提出对 Gluten 的重大改进或变更
• 遵循下文定义的模板
• 包含该工单以及 dev@ 邮件列表中围绕该提案的讨论

相关角色

任何社区成员都可以通过讨论 GPIP 是否可能满足其需求，以及提出 GPIP 来提供帮助。

**贡献者（Contributors）**可以通过讨论 GPIP 在技术上是否可行来提供帮助。

**提交者（Committers）**可以通过讨论 GPIP 是否与项目的长期目标一致，以及引导（shepherd）GPIP 来提供帮助。

GPIP 作者是指撰写 GPIP 并承诺推动该变更走完整个流程的社区成员。GPIP 的作者身份可以转移。

**GPIP 引导人（Shepherd）**是指承诺在整个过程中引导所提变更的 PMC 成员。虽然引导人在开发过程中可以委托其他提交者或与其协作，但引导人最终对 GPIP 的成败负责。引导人的职责包括但不限于：

• 为所提变更发声代言
• 推动设计推进，并在关键利益相关者之间达成共识
• 审查代码变更，确保变更符合项目标准
• 收集用户反馈，并对设计与实现进行迭代
• 维护变更的质量，包括在发布前验证变更是否达成了 GPIP 的目标，且不含关键缺陷

GPIP 流程

提出 GPIP

任何人都可以使用下文的文档模板提出 GPIP。请仅在您愿意提供帮助（至少参与讨论）时才提交 GPIP。

GPIP 创建后，作者应向 dev@gluten.apache.org 发送邮件以通知社区该 GPIP，随后应在该工单上展开讨论。

如果某个 GPIP 过于细小或属于增量改进，本应通过常规工单流程完成，则提交者应移除其 GPIP 标签。

GPIP 文档模板

GPIP 文档是一份简短的文档，由若干问题组成，其灵感来自海尔迈尔问答法（Heilmeier Catechism）：

• 问题一：你想要做什么？请完全不用术语地阐述你的目标。
• 问题二：本提案不打算解决什么问题？
• 问题三：目前是怎么做的，现有做法的局限是什么？
• 问题四：你的方法有什么新意，你认为它为什么会成功？
• 问题五：谁会在意？如果你成功了，会产生什么影响？
• 问题六：有哪些风险？
• 问题七：需要多长时间？
• 问题八：检查是否成功的中期和最终"考核"是什么？
• 附录 A：建议的 API 变更。可选章节，用于定义（如有）API 变更。必须考虑向后兼容与向前兼容性。
• 附录 B：可选的设计草图：如何实现这些目标？提供足够的技术细节，以便贡献者能够判断其可行性。请注意，这不是一份完整的设计文档。
• 附录 C：可选的被否决的设计：考虑过哪些替代方案？为什么被否决？如果从未考虑过替代方案，说明对这个问题还需要进一步思考。

讨论 GPIP

所有关于 GPIP 的讨论都应在公开论坛中进行，最好是在该工单关联的讨论区中进行。任何线下发生的讨论都应通过会议纪要的形式整理并公开，供公众查阅。

在此讨论过程中，应在 PMC 成员中指定一名或多名引导者（shepherd）。

当讨论尘埃落定后，引导者应在 dev@ 邮件列表中发起关于该 GPIP 是否继续推进的投票。投票期应至少持续 72 小时，并遵循 Apache 典型的投票流程，达成共识即通过（至少获得 3 名 PMC 成员的 +1 票，且没有 PMC 成员投 -1 票）。投票结果应通知 dev@ 邮件列表。

如果在一个月内没有至少一名 PMC 成员承诺引导该变更的推进，则该 GPIP 被否决。

如果某位提交者（committer）认为某个 GPIP 不符合项目的长期目标，或者在提出时不具可行性，则该提交者应明确对该 GPIP 投 -1 票，并给出技术上的理由。

实施 GPIP

实施应遵循贡献指南进行。需要 GPIP 的变更通常还需要编写并评审设计文档。

GPIP 社区协作

Gluten 社区始终欢迎各类贡献与参与，如果你对 GPIP 流程有任何疑问，欢迎随时与社区联系。