Spark 项目改进提案 (SPIP)

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

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 Catechism

Q1. 您想做什么？使用绝对没有术语来阐明您的目标。

Q2. 此提案不是为了解决什么问题？

Q3. 今天是怎么做的，当前做法的局限性是什么？

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

Q5. 谁在乎？如果您成功了，会有什么不同？

Q6. 风险是什么？

Q7. 需要多长时间？

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

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

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

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

讨论 SPIP

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

在讨论期间，应在 PMC 成员中确定一个或多个负责人。

讨论结束后，负责人应在 dev@ 列表上发起关于 SPIP 向前推进的投票。投票应至少开放 72 小时，并遵循典型的 Apache 投票流程，并在达成共识后通过（至少来自 PMC 成员的 3 个 +1 投票，以及来自 PMC 成员的 0 个 -1 投票）。应该通知 dev@ 投票结果。

如果一个月内至少没有一个 PMC 成员致力于指导变更，则 SPIP 将被拒绝。

如果提交者认为 SPIP 不符合长期项目目标，或者在提案点不可行，则提交者应明确地 -1 SPIP 并给出技术理由。

实施 SPIP

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