Spark 项目改进提案 (SPIP)

SPIP 的目的是在整个开发过程中，让用户社区参与到 Spark 代码库的重大改进中来，从而提高满足用户需求的概率。

SPIP 应仅用于重大的面向用户或跨领域的变更，而非微小的增量改进。如有疑问，如果某位提交者认为某项变更需要 SPIP，那么它就需要。

什么是 SPIP？

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

SPIP

• 是一个标记为“SPIP”的 JIRA 工单，用于提议对 Spark 进行重大改进或变更
• 遵循下述模板
• 包含在 JIRA 工单和 dev@ 邮件列表中关于该提案的讨论

当前的 SPIP

过去的 SPIP

参与人员

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

贡献者可以通过讨论 SPIP 在技术上是否可行来提供帮助。

提交者 (Committers) 可以通过讨论 SPIP 是否符合项目的长期目标以及指导 SPIP 来提供帮助。

SPIP 作者是任何撰写 SPIP 并致力于推动该变更完成整个过程的社区成员。SPIP 的作者身份可以转让。

SPIP 指导者 (Shepherd) 是一位致力于在整个过程中指导提议变更的 PMC 成员。虽然指导者可以在开发过程中委派或与其他提交者合作，但指导者最终对 SPIP 的成功或失败负责。指导者的职责包括但不限于

• 作为提议变更的倡导者
• 协助推进设计并在主要利益相关者之间达成共识
• 审查代码变更，确保变更符合项目标准
• 从用户处获取反馈并迭代设计与实现
• 维护变更质量，包括验证变更是否满足 SPIP 的目标，并在发布前确保没有严重错误

SPIP 流程

提出 SPIP

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

创建 SPIP 后，作者应发送电子邮件至 dev@spark.apache.org 以通知社区，并应在 JIRA 工单上进行后续讨论。

如果某个 SPIP 太小或属于增量改进，本应通过正常的 JIRA 流程处理，则提交者应移除该 SPIP 标签。

SPIP 文档模板

SPIP 文档是一个简短的文档，包含几个受“海尔迈耶问答 (Heilmeier Catechism)”启发的问题。

Q1. 您想做什么？用完全通俗的语言阐述您的目标。

Q2. 此提案并非旨在解决什么问题？

Q3. 目前是如何完成的，当前实践的局限性是什么？

Q4. 您的方法有什么新颖之处，为什么您认为它会成功？

Q5. 谁会关心？如果成功了，会有什么不同？

Q6. 风险是什么？

Q7. 需要多长时间？

Q8. 用来检验成功的阶段性考核和最终“考试”是什么？

附录 A. 建议的 API 变更。定义 API 变更的可选部分（如果有）。必须考虑向后和向前兼容性。

附录 B. 可选的设计草图：目标将如何实现？提供足够的技术细节，以便贡献者判断其是否可行。请注意，这不是完整的设计文档。

附录 C. 可选的被拒绝设计：考虑过哪些替代方案？为什么被拒绝？如果没有考虑过替代方案，则说明该问题还需要进一步思考。

讨论 SPIP

所有关于 SPIP 的讨论都应在公共论坛进行，最好是附在 Jira 上的讨论区。任何在线下进行的讨论都应通过会议纪要摘要的形式在线提供给公众。

在此讨论期间，应在 PMC 成员中确定一名或多名指导者。

一旦讨论达成一致，指导者应在 dev@ 列表上呼吁对 SPIP 的推进进行投票。投票应开放至少 72 小时，遵循标准的 Apache 投票流程，并根据共识通过（至少 3 个来自 PMC 成员的 +1 票，且没有来自 PMC 成员的 -1 票）。投票结果应通知 dev@。

如果一个月内没有 PMC 成员承诺指导该变更，则 SPIP 将被拒绝。

如果提交者认为 SPIP 不符合项目的长期目标，或者在提案时不可行，则该提交者应明确对 SPIP 投出 -1 票，并给出技术依据。

实施 SPIP

实施应通过标准的代码变更流程进行。需要 SPIP 的变更通常也需要编写并审查设计文档。