Ultralytics YOLOのオープンソースリポジトリに貢献する理由は何ですか？

Ultralytics YOLOのオープンソースリポジトリへの貢献は、ソフトウェアを改善し、コミュニティ全体にとってより堅牢で機能豊富なものにします。貢献には、コードの改善、バグ修正、ドキュメントの改善、新機能の実装などが含まれます。さらに、貢献を通じて、他の優れた開発者や分野の専門家と協力でき、自身のスキルや評価を高められます。始め方の詳細については、Pull Requestによる貢献セクションを参照してください。

Ultralytics YOLOのコントリビューターライセンス契約（CLA）に署名するにはどうすればよいですか？

コントリビューターライセンス契約（CLA）に署名するには、Pull Requestを送信した後にCLA botが提供する手順に従ってください。この手続きにより、貢献内容がAGPL-3.0ライセンスの下で適切にライセンスされ、オープンソースプロジェクトの法的整合性が維持されます。Pull Requestに次の内容のコメントを追加してください。. 詳細については、CLAへの署名セクションをご覧ください。

Googleスタイルのdocstringとは何ですか。また、Ultralytics YOLOへのコントリビューションで必須とされているのはなぜですか？

Googleスタイルのdocstringは、関数やクラスについて明確で簡潔なドキュメントを提供し、コードの可読性と保守性を向上させます。これらのdocstringでは、特定の書式ルールに従って、関数の目的、引数、戻り値を説明します。Ultralytics YOLOにコントリビュートする際にGoogleスタイルのdocstringに従うことで、追加したコードを適切にドキュメント化し、容易に理解できるようになります。例とガイドラインについては、Googleスタイルのdocstringセクションをご覧ください。

変更をGitHub ActionsのCIテストに合格させるには、どうすればよいですか？

プルリクエストをマージするには、GitHub Actionsの継続的インテグレーション（CI）テストにすべて合格する必要があります。これらのテストには、リンティング、単体テスト、その他のチェックが含まれており、コードがプロジェクトの品質基準を満たしていることを確認します。CIの出力を確認し、問題があれば修正してください。CIプロセスとトラブルシューティングのヒントについて詳しくは、GitHub ActionsのCIテストセクションをご覧ください。

Ultralytics YOLOのリポジトリでバグを報告するには、どうすればよいですか？

バグを報告するには、バグレポートと併せて、明確で簡潔な最小再現可能例を提示してください。これにより、開発者が問題を迅速に特定して修正できます。問題を再現するのに十分でありながら、最小限の例になるようにしてください。バグ報告の詳しい手順については、バグの報告セクションをご覧ください。

自分のプロジェクトでUltralytics YOLOを使用する場合、AGPL-3.0ライセンスは何を意味しますか？

プロジェクトでAGPL-3.0ライセンスのUltralytics YOLOのコードまたはモデルを使用する場合、AGPL-3.0ライセンスにより、プロジェクト全体（派生物）もAGPL-3.0の下でライセンスされ、完全なソースコードを一般公開することが求められます。これにより、派生物を通じてソフトウェアのオープンソースの性質が維持されます。これらの要件を満たせない場合は、エンタープライズライセンスを取得する必要があります。詳細については、プロジェクトのオープンソース化セクションをご覧ください。

Ultralyticsオープンソースプロジェクトへの貢献#

ようこそ！Ultralyticsのオープンソースプロジェクトへの貢献をご検討いただき、心より歓迎いたします。皆様の参加は、リポジトリの品質向上に役立つだけでなく、コンピュータビジョンコミュニティ全体にも貢献します。このガイドでは、始めるための明確なガイドラインとベストプラクティスを説明します。

Watch: How to Contribute to Ultralytics Repository | Ultralytics Models, Datasets and Documentation 🚀

行動規範#

誰もが歓迎され、受け入れられる環境を確保するため、すべてのコントリビューターは行動規範を遵守する必要があります。コミュニティの中心にあるのは、敬意、親切さ、プロフェッショナリズムです。

プルリクエストを通じた貢献#

Pull Request（PR）による貢献を大いに歓迎します。レビューをできるだけ円滑に進めるため、次の手順に従ってください。

