跳过2-SCRICKIT-IMAGE任务说明¶

作者: Juan Nunez-Iglesias<juan.nunez-iglesias@monash.edu>
作者: Stéfan van der Walt<stefan v@berkeley.edu>
作者: 乔什·华纳
作者: 弗朗索瓦·布洛涅
作者: 伊曼纽尔·古亚特
作者: 马克·哈福什
作者: 拉尔斯·格鲁特
作者: 埃戈尔·潘菲洛夫
作者: 格雷戈里·李(Gregory Lee)
状态: 活动的
类型: 过程
已创建: 2018-12-08
已解决
分辨率
SKIMAGE-版本: 0.16

摘要¶

SCRICKIT-IMAGE应采用以下文件作为其使命声明。这一声明将在SCRICKIT-IMAGE主页和自述文件以及贡献者和核心开发人员指南中突出显示。有关API和库的未来的决策将参考本文档。(请参阅跳过1--科学工具包--形象治理和决策。)

2018年7月，我(Juan)发表了一篇博客文章，大致概述了我希望从SCRICKIT-IMAGE的路线图中获得什么 1, 但在最后敲定之前，他征求了社区的意见。我认为我们已经收集了足够长的时间来收集意见，可以推进正式通过。大多数评论都是正面的，所以下面我将在“拒绝的想法”一栏中总结一下“负面”的评论。

详细说明¶

(或者：这项提议解决了什么问题？)

在过去的几年里，SCRICKIT-IMAGE略有些飘忽不定，新老贡献者纷纷加入，添加了他们当时需要的小部分，然后又消失了一段时间。这是 fine 我们想要鼓励更多这样做，但它也缺乏方向。此外，如果没有协调一致的路线图来集中精力，这些贡献中的许多就会半途而废，因为新的贡献者很难达到我们严格的(主要是不成文的)代码标准。

实施¶

我们的使命¶

SCRICIT-IMAGE的目标是成为在Python中进行科学图像分析的参考库。我们通过以下方式实现这一目标：

存在 易于使用和安装 。我们在接受新的依赖项时非常谨慎，有时会剔除现有的依赖项，或者将其设置为可选的。我们的API中的所有函数都有详细的文档字符串，以阐明预期的输入和输出。
提供一个 一致的API 。概念上相同的参数在函数签名中具有相同的名称和位置。
确保正确性 。测试覆盖率接近100%，代码在被包含在库中之前至少要经过两名核心开发人员的审查。
关心用户数据 。我们有一个功能性的 2 API，除非明确指示，否则不要修改输入数组。
推介 图像处理教育 ，并附有丰富的教学文献。

我们的价值观¶

我们是包容的。我们继续欢迎和指导做出第一次贡献的新来者。
我们是社区驱动的。关于API和功能的决定是由我们用户的需求驱动的，而不是核心团队的突发奇想。(请参阅跳过1--科学工具包--形象治理和决策。)
我们主要服务于科学应用程序，在Photoshop或GIMP的脉络中进行“消费者”图像编辑。这通常意味着优先考虑对n维数据的支持，并拒绝实施几乎没有科学价值的“华而不实”的过滤器。
我们看重简单、可读的实现，而不是获得每一分每一秒的性能。对于新手和维护者来说，易于理解的易读代码使贡献新代码以及防止错误变得更容易。例如，这意味着，如果代码行数减少两倍，我们更愿意将速度降低20%。
我们重视教育和文件记录。所有函数都应具有NumPy样式的文档字符串 3, 最好是举例，以及展示该函数如何在科学应用中使用的图库例子。核心开发人员在完成文档示例方面发挥了积极作用。
我们不会变魔术。我们使用NumPy数组而不是花哨的外墙对象 12, 我们更愿意教育用户，而不是代表他们做出决定。这并不排除合理的违约。 4

本文档¶

就像 Python 的禅宗 5 和PEP8指南风格和实现细节在大多数Python代码中，本指南旨在指导有关SCRICKIT-IMAGE未来的决策，无论是在代码风格方面，是否接受新功能，或者是否采取新的依赖关系，等等。

参考文献¶

要了解有关本文档历史的更多信息，请阅读以下内容：

原创博客帖子 1
GitHub问题 6
Image.sc论坛帖子 7
跳过GitHub拉取请求 8

脚注

12: NumPy数组的使用是该声明中最受支持的组件，以及关于包容性、指导和文档的要点。我们有来自马克·哈弗什、罗伊·阿维塔尔和格雷格·李等人的+1。

向后兼容性¶

这一跳过正规化了SCRICKIT-IMAGE的不成文文化，因此不会引起任何向后兼容性问题。

替代方案¶

最初讨论中的两个主题最终被拒绝，详细情况如下：

处理元数据¶

在我最初的帖子中，我建议SCRICKIT-IMAGE在1.0之前应该有某种形式的元数据处理。在其他人中，Mark Harfouche、Curtis Rueden和Dan Allan都建议：(A)也许SCRICKIT-IMAGE不 need 来处理元数据，并且可以转而专注于成为一个健壮的低级库，另一个像XArray这样的库可以用来包括元数据处理，并且(B)不管怎样，可以在以后添加元数据支持，而不会破坏1.0API。我认为这些都是非常好的要点，而且元数据处理非常困难，我不介意暂时不讨论这个问题。

神奇的思维¶

菲利普·汉斯洛夫斯基建议 9 关于“做魔术”，在某些情况下是可取的，一个好的解决方案是提供一个建立在非魔术层之上的魔法层。我同意这个评估，但是，在1.0版本之前，SCRICKIT-IMAGE应该仍然是非魔法层。

讨论¶

请参阅下面的参考文献。

版权所有¶

本文档专门针对具有知识共享CC0许可证的公共领域 10. 根据CC0+，鼓励在适当的情况下归因于此来源 11.