跳过 2 — scikit-image 使命宣言#

作者:

Juan Nunez-Iglesias <juan.nunez-iglesias@monash.edu>

作者:

Stéfan van der Walt <stefanv@berkeley.edu>

作者:

乔什·华纳

作者:

弗朗索瓦·布洛涅

作者:

伊曼纽尔·古利亚特

作者:

马克·哈福克

作者:

Lars Grüter

作者:

叶戈尔·潘菲洛夫

作者:

格雷戈里·李

状态:

活跃

类型:

过程

创建:

2018年12月8日

已解决:

分辨率:

skimage-版本:

0.16

摘要#

scikit-image 应采用以下文档作为其使命声明。此声明将在 scikit-image 主页和自述文件中显著展示，同时也会出现在贡献者和核心开发者指南中。关于 API 和库未来的决策将参考此文档。（参见 SKIP 1 — scikit-image 治理和决策制定。）

2018年7月，我（Juan）发表了一篇博文，大致概述了我对scikit-image [1] 路线图的期望，但在最终确定之前请求社区的意见。我认为我们已经收集了足够的意见，可以继续正式采纳。大多数意见都是积极的，所以下面我只会总结“负面”意见，归类为“被拒绝的想法”。

详细描述#

（或者：这个提案解决了什么问题？）

在过去的几年里，scikit-image 有些“漂泊不定”，新老贡献者不断加入，添加他们当时需要的小功能，然后又消失一段时间。这*很好*，我们希望鼓励更多这样的行为，但它也缺乏方向。此外，如果没有一个集中的路线图来集中精力，许多这些贡献就会半途而废，因为新贡献者很难达到我们严格（且大多未成文）的代码标准。

实现#

我们的使命#

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

  • 易于使用和安装。我们在引入新依赖时非常谨慎，有时会剔除现有的依赖，或者将它们设为可选。我们API中的所有函数都有详细的文档字符串，明确说明预期的输入和输出。

  • 提供一个**一致的API**。概念上相同的参数在函数签名中具有相同的名字和位置。

  • 确保正确性。测试覆盖率接近100%，代码在被纳入库之前至少由两名核心开发者审查。

  • 关心用户的数据。我们有一个功能性的 [2] API，并且除非明确指示，否则不会修改输入数组。

  • 推广**图像处理教育**，提供广泛的教材文档。

我们的价值观#

  • 我们是包容的。我们继续欢迎并指导那些正在做出首次贡献的新人。

  • 我们是社区驱动的。关于API和功能的决策是由我们用户的需求驱动的，而不是由核心团队的突发奇想决定的。（参见 SKIP 1 — scikit-image 治理和决策制定。）

  • 我们主要服务于科学应用，而不是像 Photoshop 或 GIMP 这样的“消费者”图像编辑。这通常意味着优先支持 n 维数据，并拒绝实现那些科学价值不大的“炫目”滤镜。

  • 我们重视简单、可读的实现，而不是追求极致的性能。易于理解的可读代码，无论是对新加入者还是维护者，都使得贡献新代码以及预防错误变得更加容易。这意味着，例如，如果我们能将代码行数减少一半，即使会导致20%的性能下降，我们也会选择这样做。

  • 我们重视教育和文档。所有函数都应该有 NumPy 风格的文档字符串 [3]，最好带有示例，以及展示该函数在科学应用中如何使用的图库示例。核心开发者积极参与完成文档示例。

  • 我们不做魔法。我们使用 NumPy 数组而不是花哨的外观对象 [12]，我们更倾向于教育用户而不是替他们做决定。这并不排除合理的默认设置。 [4]

本文档#

就像 Python 之禅 [5] 和 PEP8 指导大多数 Python 代码的风格和实现细节一样，本指南旨在指导关于 scikit-image 未来的决策，无论是代码风格、是否接受新功能，还是是否引入新依赖，以及其他方面。

参考文献#

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

  • 原文博客文章 [1]

  • GitHub 问题 [6]

  • image.sc 论坛帖子 [7]

  • SKIP GitHub 拉取请求 [8]

脚注

向后兼容性#

此 SKIP 正式化了 scikit-image 中一直以来的非书面文化，因此不会引发任何向后兼容性问题。

替代方案#

在原始讨论中，有两个主题最终被否决，详情如下：

处理元数据#

在我的原始帖子中，我建议 scikit-image 在 1.0 版本之前应该有一些形式的元数据处理。其中包括 Mark Harfouche、Curtis Rueden 和 Dan Allan 都建议 (a) 也许 scikit-image 不需要处理元数据，而是可以专注于成为一个稳健的底层库，另一个像 XArray 这样的库可以使用它来包含元数据处理，以及 (b) 无论如何，元数据支持可以在不破坏 1.0 API 的情况下稍后添加。我认为这些都是非常好的观点，而且元数据处理非常困难，我不介意暂时将此问题搁置。

魔法思维#

Philipp Hanslovsky 建议 [9]，关于“做魔法”，在某些情况下是可取的，一个好的解决方案是在非魔法层之上提供一个魔法层。我同意这一评估，但在1.0之前，scikit-image 应保持为非魔法层。

讨论#

请参阅下面的参考文献。

参考文献#

On this page
显示源代码