闪电般的统一分析引擎

Spark Project Improvement Proposals (SPIP)

SPIP的目的是在整个开发过程中告知和吸引用户社区对Spark代码库进行重大改进,以增加满足用户需求的可能性.

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

What is a SPIP?

SPIP与产品管理中常用的产品需求文档相似.

SPIP:

  • 是标有" SPIP"的JIRA票证,建议对Spark进行重大改进或更改
  • 遵循下面定义的模板
  • 包括有关提案的JIRA票证和dev @列表中的讨论

Current SPIPs

Past SPIPs

Who?

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

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

提交者可以通过讨论SPIP是否符合长期项目目标以及扩展SPIP来提供帮助.

SPIP作者是创作SPIP并致力于在整个过程中推动变更的任何社区成员. SPIP的作者身份可以转让.

SPIP Shepherd是PMC成员,致力于在整个过程中推广提议的更改. 尽管牧羊人可以在开发过程中委派其他成员或与之合作,但牧羊人最终还是要对SPIP的成功或失败负责. 牧羊人的责任包括但不限于:

  • Be the advocate for the proposed change
  • 帮助推进设计并在主要利益相关者之间达成共识
  • 审查代码更改,确保更改符合项目标准
  • 从用户那里获得反馈并迭代设计和实施
  • 维护变更的质量,包括在发布变更之前验证变更是否满足SPIP的目标并且不存在关键错误

SPIP Process

Proposing an SPIP

任何人都可以使用下面的文档模板来提出SPIP. 如果您愿意提供帮助,请至少在讨论中提交SPIP.

创建SPIP后,作者应该通过电子邮件dev@spark.apache.org通知SPIP的社区,并讨论应在JIRA票接踵而至.

如果SPIP太小或增量,并且应该通过常规JIRA流程完成,则提交者应删除SPIP标签.

SPIP Document Template

SPIP文档是由Heilmeier Catechism启发的简短文档,其中包含一些问题:

Q1. 你想做什么? 绝对不要用术语表述您的目标.

Q2. 该提议不是为解决什么问题?

Q3. 今天如何进行,目前的做法有哪些局限性?

Q4. 您的方法中有什么新内容,为什么会成功?

Q5. 谁在乎? 如果您成功了,那会有什么不同?

Q6. 有什么风险?

Q7. 这需要多长时间?

Q8. 什么是期中和期末"考试"以检查是否成功?

附录A.建议的API更改. 定义API的可选部分会进行更改(如果有). 必须考虑向后和向前的兼容性.

附录B.可选设计草图:如何实现目标? 提供足够的技术细节,以使贡献者能够判断是否可行. 请注意,这不是完整的设计文档.

附录C.拒绝的可选设计:考虑了哪些替代方案? 他们为什么被拒绝? 如果没有考虑替代方案,则该问题需要更多考虑.

Discussing an SPIP

对SPIP的所有讨论都应在公共论坛上进行,最好是在Jira上进行的讨论. 离线进行的任何讨论都应通过总结讨论的会议记录在线上向公众公开.

在讨论期间,应在PMC成员中确定一个或多个牧羊人.

讨论结束后,牧羊人应该呼吁对SPIP进行投票,并在dev @列表中向前发展. 投票应至少持续72小时,并遵循典型的Apache投票过程并通过共识(PMC成员至少3 +1票,PMC成员没有-1票). 应将投票结果通知dev @.

如果不存在至少一个致力于在一个月内完成更改的PMC成员,则拒绝SPIP.

如果提交者认为SPIP不符合长期项目目标,或者在建议时不切实际,则提交者应明确-1制定SPIP并给出技术依据.

Implementing an SPIP

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

by  ICOPY.SITE