**リポジトリをフォークする：**まず、対象のUltralyticsリポジトリ（例：ultralytics/ultralytics）をGitHubアカウントにフォークします。
**ブランチを作成する：**フォークしたリポジトリに、変更内容を明確に示す説明的な名前の新しいブランチを作成します（例：fix-issue-123、add-feature-xyz）。
**変更を加える：**改善や修正を実装します。コードがプロジェクトのスタイルガイドラインに従っており、新しいエラーや警告を発生させないことを確認してください。
**変更をテストする：**送信前にローカルで変更をテストし、期待どおりに動作し、リグレッションを引き起こさないことを確認します。新しい機能を導入する場合は、テストを追加してください。
**変更をコミットする：**簡潔で説明的なコミットメッセージを付けて変更をコミットします。特定のIssueに対応する変更の場合は、Issue番号を含めてください（例：Fix #123: Corrected calculation error.）。
**Pull Requestを作成する：**ブランチから元のUltralyticsリポジトリのmainブランチにPull Requestを送信します。変更の目的と範囲を説明する明確なタイトルと詳細な説明を記載してください。

開発環境のインストール#

フォーク（またはメインリポジトリ）をクローンし、編集可能モード（-e）でインストールします。これにより、Pythonがローカルファイルを実行し、再インストールなしですべての変更を反映できるようになります。

git clone https://github.com/YOUR_USERNAME/ultralytics.git
cd ultralytics
pip install -e .

PyPIパッケージの代わりにフォークに依存させるには、pipまたはrequirements.txtをフォークのブランチに向けます。

git+https://github.com/YOUR_USERNAME/ultralytics.git@my-custom-branch

ドキュメントの変更#

ドキュメントのソースはdocs/en/にあります。リポジトリのルートから開発用依存関係をインストールし、PRを作成する前に完全なstrict検証を実行してください。

uv pip install -e ".[dev]"
python docs/build_docs.py

検証では、zensical build --strictを実行する前に、生成されるリファレンス、マクロ、比較ページを準備します。マクロを使用しないページをより迅速にライブプレビューするには、zensical serveを実行してください。

CLAの署名#

Pull Requestをマージする前に、コントリビューターライセンス契約（CLA）に署名する必要があります。この法的契約により、貢献内容が適切にライセンスされ、プロジェクトをAGPL-3.0ライセンスの下で継続的に配布できます。

Pull Requestを送信すると、CLA botが署名手続きを案内します。CLAに署名するには、PRに次の内容のコメントを追加してください。

I have read the CLA Document and I sign the CLA

Googleスタイル形式のドキュメント文字列#

新しい関数やクラスを追加する場合は、明確で標準化されたドキュメントとなるよう、Googleスタイルのdocstringを含めてください。入力と出力の両方のtypesを必ず括弧で囲んでください（例：(bool)、(np.ndarray)）。

Docstringの例

この例では、標準的なGoogleスタイルのdocstring形式を示します。関数の説明、引数、戻り値、例が読みやすく明確に分離されている点に注目してください。

def example_function(arg1, arg2=4):
    """Example function demonstrating Google-style docstrings.

    Args:
        arg1 (int): The first argument.
        arg2 (int): The second argument.

    Returns:
        (bool): True if arguments are equal, False otherwise.

    Examples:
        >>> example_function(4, 4)  # True
        >>> example_function(1, 2)  # False
    """
    return arg1 == arg2

GitHub Actions CIテスト#

すべてのPull Requestは、マージする前にGitHub Actionsの継続的インテグレーション（CI）テストに合格する必要があります。これらのテストには、lint、単体テスト、その他のチェックが含まれ、変更がプロジェクトの品質基準を満たしていることを確認します。CIの出力を確認し、発生した問題に対処してください。

コードコントリビューションのベストプラクティス#

Ultralyticsプロジェクトにコードを貢献する際は、次のベストプラクティスを念頭に置いてください。

**コードの重複を避ける：**可能な限り既存のコードを再利用し、不要な引数を最小限に抑えます。
**小さく、焦点を絞った変更にする：**大規模な変更ではなく、対象を絞った修正に集中します。
**可能な限り簡素化する：**コードを簡素化したり、不要な部分を削除したりできる箇所を探します。
**互換性を考慮する：**変更を加える前に、Ultralyticsを使用する既存のコードを壊す可能性がないか検討します。
一貫したフォーマットを使用する：Ruff Formatterなどのツールは、スタイルの一貫性の維持に役立ちます。
**適切なテストを追加する：**新機能が期待どおりに動作することを確認するため、テストを含めます。

プルリクエストのレビュー#

Pull Requestのレビューも、貢献するための有意義な方法です。PRをレビューする際は、次の点を確認してください。

