セマンティック カーネルへの貢献
セマンティック カーネルに貢献するには、問題の送信、ディスカッションの開始、プル要求 (PR) の送信を行います。 コードの投稿は非常に高く評価されていますが、発生した問題に関する問題を報告するだけでも、私たちの取り組みに集中できるので、貢献するのに最適な方法です。
問題の報告とフィードバック
バグ レポート、API の提案、全体的なフィードバックは常に歓迎します。 GitHub を使用しているため、 Issues タブと Discussions タブを使用してチームとの会話を開始できます。 以下に、問題とフィードバックを送信する際のヒントをいくつか示します。このヒントを使用すると、できるだけ早くフィードバックに応答できます。
問題の報告
SDK の新しい問題は問題の 一覧で報告できますが新しい問題を提出する前に、問題の一覧を検索して、まだ存在していないことを確認してください。 セマンティック カーネルのドキュメント (このサイト) に問題がある場合は、 Semantic Kernel のドキュメント リポジトリに問題を提出してください。
場合は報告したい内容に関する既存の問題を見つけます。ディスカッションに独自のフィードバックを含めてください。 また、バックログの一般的な問題に優先順位を付けるのに役立つので、元の投稿のアップ投票 (👍 反応) も強くお勧めします。
適切なバグ レポートの作成
優れたバグ レポートを使用すると、保守担当者が根本的な問題を簡単に確認し、根本原因を特定できます。 バグ レポートが優れているほど、問題を迅速に解決できます。 理想的には、バグ レポートには次の情報が含まれている必要があります。
- 問題の概要を説明します。
- ミニマルな再現、つまり、間違った動作を再現するために必要なコード/構成の最小サイズ。
- 実際の動作とは対照的に展開された動作の説明観察されました。
- 環境に関する情報: OS/ディストリビューション、CPU アーキテクチャ、SDK のバージョンなど
- 追加情報(たとえば、以前のバージョンからの回帰ですか? 既知の回避策はありますか?
フィードバックの送信
セマンティック カーネルに関する一般的なフィードバックや、それを改善する方法に関するアイデアがある場合は、 discussions ボードで共有してください。 新しいディスカッションを開始する前に、ディスカッションの一覧を検索して、まだ存在していないことを確認してください。
ideas カテゴリを使用することをお勧めしますセマンティック カーネルについて質問がある場合は、Q&A カテゴリを共有する特定のアイデアがある場合。
また、 Semantic Kernel Discord サーバーに参加することで、Discord コミュニティでディスカッションを開始 (および作成したすべてのフィードバックを共有) することもできます。
フィードバックの優先順位付けに関するヘルプ
現在、アップ投票を使用してバックログの問題や機能に優先順位を付けるのに役立ちます。そのため、対処したい問題やディスカッションをアップ投票してください。
他のユーザーが機能の恩恵を受けると思われる場合は、他のユーザーに問題のアップ投票を依頼することもお勧めします。 これは、ほとんどのユーザーに影響を与える問題に優先順位を付けるのに役立ちます。 Discord の同僚、友人、または community に問い合わせ 問題またはディスカッションへのリンクを共有することで、問題をアップ投票することができます。
pull request の送信
セマンティック カーネルへの貢献を歓迎します。 バグ修正または投稿したい新機能がある場合は、以下の手順に従って pull request (PR) を送信してください。 その後、プロジェクトの保守担当者は、コードの変更を確認し、受け入れられたらマージします。
推奨される投稿ワークフロー
セマンティック カーネルに貢献するには、次のワークフローを使用することをお勧めします (これはセマンティック カーネル チームが使用するワークフローと同じです)。
- 作業に関する問題を作成します。
- 簡単な変更を行うには、この手順をスキップできます。
- トピックに既存の問題がある場合は、その問題を再利用します。
- 問題のディスカッションを使用して、提案された変更が適切であることをチームとコミュニティから同意します。
- 実装に取りかかる問題を明確に示します。 これにより、問題をユーザーに割り当て、他のユーザーが誤って問題に取り組まないことが保証されます。
- GitHub でリポジトリの個人用フォークを作成します (まだない場合)。
- フォークで、メイン (
git checkout -b mybranch) から分岐を作成します。- "issue-123" や "githubhandle-issue" など、意図を明確に伝えるようにブランチに名前を付けます。
- ブランチに変更を加えてコミットします。
- 変更に対応する新しいテストを追加します (該当する場合)。
- 変更を加えたリポジトリをビルドします。
- ビルドがクリーンであることを確認します。
- 新しいテストを含め、テストがすべて合格していることを確認します。
- リポジトリの main ブランチに対して PR を作成します。
- 変更が対処している問題または改善の内容を説明の中に示します。
- すべての継続的インテグレーション チェックが成功していることを確認します。
- コード保守担当者からの変更のフィードバックまたは承認を待ちます。
- エリア所有者がサインオフし、すべてのチェックが緑色になると、PR がマージされます。
投稿中の Dos と Don'ts
次に示す Dos and Don'ts の一覧は、セマンティック カーネルに投稿する際に、変更をできるだけ迅速に確認してマージするのに役立ちます。
次の操作を行います。
- Do 標準の .NET コーディング スタイルに従い Python コード スタイル します
- 操作 一般的なガイドラインと異なる場合は、変更するプロジェクトまたはファイルの現在のスタイルを優先します。
- 新機能を追加するときに テストを含めます。 バグを修正する場合は、まず、現在の動作がどのように壊れているかを示すテストを追加します。
- ディスカッションに集中 してください。 新しいトピックや関連するトピックが表示されたら、ディスカッションを並行して追跡するよりも、新しい問題を作成することをお勧めします。
- 実行 実装に取りかかる問題を明確に示します。
- 投稿に関するブログやツイートを してください。
注意 事項：
- 大きな pull request でチームを驚かせないでください 。 共同作成者をサポートするため、大量の時間を費やす前に方向性に同意できるように、問題を報告してディスカッションを開始することをお勧めします。
- 記述しなかったコードをコミットしないでください 。 セマンティック カーネルに追加するのに適していると思われるコードが見つかる場合は、問題を報告し、続行する前にディスカッションを開始します。
- ライセンス関連のファイルまたはヘッダーを変更する PR を送信しないでください 。 問題があると思われる場合は、問題を提出して、それについてお話し合いさせていただきます。
- 最初に問題を報告してチームと話し合うことなく 新しい API を作成しないでください。 ライブラリに新しいパブリックサーフェス領域を追加することは大きな問題であり、正しいことを確認したいと考えています。
重大な変更
コントリビューションでは、API シグネチャと動作の互換性を維持する必要があります。 既存のコードを中断する変更を行う場合は、問題を提出してアイデアについて話し合うか、破壊的変更が保証されていると思われる場合は変更してください。 それ以外の場合、重大な変更を含むコントリビューションは拒否されます。
継続的インテグレーション (CI) プロセス
継続的インテグレーション (CI) システムは、必要なビルドを自動的に実行し、PR のテスト (ローカルで実行する必要があるテストも含む) を実行します。 ビルドとテストの実行は、PR をマージする前にクリーンである必要があります。
何らかの理由で CI ビルドが失敗した場合、PR の問題は、エラーの原因を特定して対処できるようにリンクで更新されます。