SKIP 2 — scikit-image 使命宣言#

作者:

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

作者:

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

作者:

Josh Warner

作者:

François Boulogne

作者:

Emmanuelle Gouillart

作者:

Mark Harfouche

作者:

Lars Grüter

作者:

Egor Panfilov

作者:

Gregory Lee

状态:

活动

类型:

流程

创建时间:

2018-12-08

已解决:

解决方案:

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 数组而不是花哨的 facade 对象 [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 应该仍然是非魔法层。

讨论#

请参阅下面的参考文献。

参考文献#