SKIP 0 — 目的とプロセス#

著者:: Jarrod Millman <millman@berkeley.edu>
著者:: Juan Nunez-Iglesias <juan.nunez-iglesias@monash.edu>
著者:: Stéfan van der Walt <stefanv@berkeley.edu>
ステータス:: アクティブ
タイプ:: プロセス
作成:: 2019-07-30

SKIPとは何か？#

SKIPは**s**ci**k**it-**i**mage **p**roposalの略です。SKIPは、コミュニティに情報を提供したり、scikit-imageまたはそのプロセスや環境の新しい機能を記述する設計文書です。SKIPは、提案された変更の理由と、該当する場合は簡潔な技術仕様を提供する必要があります。

SKIPは、主要な新機能の提案、問題に関するコミュニティからの意見収集、scikit-imageに組み込まれた設計上の決定の文書化のための主要なメカニズムとなることを意図しています。SKIPの著者は、コミュニティ内でコンセンサスを構築し、反対意見を文書化する責任があります。

SKIPはバージョン管理されたリポジトリにテキストファイルとして保持されるため、その改訂履歴は機能提案の履歴記録となります[1]。

タイプ#

SKIPには3種類あります。

**標準トラック** SKIPは、scikit-imageの新しい機能または実装について記述します。
**情報提供** SKIPは、scikit-imageの設計上の問題について記述するか、Pythonコミュニティに一般的なガイドラインまたは情報を提供しますが、新しい機能を提案するものではありません。情報提供SKIPは必ずしもscikit-imageコミュニティのコンセンサスまたは推奨事項を表すものではないため、ユーザーと実装者は情報提供SKIPを無視しても構いません。
**プロセス** SKIPは、scikit-imageを取り巻くプロセスについて記述するか、プロセスへの変更（またはプロセスにおけるイベント）を提案します。プロセスSKIPは標準トラックSKIPに似ていますが、scikit-imageライブラリ自体以外の分野に適用されます。実装を提案する場合がありますが、scikit-imageのコードベースには適用されません。コミュニティのコンセンサスが必要です。例としては、手順、ガイドライン、意思決定プロセスの変更、scikit-image開発で使用されるツールや環境の変更などがあります。メタSKIPもプロセスSKIPとみなされます。

SKIPワークフロー#

SKIPプロセスは、scikit-imageの新しいアイデアから始まります。SKIPには、1つの主要な提案または新しいアイデアを含める必要があります。小さな機能強化やパッチは、多くの場合、SKIPを必要とせず、scikit-imageのリポジトリへのプルリクエストでscikit-image開発ワークフローに挿入できます。SKIPが集中しているほど、承認される可能性が高くなります。

各SKIPには、以下に説明するスタイルと形式を使用してSKIPを作成し、適切なフォーラムでの議論を監督し、アイデアに関するコミュニティコンセンサスを構築しようとするチャンピオン（担当者）が必要です。SKIPチャンピオン（別名著者）は、まず、そのアイデアがSKIPに適しているかどうかを確認する必要があります。これを行う最良の方法は、scikit-imageの開発者フォーラムに投稿することです。

提案は、doc/source/skipsディレクトリにskip-<n>.rstという名前で（例：skip-35.rst）、SKIP X — テンプレートと手順ファイルを使用して、GitHubプルリクエストを介してドラフトSKIPとして提出する必要があります。

PRが作成されたら、議論のために開発者フォーラムでSKIPを発表する必要があります（PR自体へのコメントは、軽微な編集と技術的な修正に制限する必要があります）。

できるだけ早く、PRはマージする必要があります（議論中に承認されたかどうかに関係なく）。一貫した議論を概説し、合理的に完全であると考えられるSKIPは、議論中に承認されたかどうかに関係なく、楽観的にマージする必要があります。著者はSKIPを更新または拡張するための追加のPRを作成したり、メンテナはステータス、議論のURLなどを設定するための追加のPRを作成したりできます。

標準トラックSKIPは、設計文書と参照実装の2つの部分で構成されています。原則としてうまくいくと思われるアイデアでも、実際には非現実的であることが判明することが多いため、少なくともプロトタイプ実装をSKIPと同時に開発することを一般的に推奨します。WIP（進行中）として適切にマークされている限り、プロトタイプ実装をscikit-imageリポジトリへのPRとして利用可能にすることが理にかなうことがよくあります。

レビューと解決#

SKIPは開発者フォーラムで議論されます。SKIPのステータスの可能なパスは以下のとおりです。

すべてのSKIPはDraftステータスで作成する必要があります。

最終的に、議論の後、SKIPを承認すべきというコンセンサスが得られる可能性があります。詳細については、次のセクションを参照してください。この時点で、ステータスはAcceptedになります。

SKIPがAcceptedされると、参照実装を完了する必要があります。参照実装が完成し、メインソースコードリポジトリに組み込まれると、ステータスはFinalに変更されます。

言語機能または標準ライブラリアーPIの長期的な安定性をコミットする前に、追加の設計とインターフェースのフィードバックを収集するために、SKIPを「暫定」とマークすることもできます。これは「暫定的に承認済み」の略で、提案が参照実装への組み込みが承認されたことを示しますが、完全な設計を「最終的」と見なす前に、追加のユーザーフィードバックが必要です。通常の承認済みSKIPとは異なり、暫定的に承認済みSKIPは、関連する変更がリリースに含まれた後でも、拒否または取り消される可能性があります。

