通用指南

以下是所有类型的贡献需要记住的一些事项

• 遵循 “fork 和 pull request” 工作流程。
• 在打开 pull request 时，填写已签入的 pull request 模板。注明相关 issue 并标记相关的维护者。
• 在请求审核之前，确保您的 PR 通过格式化、linting 和测试检查。
  • 如果您希望对您当前的进度进行评论或反馈，请打开一个 issue 或讨论并标记维护者。
  • 请参阅关于 测试 和 格式化和 linting 的章节，了解如何在本地运行这些检查。
• 向后兼容性是关键。您的更改不得具有破坏性，除非是关键错误和安全修复的情况。
• 在打开新的 PR 或 issue 之前，查找是否已经打开了重复的 PR 或 issue。
• 保持范围尽可能隔离。作为一般规则，您的更改不应影响超过一个包。

错误修复

我们鼓励并感谢错误修复。我们要求您

• 足够详细地解释错误，以便维护者能够重现它。
  • 如果存在相关的 issue，请链接到它。以 Fixes 为前缀，以便在 PR 合并时 issue 将自动关闭。
• 如果可能，避免破坏性更改。
• 包括在没有错误修复的情况下会失败的单元测试。

如果您遇到错误但不知道如何修复它，我们要求您为其打开一个 issue，详细描述您遇到该错误的环境。

新功能

我们旨在保持新功能的高门槛。我们通常不接受来自外部贡献者的新核心抽象、基础设施更改、依赖项更改或新的 agent/chain，除非存在 GitHub 讨论或 issue 表明迫切需要它们。

• 新功能必须附带文档、单元测试和（如果适用）集成测试。
• 新的集成必须附带文档、单元测试和（如果适用）集成测试。
  • 有关贡献新集成的更多详细信息，请参阅此页面。
• 新功能不应继承或使用已弃用的方法或类。
• 我们将拒绝可能导致安全漏洞或报告的功能。
• 不要添加任何硬依赖项。集成可以添加可选依赖项。