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のホームページとREADME、そして貢献者とコア開発者ガイドで目立つように掲載されます。APIとライブラリの将来に関する決定はこの文書を参照して行われます。（SKIP 1 — scikit-imageガバナンスと意思決定を参照）

2018年7月、私（Juan）はブログ記事を公開し、scikit-imageのロードマップとして何を望んでいるかを概説しましたが[1]、最終決定する前にコミュニティからのコメントを求めました。十分なコメントが集まったと考え、正式な採用に向けて進めることができます。ほとんどのコメントは肯定的だったので、以下では「棄却されたアイデア」の項で「否定的」なコメントを要約します。

詳細な説明#

（または：この提案が解決する問題とは？）

過去数年、scikit-imageは少し「漂流」しており、新規とベテランの貢献者が入り乱れ、その時々に必要な小さな部分を付け加え、しばらくの間姿を消すことを繰り返していました。これは問題ありませんし、さらに多くの貢献を促したいと考えていますが、方向性が欠けています。さらに、集中して努力するためのロードマップがないため、これらの貢献の多くは道半ばで頓挫します。新規貢献者にとって、私たちの厳格な（そして大部分が文書化されていない）コードの基準を満たすことが困難だからです。

実装#

私たちのミッション#

scikit-imageは、Pythonにおける科学的画像解析のための参照ライブラリとなることを目指しています。これは、以下によって実現します。

  • 使いやすく、インストールしやすいこと。新しい依存関係の追加には慎重であり、既存の依存関係を削減したり、オプションにしたりすることもあります。APIのすべての関数には、期待される入力と出力を明確にする包括的なdocstringがあります。

  • 一貫したAPIを提供すること。概念的に同一の引数は、関数シグネチャで同じ名前と位置を持ちます。

  • 正確性を確保すること。テストカバレッジはほぼ100％であり、コードはライブラリに含める前に少なくとも2人のコア開発者によってレビューされます。

  • ユーザーのデータを守ること。機能的な[2] APIを持ち、明示的に指示されない限り入力配列を変更しません。

  • 包括的な教育用ドキュメントにより、画像処理の教育を促進すること。

私たちの価値観#

  • 私たちは包括的です。初めて貢献する新規参入者を歓迎し、指導し続けます。

  • 私たちはコミュニティ主導です。APIと機能に関する決定は、コアチームの思いつきではなく、ユーザーの要件によって推進されます。（SKIP 1 — scikit-imageガバナンスと意思決定を参照）

  • 私たちは主に科学的アプリケーションに焦点を当てており、PhotoshopやGIMPのような「消費者向け」の画像編集には重点を置いていません。これは、多くの場合、n次元データのサポートを優先し、「派手な」フィルターの実装（科学的な価値がほとんどないもの）を拒否することを意味します。

  • 私たちは、パフォーマンスを最大限に引き出すことよりも、シンプルで読みやすい実装を重視します。新規参入者とメンテナンス担当者の両方にとって理解しやすい、読みやすいコードは、新しいコードの貢献を容易にし、バグの発生を防ぎます。これは、例えば、コード行数を半分に減らすために20％の速度低下を許容することを意味します。

  • 私たちは教育とドキュメントを重視します。すべての関数にはNumPyスタイルのdocstring[3]（できれば例付き）と、その関数が科学的アプリケーションで使用される方法を示すギャラリーの例が必要です。コア開発者は、ドキュメントの例を完成させることに積極的に取り組んでいます。

  • 私たちは魔法は使いません。私たちは派手なファサードオブジェクト[12]ではなくNumPy配列を使用し、ユーザーに代わって決定を行うよりも、ユーザーを教育することを好みます。これは、適切なデフォルトを排除するものではありません。[4]

この文書#

Pythonの禅[5]とPEP8がほとんどのPythonコードのスタイルと実装の詳細をガイドするのと同じように、このガイドは、コードスタイル、新しい機能の受け入れ、新しい依存関係の追加など、scikit-imageの将来に関する決定をガイドすることを目的としています。

参考文献#

この文書の履歴の詳細については、以下をお読みください。

  • オリジナルのブログ投稿 [1]

  • GitHubのissue [6]

  • image.scフォーラムの投稿 [7]

  • SKIPのGitHubプルリクエスト [8]

脚注

下位互換性#

このSKIPは、これまで文書化されていなかったscikit-imageの文化を正式なものにするため、下位互換性の問題を引き起こしません。

代替案#

元の議論における2つのトピックは最終的に拒否されました。詳細は以下に示します。

メタデータの処理#

私の元の投稿では、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は非魔法的なレイヤーのままであるべきです。

議論#

以下の参考文献を参照してください。

参考文献#