貢獻

本項目正在積極開發中，代碼可能會發生相當大的變化。

目前，我們只計劃優先審查外部貢獻的錯誤修復或安全修復。

如果您想添加新功能或更改現有功能的行為，請開啟一個問題提議該功能，並在花費時間構建之前獲得 OpenAI 團隊成員的批准。

未經過此過程的新貢獻可能會被關閉，如果它們與我們當前的路線圖不一致或與其他優先事項/即將推出的功能衝突。

開發工作流程

• 從 main 創建一個_主題分支_ - 例如 feat/interactive-prompt。
• 保持您的更改集中。多個不相關的修復應作為單獨的 PR 開啟。
• 確保您的更改沒有 lint 警告和測試失敗。

編寫高影響力的代碼更改

1. 從問題開始。 開啟一個新問題或在現有討論上評論，以便我們在編寫代碼之前能夠達成一致的解決方案。
2. 添加或更新測試。 每個新功能或錯誤修復都應該附帶在您的更改前失敗且之後通過的測試覆蓋。100% 覆蓋不是必需的，但要力求有意義的斷言。
3. 記錄行為。 如果您的更改影響用戶面向的行為，請更新 README、內聯幫助（codex --help）或相關的示例項目。
4. 保持提交原子性。 每個提交都應該編譯，測試應該通過。這使審查和潛在的回滾更容易。

開啟拉取請求

• 填充 PR 模板（或包含類似信息）- 什麼？為什麼？怎樣？
• 在問題跟踪器中包含指向錯誤報告或增強請求的鏈接
• 在本地運行所有檢查。使用根 just 助手，以便您與工作區的其餘部分保持一致：just fmt、針對您接觸的 crate 的 just fix -p <crate>，以及相關的測試（例如，cargo test -p codex-tui 或 just test 如果您需要完整的掃描）。可以在本地捕獲的 CI 失敗會減慢進程。
• 確保您的分支是最新的 main 並且您已解決合併衝突。
• 僅當您認為 PR 處於可合併狀態時，才將 PR 標記為準備審查。

審查過程

1. 一名維護者將被分配為主要審查者。
2. 如果您的 PR 添加了之前未討論和批准的新功能，我們可能會選擇關閉您的 PR（參見貢獻）。
3. 我們可能會要求更改 - 請不要對此感到沮喪。我們重視這項工作，但我們也重視一致性和長期可維護性。
4. 當有共識認為 PR 符合標準時，維護者將進行 squash-and-merge。

社區價值觀

• 友善和包容。 尊重他人；我們遵循貢獻者公約。
• 假設良好意圖。 書面溝通很困難 - 傾向於慷慨。
• 教導和學習。 如果您發現了令人困惑的東西，請開啟一個 issue 或 PR 以改進。

獲取幫助

如果您在設置項目時遇到問題、想要反饋一個想法，或只是想說_嗨_ - 請開啟一個討論或加入相關的問題。我們很樂意幫助。

總之，我們可以使 Codex CLI 成為一個令人難以置信的工具。快樂黑客！ 🚀

貢獻者許可協議（CLA）

所有貢獻者必須接受 CLA。該過程很簡單：

1. 開啟您的拉取請求。

2. 粘貼以下評論（或如果您之前簽署過，回復 recheck）：

   I have read the CLA Document and I hereby sign the CLA

3. CLA-Assistant 機器人在存儲庫中記錄您的簽名並將狀態檢查標記為已通過。

無需特殊的 Git 命令、電子郵件附件或提交頁腳。

快速修復

情景	命令
修改最後一個提交	git commit --amend -s --no-edit && git push -f

DCO 檢查阻止合併，直到 PR 中的每個提交都附帶頁腳（使用 squash 這只是其中一個）。

安全和負責任的 AI

您發現了漏洞或對模型輸出有疑慮嗎？請發送電子郵件至security@openai.com，我們會迅速回複。