前回の記事では、OCA活動の始め方を概要レベルでご紹介しました。
今回は、OCA の GitHub リポジトリへ PR（プルリクエスト）を提出する際の具体的な流れを解説します。
OCA Contributors Guidelines & Community Handbook をもとに、
- PR作成の基本ルール
- CIチェック
- レビュー対応
- 初心者がつまずきやすいポイント
を実践的な観点から整理しました。
この記事は、Git・Python・Odooの技術ドキュメントにある程度慣れている開発者が、OCAモジュールの改善提案やバージョンアップ、モジュール追加に初めて取り組む際の参考としてご活用ください。
特に「初めての人が戸惑いやすいポイント」は、実際のレビューで頻出する内容をもとに整理しています。
PRがマージされるまでの詳細ワークフロー
OCAでは、PRがマージされるまでの流れが明確に定義されています。
まず全体像を把握しましょう。
Step1：準備
- CLA（Contributor License Agreement：ライセンス同意）に署名（初回のみ）
- 開発環境にpre-commitをインストール
- 既存のissueやPRを確認（重複防止）
- 新規モジュール追加の場合のリポジトリ選択
どのリポジトリにPRを出すかは、対象リポジトリの README を確認して判断します
Step2：PR作成
■ 基本ルール
- 対象ブランチ：16.0 や 18.0（※main / master ブランチにはPRを出さない点に注意してください。）
- コミットメッセージ：”[TAG] module_name: 内容説明” の形式。
タグの例：[FIX]、[IMP]、[ADD]、[MIG]。規約を参照してください。
[FIX] module_name: 修正内容 [ADD] module_name: 新機能
- PRタイトル：先頭にバージョン タグを含めます
[18.0][FIX] module_name: 修正内容
- 原則として「1PR = 1コミット」が推奨されています。
複数の課題を扱う場合や移行作業を除き、必要に応じてスカッシュし、1コミットにまとめます。
Step3：CI(継続的インテグレーション)チェック
PRを作成すると、自動チェック（CI）が実行されます。
- pre-commit(コードの書き方チェック)：フォーマットとリンティングをチェックします。プッシュする前にローカルで実行してください
- Test：GitHub Actions がモジュールのテストを実行します。
- Runboat：機能テスト用のライブテストインスタンスを提供します。
- Codecov：テストカバレッジ（網羅率）に関するレポート（情報提供用）
👉 CIチェックで失敗した場合は、修正後に再Pushして再実行します。
Step4：レビュー対応
OCA活動で特に重要なのがレビュー対応です。
- レビューコメントへのリアクションや説明を丁寧に行うことが重要
- 修正は迅速に対応
- 複数回のやり取りは普通
👉 丁寧で前向きな対応が、PRの採用につながります。
OCAハウツーガイドはこちら
■ PRのマージ条件
- 承認3件（5日以内）、または2件（5日以降）
- PSCメンバー1名の承認必須
承認後、PSCメンバーが " /ocabot merge " を実行してマージします。
初めての人が戸惑いやすいポイント
■ レビューはすぐ来ない
- OCAはボランティアベースのため、レビューには時間がかかることがあります。
👉 対策： 他人のPRレビューに参加する
■ Stale（放置）扱い
- 120日活動がない場合、自動クローズ
👉 コメントすれば復活します
■ フィードバック、レビュー指摘、修正依頼は一般的なこと
- コードスタイル
- テスト不足
- Odoo設計ルール
👉 コードスタイル（pre-commit、ruff、prettierなど）、テストカバレッジ、Odooのパターンに関する指摘を受けることがあります。このプロセスは批判ではなく、品質向上のための共同作業です。
よくある初心者のミス
ここは非常に重要です。
❌ 翻訳をPRで出す
→ Weblateを使いましょう。
❌ 複数のトピックを網羅するPR
→ 各プルリクエストは、単一の課題または機能に焦点を絞ってください。変更内容が複数のトピック、複数のモジュールに関わる場合は、それぞれを別のプルリクエストに分割します。
❌ AI生成コードをそのまま出す
→ AIで生成したコードは、そのまま提出せず、必ず内容を理解・精査したうえで提出しましょう。
❌ pre-commit未実行
→ 事前にローカルでチェックします。
❌ 履歴のない移行PR
モジュールを新しいバージョンに移行する際は、Gitの履歴を保持し、公式の移行ガイドに従ってください。
❌ PRタイトル、コミットメッセージの形式ミス
→ 規約に従ってください。
リソースとヘルプ
OCAに関するより詳細な情報を知りたい場合は、下記を参照してください。
■ コミュニティ
■ 開発・技術情報
- Odoo公式ドキュメント：モデル、ビュー、テスト、およびOdooフレームワークに関するOdoo公式リファレンス
- メンテナーツールwiki：リポジトリの設定、コーディング規約、移行などに関するOCAのガイドと規約
- CI（Continuous Integration：継続的インテグレーション）：OCA CIワークフローは、すべてのPRに対して自動的にテストを実行します。Runboatは、プルリクエストのGitHubチェックからリンクされたテストインスタンスを提供します。
■ OCA公式情報
- OCA GitHub：github.com/OCAで全てのリポジトリを閲覧できます。
- OCAウェブサイト：odoo-community.org — イベント、ワーキンググループ、ブランディング素材などOCAに関する全般的な情報。
まとめ
OCAへの貢献は、単なるOSS活動ではありません。
Odooを世界中の企業が使いやすくするための、継続的なコミュニティ活動です。
最初は、GitHubの運用、コーディング規約、CI対応、レビュー文化などに戸惑うこともあるかもしれません。
しかし、継続的に参加することで、
- Odoo開発スキルの向上
- コード品質の改善
- チーム開発経験の蓄積
- グローバルコミュニティとの接点
といった大きなメリットがあります。
また、OCA活動を「特別なOSS活動」と切り離して考えるのではなく、日々の開発フローや社内ルールに取り込んでいくことで、実務にも自然に活かせるようになります。
まずは、
- 小さな改善PRから始める
- 継続して参加する
- 他人のレビューにも関わってみる
この3つを意識して取り組むといいかもしれません。
コタエルでは、OCAガイドラインに沿ったOdoo導入支援を行い、コミュニティ活動で得た知見を日々のプロジェクトに活かしています。
OCA活動解説【実践編】｜GitHubプルリクエストの作成・レビュー対応・マージまで