コア開発者ガイド#

新任のコア開発者の皆様、ようこそ！ コアチームは、あなたの仕事の質を高く評価しており、あなたとの協力を楽しんでいます。そのため、あなたをチームに招待いたしました。これまでのプロジェクトへの数々のご貢献に感謝いたします。

このドキュメントは、あなたの新しい役割のためのガイドラインを提供します。まず何よりも、プロジェクトのミッション、ビジョン、および価値観をよく理解する必要があります。疑問がある場合は、常にここを参照してください。

コアチームメンバーとして、他の貢献者をレビュープロセスを通じて導く責任を負うことになります。以下にいくつかのガイドラインを示します。

すべての貢献者は平等に扱われる#

あなたはメインブランチに直接変更をプッシュできるようになりましたが、決してそうすべきではありません。代わりに、以前と同様に、一般的な貢献者ガイドに従ってプルリクエストを作成し続けてください。

コア貢献者として、他の貢献者のプルリクエストをマージまたは承認する能力を獲得します。核兵器の起動キーのように、それは共有された力です。あなたは別のコアがプルリクエストを承認し、かつあなた自身がそれを注意深くレビューした後でのみマージする必要があります。（下記のレビュー、特に理解した変更のみをマージするを参照。）クリーンな git の履歴を確保するために、正当な理由がない限り、GitHub のSquash and Merge機能を使用してマージしてください。

レビュー#

良いレビューを行う方法#

貢献者には常に親切にしてください。ほとんどすべてのscikit-imageはボランティア活動であり、それに対して私たちは非常に感謝しています。アイデアや実装について建設的な批判を提供し、自分の作品が初心者のときにどのように評価されたかを思い出してください。

scikit-imageは、コードレビューにおけるメンターシップを重視しています。新しいユーザーは、git の経験がほとんどないため、より多くの手助けを必要とすることがよくあります。遠慮なく何度も繰り返し説明し、貢献者を認識しない場合は、開発ガイドまたはウェブ上のその他の GitHub ワークフローチュートリアルを指示してください。GitHub の仕組みを知っていると決めつけないでください（たとえば、多くの人はコミットを追加するとプルリクエストが自動的に更新されることに気づいていません）。優しく、丁寧で、親切な励ましが、新しいコア開発者になるか、放棄されたプルリクエストになるかの違いを生む可能性があります。

レビューの際は、以下に焦点を当ててください

  1. API: API は、ユーザーが最初にscikit-imageを使用するときに目にするものです。API は一度リリースすると変更が難しいため、シンプルで、機能的（つまり、状態を持たない）で、ライブラリの他の部分と一貫性があり、入力変数の変更は避ける必要があります。プロジェクトの非推奨ポリシーをよく理解してください。

  2. ドキュメント: 新しい機能には、それを説明するだけでなく、説明するギャラリーの例が必要です。

  3. アルゴリズム: 承認する前に、変更または追加されるコードを理解する必要があります。（下記の理解した変更のみをマージするを参照。）実装は主張どおりに機能し、シンプルで、読みやすく、効率的である必要があります。

  4. テスト: ライブラリへのすべての貢献はテストする必要があり、追加されたコードの各行は少なくとも 1 つのテストでカバーする必要があります。良いテストはコードを実行するだけでなく、コーナーケースも探求します。テストをレビューしないのは魅力的ですが、必ずレビューしてください。

  5. ライセンス: 新しい貢献は、scikit-image のライセンスと同じライセンス、または互換性のあるライセンスで使用できるようにする必要があります。BSD 互換ライセンスの例としては、MIT LicenseとApache License 2.0があります。疑問がある場合は、チームに助けを求めてください。あなたが貢献者であり、提出されたコードの著作権者でない場合は、元の作成者に承認を求め、LICENSE.txtに名前を含めてください。そのファイル内の他のエントリをテンプレートとして使用できます。

  6. 確立された方法: 一般的に、私たちは文献で十分に文書化され、画像コミュニティで広く使用されている、確立されたアルゴリズムと方法を含めることを目指しています。これは必須ではありませんが、新しい貢献は私たちの使命と一致する必要があります。

その他の変更は、些細なことである可能性があります。スペルミス、書式設定などです。貢献者にこれらの変更を行うように要求するのではなく、彼らのブランチにプッシュするか、GitHub の提案機能を使用して変更してください。（後者は、貢献者が変更を受け入れるかどうかを選択できるため、推奨されます。）

デフォルトのマージポリシーは、すべての PR コミットを単一のコミットにまとめることです。mainからの最新の変更を自分のブランチに取り込みたいユーザーは、リベースするのではなくマージするようにアドバイスする必要があります。マージの競合が発生した場合でも、貢献者が git に慣れていると知っている場合を除き、リベースを要求しないでください。代わりに、自分でブランチをリベースし、彼らのブランチに強制プッシュし、貢献者に強制プルする方法をアドバイスしてください。貢献者がもはやアクティブでない場合は、新しいプルリクエストを提出して元のプルリクエストを閉じることにより、そのブランチを引き継ぐことができます。そうする際は、貢献者の作品を無駄にしているのではないことを必ず伝えてください！

