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 的目标并且没有严重 bug

SPIP 流程

提出 SPIP

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

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

如果一个 SPIP 太小或属于增量改进，并且应该通过正常的 JIRA 流程完成，提交者应移除 SPIP 标签。

SPIP 文档模板

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

问题 1. 您正在尝试做什么？请用绝对非行话的语言阐明您的目标。

问题 2. 此提案未旨在解决哪些问题？

问题 3. 目前是如何做的，以及当前做法的局限性是什么？

问题 4. 您的方法有什么新颖之处，以及您为什么认为它会成功？

问题 5. 谁会关心？如果您成功了，会有什么不同？

问题 6. 风险是什么？

问题 7. 需要多长时间？

问题 8. 检查成功的期中和期末“考试”是什么？

附录 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 的更改通常也需要编写和审查设计文档。