**単体テストを確認する：**PRに新機能や変更に対するテストが含まれていることを確認します。
**ドキュメントの更新をレビューする：**変更を反映するよう、ドキュメントが更新されていることを確認します。
**パフォーマンスへの影響を評価する：**変更がパフォーマンスに与える影響を検討します。
**CIテストを確認する：**すべての継続的インテグレーションテストに合格していることを確認します。
**建設的なフィードバックを提供する：**問題や懸念事項について、具体的で明確なフィードバックを提供します。
**努力を認める：**前向きな協力関係を維持するため、作成者の作業に謝意を示します。

バグの報告#

バグ報告はプロジェクトの品質と信頼性の向上に役立つため、非常に重視しています。GitHub Issuesでバグを報告する際は、次の点に留意してください。

**既存のIssueを確認する：**まず検索し、そのバグがすでに報告されていないか確認します。
**最小再現可能例を提供する：**問題を一貫して再現する、小さく自己完結したコードスニペットを作成します。これは効率的なデバッグに不可欠です。
**環境を説明する：**オペレーティングシステム、Pythonのバージョン、関連するライブラリのバージョン（例：torch、ultralytics）、ハードウェア（CPU/GPU）を指定します。
**期待される動作と実際の動作を説明する：**期待した動作と実際に発生したことを明確に記載します。エラーメッセージやトレースバックも含めてください。

ライセンス#

Ultralyticsは、リポジトリにGNU Affero一般公衆利用許諾契約書 v3.0（AGPL-3.0）を使用しています。このライセンスは、ソフトウェア開発におけるオープン性、透明性、共同での改善を促進します。これにより、すべてのユーザーがソフトウェアを使用、変更、共有する自由を持ち、協力とイノベーションに富んだ強固なコミュニティの形成が促されます。

すべてのコントリビューターには、Ultralyticsのオープンソースコミュニティに効果的かつ倫理的に貢献するため、AGPL-3.0ライセンスの条項を理解しておくことを推奨します。

YOLOプロジェクトをAGPL-3.0の下でオープンソース化する#

プロジェクトでUltralytics YOLOのモデルやコードを使用していますか？AGPL-3.0ライセンスでは、派生物全体もAGPL-3.0の下でオープンソース化することが求められます。これにより、変更やオープンソースを基盤として構築された大規模なプロジェクトもオープンな状態に保たれます。

AGPL-3.0への準拠が重要な理由#

**ソフトウェアをオープンに保つ：**改善や派生物がコミュニティに還元されることを保証します。
**法的要件：**AGPL-3.0でライセンスされたコードを使用すると、プロジェクトはその条項に拘束されます。
**協力を促進する：**共有と透明性を促します。

プロジェクトをオープンソース化したくない場合は、Enterprise Licenseの取得を検討してください。

AGPL-3.0に準拠する方法#

準拠するには、プロジェクトの完全な対応ソースコードをAGPL-3.0ライセンスの下で一般公開する必要があります。

開始地点を選択する：
- **Ultralytics YOLOをフォークする：**Ultralytics YOLOを基盤として密接に構築する場合は、Ultralytics YOLOリポジトリを直接フォークします。
- **Ultralyticsテンプレートを使用する：**YOLOを統合したクリーンでモジュール化された構成を始めるには、Ultralyticsテンプレートリポジトリを使用します。
プロジェクトにライセンスを付与する：
- AGPL-3.0ライセンスの全文を含むLICENSEファイルを追加します。
- 各ソースファイルの先頭に、ライセンスを示す通知を追加します。
ソースコードを公開する：
- プロジェクト全体のソースコードを一般からアクセス可能にします（例：GitHub上）。これには次のものが含まれます。
  - YOLOモデルまたはコードを組み込んだ、完全な大規模アプリケーションまたはシステム。
  - 元のUltralytics YOLOコードに加えた変更。
  - トレーニング、検証、推論用のスクリプト。
  - 変更またはファインチューニングした場合のモデルウェイト。
  - 設定ファイル、環境設定（requirements.txt、Dockerfiles）。
  - Webアプリケーションの一部である場合のバックエンドおよびフロントエンドコード。
  - 変更したサードパーティライブラリ。
  - 実行または再トレーニングに必要で、かつ再配布可能な場合のトレーニングデータ。
明確にドキュメント化する：
- プロジェクトがAGPL-3.0の下でライセンスされていることを示すよう、README.mdを更新します。
- ソースコードからプロジェクトをセットアップ、ビルド、実行する方法を明確に説明します。
- 元のリポジトリへのリンクを記載し、Ultralytics YOLOを適切に帰属表示します。例：
```
This project utilizes code from [Ultralytics YOLO](https://github.com/ultralytics/ultralytics), licensed under AGPL-3.0.
```

