审查流程

概述

本文档概述了 LangChain 维护者审查拉取请求 (PR) 所使用的流程。此流程的主要目标是增强 LangChain 开发者的体验。

评审状态

我们将 PR 分为三种主要状态，这些状态在右侧边栏中标记为项目项状态，可在此处查看详细信息。

• 初步分类:

  • 所有新提交 PR 的初始状态。
  • 需要维护者将其归类到其他状态之一。

• 需要支持:

  • 在推进之前需要社区反馈或额外输入的 PR。
  • 如果收到 5 个赞成票，将自动提升到待办事项列表。
  • 当应用此状态时，会自动生成一条评论，解释流程和赞成票要求。
  • 如果 PR 在此状态下保留 25 天，将通过自动评论标记为“过时”。
  • 如果 30 天后没有采取进一步行动，PR 将自动关闭。

• 评审中:

  • 我们的团队正在积极评审的 PR。
  • 这些会定期进行评审和监控。

注意：一个 PR 在任何时候只能有一种状态。

注意：您可能会注意到另外 3 种状态：已完成 (Done)、已关闭 (Closed) 和内部 (Internal)，这些状态在此生命周期之外。已完成和已关闭的 PR 分别表示已合并或已关闭。内部状态适用于核心维护者提交的 PR，这些 PR 由提交者拥有。

评审指南

1. 涉及 /libs/core 的 PR:

   • 直接影响核心代码并可能影响最终用户的 PR。
   • 初步分类指南：大多数 PR 应直接进入评审中状态或关闭。
   • 这些 PR 享有最高优先级，并以最快的速度进行评审。
   • 缺乏简洁动机描述（无论是在 PR 摘要中还是在链接的问题中）的 PR 很可能会在未经深入评审的情况下被关闭。请不要使用大型语言模型生成冗长的 PR 描述。
   • 没有单元测试的 PR 可能会被关闭。
   • 功能请求应首先作为 GitHub 问题提出并与 LangChain 维护者讨论。未经事先讨论而提交的大型 PR 可能会被关闭。

2. 涉及 /libs/langchain 的 PR:

   • 与核心 PR 密切相关但优先级略低的高影响力 PR。
   • 初步分类指南：大多数 PR 应直接进入评审中状态或关闭。
   • 这些 PR 会像核心 PR 一样，被积极地评审和关闭。
   • 新的功能请求应提前在问题中与核心维护团队讨论。

3. 涉及 /libs/partners/ 的 PR:

   • 涉及集成包的 PR。
   • 初步分类指南：大多数 PR 应直接进入评审中状态或关闭。
   • 根据 PR 的内容，评审可能由我们的团队进行，也可能移交给合作伙伴的开发团队。
   • 我们与大多数合作伙伴开发团队保持沟通，以促进此流程。

4. 社区 PR:

   • 大多数社区 PR 的初始状态将是“需要支持”。
   • 初步分类指南：大多数 PR 应进入需要支持状态。高流量集成上的错误修复应直接进入评审中状态。
   • 初步分类指南：所有新功能和集成应进入需要支持状态，如果没有获得足够的支持（通过赞成票或评论衡量），将被关闭。
   • 处于需要支持状态 20 天的 PR 将被标记为“过时”，如果在 30 天内没有采取任何行动，将被关闭。

5. 文档 PR:

   • 涉及 docs/docs 中文档内容的 PR。
   • 初步分类指南:
     • 修复单个文件中的拼写错误或小错误并通过 CI 的 PR 应直接进入评审中状态。
     • 在问题中已讨论并同意的更改的 PR 应直接进入评审中状态。
     • 添加新页面或更改文档结构的 PR 应进入需要支持状态。
   • 我们致力于标准化文档格式，以简化评审流程。
   • 针对文档运行 CI 作业，以确保符合标准，从而自动化大部分评审工作。

6. PR 必须是英文:

   • 非英文的 PR 将在未经评审的情况下被关闭。
   • 这是为了确保所有维护者都能有效评审 PR。

如何查看 PR 状态

查看截图

要查看所有开放 PR 的状态，请访问 LangChain 项目看板。

评审优先级

我们的目标是通过专注于开发以下软件来提供最佳的开发体验：

• 能工作：按预期工作（无错误）。
• 有用：通过开箱即用的组件和简化应用构建的运行时，改进 LLM 应用开发。
• 易用：使用直观且文档齐全。

我们相信此流程反映了我们的优先级，如果您认为并非如此，欢迎提供反馈。