可能な限り、「暫定」ステータスに依存する必要性を回避するために（例：後でSKIPにいくつかの機能を延期することによって）、提案の範囲を縮小することが好ましいと考えられます。このステータスは、より広いエコシステムでバージョン互換性の課題につながる可能性があります。

SKIPにはDeferredステータスを割り当てることもできます。SKIPの進捗がない場合、SKIPの作者またはコア開発者はSKIPにこのステータスを割り当てることができます。

SKIPはRejectedにすることもできます。すべてが言われた後、それは良いアイデアではなかったのかもしれません。この事実を記録しておくことが依然として重要です。Withdrawnステータスは似ていますが、これはSKIPの作者自身がSKIPは実際には悪いアイデアであると判断したか、競合する提案の方が優れた代替案であることを受け入れたことを意味します。

SKIPがAccepted、Rejected、またはWithdrawnになると、それに応じてSKIPを更新する必要があります。ステータスフィールドの更新に加えて、少なくともResolutionヘッダーを、議論フォーラムの関連投稿へのリンクとともに追加する必要があります。

SKIPは、別のSKIPによってSupersededされることもあり、元のSKIPは時代遅れになります。Replaced-ByとReplacesヘッダーは、それぞれ元のSKIPと新しいSKIPに追加する必要があります。

プロセスSKIPは、完了することを意図していない場合（例：SKIP 0（このSKIP））にもActiveステータスを持つ場合があります。

SKIPが承認される方法#

SKIPは、関係するすべての貢献者のコンセンサスによってAcceptedになります。コンセンサスが得られたかどうかを判断する具体的な方法が必要です。SKIPを承認する準備ができたと思ったら、開発者フォーラムで次のような件名のトピックを開始します。

SKIP #<番号>の承認提案：<タイトル>

メール本文には、

最新のSKIPへのリンク、
主要な論点とその解決方法の簡単な説明、
「このメールから7日以内に実質的な異議がない場合は、SKIPは承認されます。詳細については、SKIP 0を参照してください。」のような文を含めます。

NumPyライブラリの同等の例については、以下を参照してください。 https://mail.python.org/pipermail/numpy-discussion/2018-June/078345.html

メールを送信したら、後で人が見つけられるように、SKIPのDiscussionセクションからメールスレッドへのリンクを必ず作成してください。

一般的に、SKIPの著者がこのメールを送信しますが、誰でも送信できます。重要なのは、SKIPが承認されようとしているときに全員がそれを認識し、回答する最後の機会を与えることです。この最終コメント期間を7日以上延長する特別な理由がある場合は、メールでそれを明記してください。7日未満にするべきではありません。なぜなら、旅行中などの人もいて、回答するのに時間が必要になることがあるからです。

一般的に、目標はコミュニティにコンセンサスを得ることです。人々が利用しようとするための厳格なポリシーを提供することではありません。疑わしい場合は、より多くのフィードバックを求め、妥協の機会を探すことを優先してください。

最終コメント期間が実質的な異議なく経過した場合は、SKIPを正式にAcceptedとマークできます。リストにフォローアップメールを送信し（祝いの絵文字はオプションですが推奨します🎉✨）、:Status:をAcceptedに、:Resolution:ヘッダーをフォローアップメールへのリンクに設定してSKIPを更新します。

重要な異議があれば、SKIP はDraft状態のまま残り、通常の議論が続けられます。異議が解決された後に、改めて承認のために提案することができます。

まれに、コア開発者間でコンセンサスが得られない場合、scikit-image ステアリング評議会に、物議を醸しているSKIPがAcceptedかどうかを決定するよう依頼することがあります。

メンテナンス#

一般的に、Standards track SKIPは、Final状態に達した後、変更されません。コードとプロジェクトドキュメントが実装された機能の最終的な参照とみなされるためです。ただし、特別な状況下では更新される場合があります。

Process SKIPは、開発プラクティスやその他の詳細の変更を反映するために、随時更新される場合があります。これらの場合に実行される正確なプロセスは、更新されるSKIPの性質と目的に依存します。

形式とテンプレート#

SKIPは、reStructuredText形式を使用するUTF-8エンコードのテキストファイルです。詳細は、SKIP X — テンプレートと手順ファイルとreStructuredTextPrimerを参照してください。Sphinxを使用してSKIPをHTMLに変換し、Web上で表示します[2]。

ヘッダー前文#

各SKIPは、ヘッダー前文で始まる必要があります。ヘッダーは次の順序で表示する必要があります。*でマークされたヘッダーはオプションです。その他のヘッダーは必須です。

  :Author: <list of authors' real names and optionally, email addresses>
  :Status: <Draft | Active | Accepted | Deferred | Rejected |
           Withdrawn | Final | Superseded>
  :Type: <Standards Track | Process>
  :Created: <date created on, in dd-mmm-yyyy format>
* :Requires: <skip numbers>
* :skimage-Version: <version number>
* :Replaces: <skip number>
* :Replaced-By: <skip number>
* :Resolution: <url>

Authorヘッダーには、SKIPのすべての作成者の名前、およびオプションでメールアドレスをリストします。Authorヘッダー値の形式は、

Random J. User <address@dom.ain>

（メールアドレスを含める場合）、または

Random J. User

（アドレスを指定しない場合）です。複数の作成者がいる場合は、それぞれを別行に記述します。

議論#

scikit-image/scikit-image#3585

参考文献と脚注#

著作権#

このドキュメントはパブリックドメインに置かれています。