新しい変更をプッシュした後、プルリクエストにメモを追加してください。GitHub はこれらの通知を送信しません。

理解した変更のみをマージする#

長期的な保守性は重要な懸念事項です。コードは単に機能するだけでなく、複数のコア開発者が理解する必要があります。変更は将来行う必要があり、元の貢献者はすでに移動している可能性があります。

したがって、コードの変更を理解していない場合は、マージしないでください。遠慮なく助けを求めてください。私たちはコミュニティメンバーや、必要に応じて外部の開発者に相談してきた長い歴史があり、これを素晴らしい学習機会と捉えています。

私たちはコードベースの一部となるパッチ（およびバグ！）をまとめて「所有」しますが、マージした変更を保証していることになります。その責任を真剣に受け止めてください。

実際には、特定のプルリクエストをレビューおよび承認する 2 番目のコア開発者である場合、通常は承認後すぐに（繰り返しますが、GitHub の Squash and Merge 機能を使用して）マージします。このプロセスにはどのような例外がありますか？プルリクエストが特に物議を醸したり、多くの議論の対象となっている場合（API の変更など）、マージするまでに数日待つ必要があります。この待機時間により、プルリクエストの現在の状態に同意しない場合に、他の人が意見を表明する機会が得られます。もう 1 つの例外的な状況は、最初の承認レビューがかなり前に発生し、それ以来多くの変更が行われた場合です。

コミットをまとめる際、GitHub はすべてのコミットメッセージを連結します。変更の簡潔で整理された概要を示すように、結果のメッセージを編集してください。たとえば、PR 自体の説明を取得し、「pep8 fix」、「apply review comments」などの行を削除できます。すべての Co-authored-by エントリは保持してください。

Issue とプルリクエストをクローズする#

解決されていない問題をクローズする必要がある場合があります。これにはいくつかの理由が考えられます

  • 元の投稿者の背後にいる人が説明の要求に応答せず、コア開発者の誰も問題を再現できなかった場合。

  • 問題の修正が難しく、他の問題よりも優先して継続的な努力を費やすにはニッチすぎるユースケースと見なされた場合、または

  • ユースケースまたは機能リクエストが、コア開発者が scikit-image に属さないと感じている場合。

など。同様に、プルリクエストは、マージせずにクローズする必要がある場合があります。なぜなら、

  • プルリクエストは、追加のメンテナンス負担に見合わないと見なされるニッチな機能を実装する場合。

  • プルリクエストは便利な機能を実装しますが、scikit-image の標準に準拠させるにはかなりの労力が必要であり、元の貢献者は移動しており、必要な変更を行うことができる他の開発者が見つからない場合。または

  • プルリクエストが、わずかな高速化を実装するために、関数のコードの複雑さを大幅に増加させるなど、私たちの価値観に合わない変更を行う場合。

などがあります。

これらはすべてクローズするための正当な理由である可能性がありますが、説明なしに Issue やプルリクエストをクローズすることで貢献者を疎外しないように注意する必要があります。クローズするときは、メッセージで次の点を明確にする必要があります。

  • クローズの決定がどのように行われたかを明確に説明します。これは、意思決定がコミュニティミーティングで行われた場合に特に重要です。コミュニティミーティングには、Issue 自体のコメントスレッドほど目に見える記録はありません。

  • 貢献者の皆様の作品に感謝します。そして

  • 貢献者または他の人が決定に異議を唱えるための明確な道筋を提供します。

これらの点は、過去の貢献の結果に関係なく、すべての貢献者が歓迎されていると感じ、貢献し続けることができるようにするのに役立ちます。

その他のリソース#

コアメンバーとして、次のようなコミュニティと開発者のリソースに精通している必要があります。

これらのソーシャルリソース全てを監視する必要はありません。

新しいコアメンバーの招待#

どのコアメンバーも他の貢献者をコアチームに招待することができます。招待は、プライベートなメールリスト、skimage-core@discuss.scientific-python.orgで行われます。本稿執筆時点では、誰が招待されるかの厳密なルールはありませんが、最低限、以下の条件を満たしている必要があります：プロジェクトに少なくとも6ヶ月間参加していること、自身で重要な変更を貢献していること、他者の作業の議論やレビューに貢献していること、そしてコミュニティの価値観にふさわしい方法で協力していること。

このガイドへの貢献!#

このガイドは、現在のコア開発者の経験を反映したものです。私たちは、今となっては当たり前になっていること、つまり新しいチームメンバーであるあなたがより簡単に見つけることができるようなことを見落としている可能性があります。ご質問があれば、他のコア開発者に質問し、得られた知見をプルリクエストとして提出してください。

結論#

あなたをチームに迎え入れることができ、大変嬉しく思っています！コードベースとコミュニティへのあなたの貢献を楽しみにしています。事前に感謝いたします！