Link to this sectionUltralyticsのオープンソースプロジェクトへの貢献について#
ようこそ!Ultralyticsのオープンソースプロジェクトへの貢献をご検討いただき、大変嬉しく思います。皆様の参加は、リポジトリの品質向上だけでなく、コンピュータビジョンコミュニティ全体にも大きなメリットをもたらします。本ガイドでは、貢献を始めるための明確なガイドラインとベストプラクティスを紹介します。
Watch: How to Contribute to Ultralytics Repository | Ultralytics Models, Datasets and Documentation 🚀
Link to this section🤝 行動規範#
すべての人にとって歓迎的で包括的な環境を維持するため、すべてのコントリビューターは当社のCode of Conductを遵守する必要があります。尊重、親切心、そしてプロ意識が、当社のコミュニティの核となります。
Link to this section🚀 プルリクエスト(PR)を通じた貢献#
プルリクエスト (PR)による貢献を心より歓迎します。レビュープロセスを円滑に進めるため、以下の手順に従ってください。
- リポジトリをフォークする: まず、該当するUltralyticsリポジトリ(例: ultralytics/ultralytics)を自分のGitHubアカウントにフォークします。
- ブランチを作成する: フォークしたリポジトリ内に、変更内容が明確にわかる名前(例:
fix-issue-123,add-feature-xyz)で新しいブランチを作成します。 - 変更を加える: 改善点や修正を実装します。コードがプロジェクトのスタイルガイドラインに準拠していること、また新たなエラーや警告を引き起こさないことを確認してください。
- 変更をテストする: 送信する前に、変更が想定通りに機能し、リグレッションを引き起こさないことをローカル環境でテストしてください。新しい機能を追加する場合は、テストも併せて追加してください。
- 変更をコミットする: 簡潔で分かりやすいメッセージで変更をコミットしてください。特定のIssueに対する修正であれば、その番号を含めてください(例:
Fix #123: Corrected calculation error.)。 - プルリクエストを作成する: 作成したブランチから、元のUltralyticsリポジトリの
mainブランチへ向けてプルリクエストを送信します。変更の目的と範囲がわかるよう、明確なタイトルと詳細な説明を記載してください。
Link to this section📝 CLAへの署名#
プルリクエストをマージする前に、Contributor License Agreement (CLA)に署名する必要があります。この法的合意により、あなたのコントリビューションが適切にライセンスされ、プロジェクトが引き続きAGPL-3.0 licenseの下で配布されることが保証されます。
プルリクエスト送信後、CLAボットが署名プロセスを案内します。CLAに署名するには、PRに以下のコメントを追加するだけです。
I have read the CLA Document and I sign the CLA
Link to this section✍️ GoogleスタイルのDocstring#
新しい関数やクラスを追加する際は、明確で標準化されたドキュメントとするためにGoogleスタイルのDocstringを記述してください。入力と出力のtypesは常に括弧内に記述してください(例: (bool), (np.ndarray))。
この例は、標準的な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 == arg2Link to this section✅ GitHub Actions CIテスト#
すべてのプルリクエストは、マージされる前にGitHub ActionsのContinuous Integration (CI) テストに合格しなければなりません。これらのテストには、リント、ユニットテスト、および変更がプロジェクトの品質基準を満たしていることを確認するためのその他のチェックが含まれます。CIの出力を確認し、発生した問題に対処してください。
Link to this section✨ コード貢献のベストプラクティス#
Ultralyticsプロジェクトにコードを貢献する際は、以下のベストプラクティスを考慮してください。
- コードの重複を避ける: 可能な限り既存のコードを再利用し、不要な引数を最小限に抑えてください。
- 小さく的を絞った変更を行う: 大規模な変更よりも、ターゲットを絞った修正に注力してください。
- 可能な場合は単純化する: コードを簡素化したり、不要な部分を削除したりする機会がないか検討してください。
- 互換性を考慮する: 変更を加える前に、それらが既存のUltralyticsコードに悪影響を及ぼさないか検討してください。
- 一貫したフォーマットを使用する: Ruff Formatterのようなツールを使用することで、スタイルの一貫性を維持できます。
- 適切なテストを追加する: 新機能が期待通りに動作することを確認するために、testsを含めてください。
Link to this section👀 プルリクエストのレビュー#
プルリクエストのレビューも、貢献の貴重な手段の一つです。PRをレビューする際は、以下の点を確認してください。
- ユニットテストの確認: PRに新機能や変更に対するテストが含まれているか検証します。
- ドキュメントの更新を確認する: 変更内容を反映するために、documentationが更新されていることを確認してください。
- パフォーマンスへの影響を評価する: 変更がperformanceにどのような影響を与えるかを検討してください。
- CIテストを検証する: すべてのContinuous Integration testsがパスしていることを確認してください。
- 建設的なフィードバックを提供する: 問題点や懸念事項について、具体的かつ明確なフィードバックを行います。
- 努力を称える: 良好な協力関係を維持するため、著者の取り組みを認めます。
Link to this section🐞 バグ報告#
私たちはプロジェクトの品質と信頼性向上のために、バグ報告を非常に重視しています。GitHub Issuesを通じてバグを報告する際は、以下を行ってください。
- 既存のIssueを確認する: そのバグが既に報告されていないか、まず検索してください。
- Minimum Reproducible Exampleを提供する: 問題を一貫して再現できる、小規模で自己完結型のコードスニペットを作成してください。これは効率的なデバッグにおいて極めて重要です。
- 環境を説明する: 使用しているオペレーティングシステム、Pythonのバージョン、関連ライブラリのバージョン(例:
torch,ultralytics)、およびハードウェア(CPU/GPU)を指定してください。 - 期待される動作と実際の動作を説明する: 何を期待していたのか、そして実際に何が起こったのかを明確に述べてください。エラーメッセージやトレースバックも必ず含めてください。
Link to this section📜 ライセンス#
Ultralyticsのリポジトリでは、GNU Affero General Public License v3.0 (AGPL-3.0)を採用しています。このライセンスは、ソフトウェア開発におけるオープン性、透明性、共同改善を促進します。すべてのユーザーがソフトウェアを使用、修正、共有する自由を持つことを保証し、強力な協力とイノベーションのコミュニティを育みます。
Ultralyticsオープンソースコミュニティへ効果的かつ倫理的に貢献いただくため、すべての貢献者の方々にAGPL-3.0ライセンスの条項を把握しておくことを推奨します。
Link to this section🌍 YOLOプロジェクトをAGPL-3.0の下でオープンソース化する#
プロジェクトでUltralytics YOLOのモデルやコードを使用していますか?AGPL-3.0ライセンスでは、派生した成果物全体も同じくAGPL-3.0の下でオープンソース化することが義務付けられています。これにより、オープンソースの基盤の上に構築された修正や大規模なプロジェクトが、オープンな状態に保たれることが保証されます。
Link to this sectionAGPL-3.0のコンプライアンスが重要な理由#
- ソフトウェアをオープンに保つ: 改善点や派生した成果物がコミュニティの利益になることを保証します。
- 法的な要件: AGPL-3.0ライセンスコードの使用は、あなたのプロジェクトをその条項に拘束します。
- コラボレーションを促進する: 共有と透明性を奨励します。
もしプロジェクトをオープンソースにしたくない場合は、エンタープライズライセンスの取得を検討してください。
Link to this sectionAGPL-3.0に準拠する方法#
準拠とは、プロジェクトの対応する完全なソースコードをAGPL-3.0ライセンスの下で公開することを意味します。
-
開始点を選択する:
- Ultralytics YOLOをフォークする: 密接に基盤として構築する場合は、Ultralytics YOLOリポジトリを直接フォークしてください。
- Ultralyticsテンプレートを使用する: YOLOを統合したクリーンでモジュール化されたセットアップには、Ultralyticsテンプレートリポジトリから開始してください。
-
プロジェクトをライセンスする:
- Add a
LICENSEfile containing the full text of the AGPL-3.0 license. - 各ソースファイルの先頭に、ライセンスを示す通知を追加してください。
- Add a
-
ソースコードを公開する:
- プロジェクト全体のソースコードを一般公開してください(例: GitHub上)。これには以下が含まれます。
- YOLOモデルやコードを取り込んだ、完全な大規模アプリケーションやシステム。
- 元のUltralytics YOLOコードに加えられたいかなる変更。
- 学習、検証、推論のためのスクリプト。
- 修正またはファインチューニングされたモデルウェイト。
- Configuration files、環境設定(
requirements.txt、Dockerfiles)。 - Webアプリケーションの一部である場合のバックエンドおよびフロントエンドコード。
- 修正を加えたすべてのthird-party libraries。
- 実行/再学習に必要であり、かつ再配布可能な学習データ。
- プロジェクト全体のソースコードを一般公開してください(例: GitHub上)。これには以下が含まれます。
-
明確にドキュメント化する:
README.mdを更新し、プロジェクトがAGPL-3.0の下でライセンスされていることを明記してください。- ソースコードからプロジェクトをセットアップ、ビルド、実行する方法についての明確な手順を含めてください。
- Ultralytics YOLOを適切に属性表示し、元のリポジトリへのリンクを張ってください。例:
This project utilizes code from [Ultralytics YOLO](https://github.com/ultralytics/ultralytics), licensed under AGPL-3.0.
Link to this sectionリポジトリ構造の例#
実用的な構造例については、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のような強力なツールを可能にするオープンソースのエコシステムを支援することになります。
Link to this section結論#
UltralyticsのオープンソースYOLOプロジェクトへのご関心をお寄せいただき、ありがとうございます。皆様の参加は、私たちのソフトウェアの未来を形作り、イノベーションとコラボレーションの活気あるコミュニティを構築するために不可欠です。コードの強化、バグの報告、新機能の提案など、どのような形であれ、皆様の貢献はかけがえのないものです。
皆様のアイデアが実現することを楽しみにしています。また、物体検出技術の発展に向けた尽力に感謝いたします。このエキサイティングなオープンソースの旅路において、共に成長しイノベーションを起こし続けましょう。
Link to this sectionよくある質問 (FAQ)#
Link to this sectionなぜUltralytics YOLOオープンソースリポジトリに貢献すべきなのですか?#
Ultralytics YOLOオープンソースリポジトリへの貢献は、ソフトウェアを改善し、コミュニティ全体にとってより堅牢で機能豊かなものにします。貢献には、コードの強化、バグ修正、ドキュメントの改善、新機能の実装などが含まれます。さらに、貢献を通じて、他の熟練した開発者や分野の専門家と協力することができ、自身のスキルと評価を高めることができます。開始方法の詳細については、プルリクエストを通じた貢献セクションを参照してください。
Link to this sectionUltralytics YOLOの貢献者ライセンス同意書 (CLA) に署名するにはどうすればよいですか?#
貢献者ライセンス同意書 (CLA) に署名するには、プルリクエスト送信後にCLAボットが提供する手順に従ってください。このプロセスにより、貢献がAGPL-3.0ライセンスの下で適切にライセンスされ、オープンソースプロジェクトの法的な整合性が維持されます。プルリクエストに以下のコメントを追加してください。
I have read the CLA Document and I sign the CLA
詳細については、CLAへの署名セクションを参照してください。
Link to this sectionGoogleスタイルのDocstringとは何ですか。また、なぜUltralytics YOLOへの貢献に必要なのですか?#
GoogleスタイルのDocstringは、関数やクラスに対して明確で簡潔なドキュメントを提供し、コードの可読性と保守性を向上させます。これらのDocstringは、関数の目的、引数、戻り値を特定の書式規則に従って概説します。Ultralytics YOLOに貢献する際、GoogleスタイルのDocstringに従うことで、追加したコードが適切にドキュメント化され、理解しやすくなります。例やガイドラインについては、GoogleスタイルのDocstringセクションをご覧ください。
Link to this sectionGitHub Actions CIテストを確実に通過させるにはどうすればよいですか?#
プルリクエストをマージする前に、すべてのGitHub Actions Continuous Integration (CI) テストを通過させる必要があります。これらのテストには、リンティング、ユニットテスト、およびコードがプロジェクトの品質基準を満たしていることを確認するためのその他のチェックが含まれます。CIの出力結果を確認し、問題を修正してください。CIプロセスとトラブルシューティングのヒントに関する詳細については、GitHub Actions CI Testsセクションを参照してください。
Link to this sectionUltralytics YOLOリポジトリのバグを報告するにはどうすればよいですか?#
バグを報告する場合は、バグ報告とともに明確かつ簡潔なMinimum Reproducible Exampleを提供してください。これは開発者が問題を迅速に特定し修正するのに役立ちます。例は最小限でありながら、問題を再現するのに十分なものであることを確認してください。バグ報告の詳細な手順については、Reporting Bugsセクションを参照してください。
Link to this section自分のプロジェクトでUltralytics YOLOを使用する場合、AGPL-3.0ライセンスにはどのような意味がありますか?#
プロジェクトでUltralytics YOLOのコードまたはモデル(AGPL-3.0ライセンス下)を使用する場合、AGPL-3.0ライセンスでは、プロジェクト全体(派生物)も同様にAGPL-3.0ライセンスの下で提供し、その完全なソースコードを公開することが義務付けられています。これにより、ソフトウェアのオープンソースとしての性質が派生物全体にわたって維持されます。これらの要件を満たせない場合は、Enterprise Licenseを取得する必要があります。詳細については、Open-Sourcing Your Projectセクションを参照してください。
