Source跳过0-目的和过程¶
- 作者
Jarrod Millman<Millman@berkeley.edu>
- 作者
Juan Nunez-Iglesias<juan.nunez-iglesias@monash.edu>
- 作者
Stéfan van der Walt<stefan v@berkeley.edu>
- 状态
活动的
- 类型
过程
- 已创建
2019-07-30
什么是跳跃？¶
Skip代表 s cik 它-- i Mage p rPoposal.Skip是一种设计文档，它向社区提供信息，或描述SCRICKIT的新功能--图像或其过程或环境。如果适用，跳过应提供拟议变更的理由和简明的技术规范。
我们打算将Skip作为提出主要新功能的主要机制，收集社区对某个问题的意见，并记录已进入SCRKIT-IMAGE的设计决策。Skip作者负责在社区内建立共识并记录不同意见。
由于跳过以文本文件的形式保存在版本化存储库中，因此它们的修订历史记录是要素建议的历史记录 1.
类型¶
跳过有三种类型：
A 标准跟踪 Skip描述了SCRICKIT-IMAGE的一个新功能或实现。
一个 信息性 Skip描述了一个SCRICKIT映像设计问题，或者向Python社区提供了通用的指导方针或信息，但没有提出新的功能。信息跳过不一定代表科学工具包-图像社区的共识或建议，因此用户和实施者可以自由地忽略信息跳过。
A 过程 Skip描述了一个围绕SCRICKIT-IMAGE的过程，或者建议改变一个过程(或其中的一个事件)。进程跳过类似于标准跟踪跳过，但适用于SCRICKIT映像库本身以外的区域。他们可能会提出一个实现方案，但不是针对SCRKIT-IMAGE的代码库；他们需要社区共识。例如，程序、指导方针、决策过程的更改，以及SCRICKIT-IMAGE开发中使用的工具或环境的更改。任何元跳过也被认为是进程跳过。
跳过工作流¶
跳过过程始于一个新的SCRICIT-IMAGE想法。跳过应该只包含一个关键的建议或新想法。小的增强或补丁通常不需要跳过，并且可以通过对SCRKIT-IMAGE的拉请求被注入到SCRICKIT-IMAGE开发工作流中 repo 。跳过的焦点越集中，就越有可能被接受。
每个跳过必须有一个拥护者-使用下面描述的风格和格式编写跳过的人，在适当的论坛中引导讨论，并试图围绕该想法建立社区共识。跳跃冠军(又名作者)应首先尝试确定该想法是否适合跳过。发布到SCRICKIT-图像 mailing list 是做这件事的最佳方式。
建议书应以草案跳过的形式通过 GitHub pull request 发送到 doc/source/skips 名为的目录 skip-<n>.rst 哪里 <n> 是适当分配的号码(例如， skip-35.rst )。草稿必须使用 跳过X模板和说明 文件。
一旦公关到位，跳过应该在邮件列表上公布以供讨论(对公关本身的评论应该限于次要的编辑和技术修复)。
在方便的情况下，应尽早合并PR(无论在讨论期间是否被接受)。概述一个连贯的论点并被认为相当完整的跳过应该乐观地合并，无论它在讨论中是否被接受。另外的PR可以由作者更新或扩展跳过，或由维护人员设置其状态、讨论URL等。
标准跟踪跳跃由两部分组成，即设计文档和参考实现。通常建议至少与SKIP共同开发一个原型实现，因为原则上听起来很好的想法有时被证明是不切实际的。通常，只要将原型实现适当地标记为WIP(工作进行中)，将其作为PR提供给SCRICKIT-IMAGE repo是有意义的。
审查和解决方案¶
在邮件列表中讨论了跳过。跳过状态的可能路径如下：
所有跳过都应使用 Draft 状态。
最终，经过讨论，可能会有一个共识，即应该接受跳过--详情见下一节。此时，状态变为 Accepted 。
一旦跳过一次 Accepted ，则必须完成参考实现。当参考实现完成并合并到主代码库中时，状态将更改为 Final 。
为了在致力于语言特性或标准库API的长期稳定性之前收集额外的设计和界面反馈，也可以将跳过标记为“临时”。这是“临时接受”的缩写，表明该提案已被接受，以纳入参考实现，但在将整个设计视为“最终”之前，还需要更多的用户反馈。与常规接受的跳过不同，临时接受的跳过仍然可能被拒绝或撤回，即使在相关更改已包含在版本中之后。
在可能的情况下，最好缩小提案的范围，以避免依赖“临时”状态(例如，将某些功能推迟到以后跳过)，因为这种状态可能会在更广泛的生态系统中导致版本兼容性问题。
还可以为跳过分配状态 Deferred 。当跳过没有取得进展时，跳过作者或核心开发人员可以将该状态分配给跳过。
跳过也可以是 Rejected 。也许说到底，这不是一个好主意。对这一事实有一个记录仍然很重要。这个 Withdrawn 状态是相似的-这意味着跳过作者自己认为跳过实际上是一个坏主意，或者已经接受了竞争提议是更好的选择。
当跳跃是 Accepted ， Rejected ，或 Withdrawn ，则应相应地更新跳过。除了更新Status字段之外，至少 Resolution 标题应添加一个链接，指向邮件列表档案中的相关帖子。
跳过也可以是 Superseded 通过不同的跳转，呈现原始的过时。这个 Replaced-By 和 Replaces 标题应分别添加到原始跳过和新跳过中。
进程跳过的状态也可能是 Active 如果它们从未打算完成，例如跳过0(此跳过)。
跳过如何被接受¶
跳过是指 Accepted 经所有感兴趣的贡献者一致同意。我们需要一个具体的方法来判断是否达成了共识。当您认为跳过可以接受时，发送一封电子邮件到SCRICKIT-IMAGE邮件列表，主题如下：
建议接受跳过编号：<标题>
在您的电子邮件正文中，您应该：
链接到最新版本的跳过，
简要描述任何主要的争论点以及它们是如何解决的，
包括这样一句话：“如果从这封电子邮件开始的7天内没有实质性的反对意见，那么跳过将被接受；有关更多详细信息，请参阅跳过0。”
有关NumPy库中的等效示例，请参阅：https://mail.python.org/pipermail/numpy-discussion/2018-June/078345.html
发送电子邮件后，应确保从 Discussion 跳跃的部分，这样人们以后就可以找到它。
一般来说，跳过的作者会发送这封电子邮件，但任何人都可以这样做-重要的是要确保每个人都知道跳过即将被接受，并给他们最后一次回复的机会。如果有什么特殊的原因需要将最后评论期限延长到7天以上，那也没什么，只要在电子邮件中说明即可。你不应该少于7天，因为有时人们在旅行或类似的地方，需要一些时间来回应。
总的来说，目标是确保社会有共识，而不是提供一个僵化的政策，让人们试图游戏。当你有疑问的时候，你应该倾向于寻求更多的反馈，寻找妥协的机会。
如果最终评议期过去了，没有任何实质性的反对意见，那么跳过可以被正式标记 Accepted 。你应该发送一封后续电子邮件通知名单(庆祝表情符号可选，但鼓励使用🎉✨)，然后通过设置其 :Status: 至 Accepted ，以及它的 :Resolution: 标题指向您的后续电子邮件的链接。
如果有 are 实质性反对，则跳过仍在 Draft 尽管如此，讨论仍在照常进行，一旦反对意见得到解决，稍后可提议再次接受。
在非常情况下，当核心开发人员之间无法达成共识时， scikit-image Steering Council 可能会被要求决定有争议的跳过是否 Accepted 。
维修¶
通常，标准跟踪跳转在达到最终状态后不再进行修改，因为代码和项目文档被视为已实现功能的最终参考。然而，在特殊情况下，它们可能会更新。
过程跳过可能会随着时间的推移而更新，以反映对开发实践和其他细节的更改。在这些情况下遵循的确切过程将取决于正在更新的跳过的性质和目的。
格式和模板¶
跳过是使用UTF-8编码的文本文件 reStructuredText 格式化。请参阅 跳过X模板和说明 文件和 reStructuredTextPrimer 以获取更多信息。我们用 Sphinx 将跳过转换为HTML以在Web上查看的步骤 2.
报头前导码¶
每一跳过必须以报头前同步码开始。标头必须按以下顺序显示。标头标有 * 是可选的。所有其他标头都是必需的。**
:Author: <list of authors' real names and optionally, email addresses>
:Status: <Draft | Active | Accepted | Deferred | Rejected |
Withdrawn | Final | Superseded>
:Type: <Standards Track | Process>
:Created: <date created on, in dd-mmm-yyyy format>
* :Requires: <skip numbers>
* :skimage-Version: <version number>
* :Replaces: <skip number>
* :Replaced-By: <skip number>
* :Resolution: <url>
作者标题列出了该跳过的所有作者的姓名，以及可选的电子邮件地址。Author标头值的格式必须为
随机J.用户<Address@Dom.ain>
如果包括电子邮件地址，并且只
随机J.用户
如果没有给出地址的话。如果有多个作者，则每个作者都应该在单独的一行上。
讨论¶
参考文献和脚注¶
版权所有¶
本文档已被置于公有领域。