首先，先簡單了解 OCA的量級，OCA 目前有超過 200 個 Repos，上百位貢獻者，並總計有數以千計的模組。不只如此，每個模組還有不同版本的 branch，且每年會更新一個版本。為了維護專案的品質，僅靠人力來管理是不切實際的，所以多年前 OCA 已建立了貢獻及管理專案的基礎建設。

貢獻流程，要注意的是 (1) Git Commit, 和 (2) CI Testing，再到 (3) GitHub Merge，這分別對應到我開頭提的 Linting, Testing 和 OCA GitHub Bot，我們稍微順一下這個流程，首先我們發現程式的臭蟲，嘗試 Fork 專案並 Clone 到本機端修改程式碼，修改完成後，我們 (1) Git Commit 我們的修改，並且上傳到雲端及送出 Pull Request 給原始專案，此時 PR 得先通過 (2) CI Testing 判別是否通過所有測試，最後，當貢獻者和管理者討論及修修改改後完成後，正是可以將 PR 納入 (3) GitHub Merge 到專案中偉大時刻，碰，大功告成!!!

在貢獻流程中，維護者一天可以收到非常多的 PR 裡面夾帶著非常多的 (1) Git Commit，如果每個都一一建議，是會很耗損開源維護者的熱情地，所以 OCA 使用 pre-commit 工具及 oca-addons-repo-template 來維持最低程度的 commit 品質。

再來是專案維護者，並不可能有時間一一檢查所有的程式，所以透過獨有的 (2) CI Testing，在 GitHub Action 把關程式碼是否通過基礎驗證，再來特別點的是，由於 Odoo 是個包含商業邏輯的全端應用，程式碼可以運行，不代表程式及資料邏輯是正確可運行的，所以有個 Runboat 運用 Kubernetes 動態建構出可以測試運行的執行環境，供維護者來做基本的驗證及確認。

最後在 PR 通過審查後，要做 (3) GitHub Merge 到原始專案當中，此時可以交由 OCA GitHub Bot 來代勞，完成最後一步。最令人振奮的是，這些都是開源的，歡迎大家來學習交流 : )