Spark 项目改进提案 (SPIP)

SPIP 的目的是在整个开发过程中，将重大改进信息告知用户社区并让其参与到 Spark 代码库的改进中，以提高满足用户需求的可能性。

SPIP 应该用于重大的面向用户或跨领域变更，而不是小的增量改进。如有疑问，如果提交者认为变更需要 SPIP，则需要 SPIP。

什么是 SPIP？

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

SPIP

• 是一个标记为“SPIP”的 JIRA 票证，用于提出对 Spark 的重大改进或变更
• 遵循下面定义的模板
• 包括 JIRA 票证和 dev@ 列表上的关于提案的讨论

当前 SPIP

过去的 SPIP

谁？

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

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

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

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

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

• 成为所提变更的倡导者
• 帮助推动设计并达成关键利益相关者之间的共识
• 审查代码变更，确保变更符合项目标准
• 从用户那里获取反馈并迭代设计和实现
• 维护变更的质量，包括验证变更是否满足 SPIP 的目标以及在发布之前是否存在严重错误

SPIP 流程

提出 SPIP

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

创建 SPIP 后，作者应向 dev@spark.apache.org 发送电子邮件，通知社区有关 SPIP 的信息，并在 JIRA 票证上进行讨论。

如果 SPIP 太小或太增量，应该通过正常的 JIRA 流程完成，提交者应该删除 SPIP 标签。

SPIP 文档模板

SPIP 文档是一个简短的文档，包含几个问题，灵感来自 Heilmeier 教义

Q1. 您想做什么？用绝对没有行话的方式阐明您的目标。

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

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

Q4. 您的方法有什么新意？为什么您认为它会成功？

Q5. 谁关心？如果您成功了，它将产生什么影响？

Q6. 风险是什么？

Q7. 需要多长时间？

Q8. 中期和最终“考试”是什么？用于检查成功。

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

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

附录 C. 可选的被拒绝的设计：考虑了哪些替代方案？为什么被拒绝？如果没有考虑替代方案，则需要更多思考问题。

讨论 SPIP

所有关于 SPIP 的讨论都应该在公开论坛中进行，最好是在 Jira 附加的讨论中进行。任何离线进行的讨论都应该通过总结讨论的会议记录在线提供给公众。

在讨论过程中，应该在 PMC 成员中确定一个或多个引导者。

讨论结束后，引导者应该在 dev@ 列表上呼吁对 SPIP 向前推进进行投票。投票应该至少开放 72 小时，并遵循典型的 Apache 投票流程，并在达成共识时通过（至少 3 +1 票来自 PMC 成员，并且没有 -1 票来自 PMC 成员）。dev@ 应该收到投票结果的通知。

如果在一个月内不存在至少一名 PMC 成员承诺引导变更，则 SPIP 被拒绝。

如果提交者认为 SPIP 不符合项目的长期目标，或者在提出时不切实际，提交者应该明确 -1 SPIP 并给出技术理由。

实施 SPIP

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