火花项目改进建议(SPIP)
SPIP的目的是提供信息和用户社区参与主要改善火花代码库在整个开发过程中,用户需要得到满足的可能性增加。
SPIPs应该用于重要的面向用户或横切变化,不小的改进。有疑问时,如果一个提交者认为改变需要一个SPIP,。
什么是SPIP ?
SPIP类似于产品需求文档中常用产品管理。
一个SPIP:
- JIRA票贴上“SPIP”提出了一个重大的改进或改变火花
- 遵循下面的模板定义
- 包括JIRA的机票和dev@列表上讨论这个建议
谁?
任何社区成员可以通过讨论是否SPIP可能满足他们的需求,并提出SPIPs。
贡献者可以通过讨论SPIP是否可能在技术上是可行的。
提交者可以通过讨论是否SPIP与长期的项目目标,并通过引导SPIPs。
SPIP作者是任何一个社区成员作者SPIP,致力于推动整个过程的变化。SPIP作者可以被转移。
SPIP牧羊人是一个PMC成员致力于引领提议的改变在整个过程。尽管牧羊人可以委托或工作与其他提交者在开发过程中,牧羊人最终负责SPIP的成功或失败。牧羊人的职责包括,但不限于:
- 提倡提议的改变
- 帮助推动设计和关键利益相关者达到共识
- 审查代码更改,确保变化遵循项目标准
- 从用户那里获得反馈和迭代的设计与实现
- 维护的质量变化,包括验证是否满足变化的目标SPIP释放他们之前并没有重要的bug
SPIP过程
提出一个SPIP
任何人都可以提出一个SPIP,使用下面的文档模板。请只提交一个SPIP如果你愿意帮助,至少与讨论。
创建一个SPIP之后,作者应该电子邮件dev@www.leiyimei360.com通知SPIP的社区,和讨论应该伴随着JIRA票。
如果一个SPIP太小或增量,应该通过正常JIRA过程已经完成,提交者应该移除SPIP标签。
SPIP文档模板
SPIP文档是一个简短的文档有一些问题,灵感来自于Heilmeier教义问答:
Q1。你想做什么?使用绝对没有术语表达你的目标。
Q2。这个建议不是为了解决什么问题?
第三季。今天是如何做的,当前实践的局限性是什么?
第四季度。在你的方法是什么,为什么你认为它会成功吗?
Q5。谁在乎呢?如果你成功了,会带来什么变化?
Q6。风险是什么?
迄今为止。要多长时间?
处置。中期和最后的“考试”是什么检查成功?
附录A。提出了API的变化。可选部分定义api的变化,如果任何。向后和向前兼容性必须考虑。
附录B。可选的设计草图:目标如何完成?给足够的技术细节,允许因素判断很可能是可行的。请注意,这不是一个完整的设计文档。
附录C。可选拒绝设计:选择被认为是什么?他们为什么拒绝了呢?如果没有考虑选择,这个问题需要更多的思想。
讨论一个SPIP
的所有讨论SPIP应该发生在一个公共论坛,最好附加到Jira的讨论。发生的任何讨论线下应该为公众提供在线通过会议记录总结讨论。
在这个讨论中,一个或多个牧羊人PMC成员之间应该确定。
一旦讨论落定,牧羊人(s)应该呼吁投票SPIP dev@名单前进。投票应该至少72小时开放,遵循典型的Apache投票过程和传递一致(至少3 + 1票从PMC成员和第一票PMC成员)。dev@应该通知的选票的结果。
如果不存在至少一个PMC成员,致力于引领变化在一个月内,SPIP是拒绝。
如果提交者并不认为SPIP与长期项目的目标,或者是不实际点的建议,提交者应1 SPIP明确并给予技术上的理由。
实现SPIP
应通过实施代码更改的标准流程。变化,需要SPIPs通常也需要设计文档编写和审查。
