贡献

本项目正在积极开发中，代码可能会发生相当大的变化。

目前，我们只计划优先审查外部贡献的错误修复或安全修复。

如果您想添加新功能或更改现有功能的行为，请开启一个问题提议该功能，并在花费时间构建之前获得 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，我们会迅速回复。