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 陣列而不是花哨的門面物件[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 應保持為非魔法層。

討論#

請參閱下方的參考資料。

參考資料#