リポジトリ構成の例#

実用的な構成例については、Ultralyticsテンプレートリポジトリを参照してください。

my-yolo-project/
│
├── LICENSE               # Full AGPL-3.0 license text
├── README.md             # Project description, setup, usage, license info & attribution
├── pyproject.toml        # Dependencies (or requirements.txt)
├── scripts/              # Training/inference scripts
│   └── train.py
├── src/                  # Your project's source code
│   ├── __init__.py
│   ├── data_loader.py
│   └── model_wrapper.py  # Code interacting with YOLO
├── tests/                # Unit/integration tests
├── configs/              # YAML/JSON config files
├── docker/               # Dockerfiles, if used
│   └── Dockerfile
└── .github/              # GitHub specific files (e.g., workflows for CI)
    └── workflows/
        └── ci.yml

これらのガイドラインに従うことで、AGPL-3.0への準拠を確保し、Ultralytics YOLOのような強力なツールを可能にするオープンソースエコシステムを支援できます。

まとめ#

Ultralyticsのオープンソース YOLOプロジェクトへの貢献に関心をお寄せいただき、ありがとうございます。皆様の参加は、ソフトウェアの未来を形作り、イノベーションと協力に満ちた活気あるコミュニティを構築するために不可欠です。コードの改善、バグの報告、新機能の提案など、皆様の貢献は非常に貴重です。

皆様のアイデアが実現することを楽しみにしており、物体検出技術の発展に尽力していただいていることに感謝します。このエキサイティングなオープンソースの歩みを、ともに成長させ、革新し続けましょう。

FAQ#

Ultralytics YOLOのオープンソースリポジトリへの貢献は、ソフトウェアを改善し、コミュニティ全体にとってより堅牢で機能豊富なものにします。貢献には、コードの改善、バグ修正、ドキュメントの改善、新機能の実装などが含まれます。さらに、貢献を通じて、他の優れた開発者や分野の専門家と協力でき、自身のスキルや評価を高められます。始め方の詳細については、Pull Requestによる貢献セクションを参照してください。
コントリビューターライセンス契約（CLA）に署名するには、Pull Requestを送信した後にCLA botが提供する手順に従ってください。この手続きにより、貢献内容がAGPL-3.0ライセンスの下で適切にライセンスされ、オープンソースプロジェクトの法的整合性が維持されます。Pull Requestに次の内容のコメントを追加してください。
I have read the CLA Document and I sign the CLA
詳細については、CLAへの署名セクションをご覧ください。
Googleスタイルのdocstringは、関数やクラスについて明確で簡潔なドキュメントを提供し、コードの可読性と保守性を向上させます。これらのdocstringでは、特定の書式ルールに従って、関数の目的、引数、戻り値を説明します。Ultralytics YOLOにコントリビュートする際にGoogleスタイルのdocstringに従うことで、追加したコードを適切にドキュメント化し、容易に理解できるようになります。例とガイドラインについては、Googleスタイルのdocstringセクションをご覧ください。
プルリクエストをマージするには、GitHub Actionsの継続的インテグレーション（CI）テストにすべて合格する必要があります。これらのテストには、リンティング、単体テスト、その他のチェックが含まれており、コードがプロジェクトの品質基準を満たしていることを確認します。CIの出力を確認し、問題があれば修正してください。CIプロセスとトラブルシューティングのヒントについて詳しくは、GitHub ActionsのCIテストセクションをご覧ください。
バグを報告するには、バグレポートと併せて、明確で簡潔な最小再現可能例を提示してください。これにより、開発者が問題を迅速に特定して修正できます。問題を再現するのに十分でありながら、最小限の例になるようにしてください。バグ報告の詳しい手順については、バグの報告セクションをご覧ください。
プロジェクトでAGPL-3.0ライセンスのUltralytics YOLOのコードまたはモデルを使用する場合、AGPL-3.0ライセンスにより、プロジェクト全体（派生物）もAGPL-3.0の下でライセンスされ、完全なソースコードを一般公開することが求められます。これにより、派生物を通じてソフトウェアのオープンソースの性質が維持されます。これらの要件を満たせない場合は、エンタープライズライセンスを取得する必要があります。詳細については、プロジェクトのオープンソース化セクションをご覧ください。

貢献者

GLglenn-jocher²⁵ RIRizwanMunawar³ RAraimbekovm² PDpderrenger² Y-Y-T-G¹ WIWillieMaddox¹ LEleonnil¹ MAMatthewNoyce¹ BUBurhan-Q¹

作成日 2023年11月12日更新日先週