Skip to main content

审核流程

概述

本文档概述了LangChain维护者审核拉取请求(PR)的流程。该流程的主要目标是提升LangChain开发者的体验。

审核状态

我们使用三种主要状态对PR进行分类,这些状态在右侧边栏中标记为项目项状态,可以在这里查看详细信息。

  • 初步分类:

  • 所有新提交PR的初始状态。

  • 需要维护者将其分类为其他状态之一。

  • 需要支持:

  • 需要社区反馈或额外输入的PR,以便继续推进。

  • 如果收到5个赞,它将自动提升到待办事项列表。

  • 当应用此状态时,会生成自动评论,解释流程和赞的要求。

  • 如果PR在此状态下保持25天,将通过自动评论标记为“过时”。

  • 如果在30天内没有进一步的操作,PR将自动关闭。

  • 审核中:

  • PR正在我们团队积极审核中。

  • 这些会定期进行审核和监控。

注意: 一个PR一次只能有一个状态。

注意: 您可能会注意到3个额外的状态:完成、关闭和内部, 这些状态与此生命周期无关。完成和关闭的PR已被合并或关闭, 分别。Internal是指由核心维护者提交的PR,这些PR由提交者拥有 由提交者拥有。

审核指南

  1. 涉及/libs/core的PR
  • 直接影响核心代码并可能影响最终用户的PR。
  • 优先级指南:大多数PR应直接进入审核中或关闭。
  • 这些PR被给予最高优先级,并且审核速度最快。
  • 没有简明动机描述的PR(无论是在PR摘要中还是在链接的问题中)可能会在没有深入审核的情况下被关闭。请不要使用LLM生成冗长的PR描述。
  • 没有单元测试的PR可能会被关闭。
  • 功能请求应首先作为GitHub问题提出,并与LangChain维护者讨论。未经事先讨论提交的大型PR可能会被关闭。
  1. 涉及 /libs/langchain 的 PR:
  • 高影响力的 PR 与核心 PR 密切相关,但优先级略低。
  • 分类指南: 大多数 PR 应直接进入 审核中 或关闭。
  • 这些 PR 会被积极审核和关闭,类似于核心 PR。
  • 新功能请求应事先在问题中与核心维护团队讨论。
  1. 涉及 /libs/partners/ 的 PR:
  • 涉及集成包的 PR。
  • 分类指南: 大多数 PR 应直接进入 审核中 或关闭。
  • 审核可能由我们的团队进行,或根据 PR 的内容移交给合作伙伴的开发团队。
  • 我们与大多数合作伙伴开发团队保持沟通,以促进这一过程。
  1. 社区 PRs:
  • 大多数社区 PRs 的初始状态为 "需要支持"。
  • 分类指南: 大多数 PR 应该归类为 需要支持。高流量集成的 bug 修复应直接归类为 审核中
  • 分类指南: 所有新功能和集成应归类为 需要支持,如果没有获得足够的支持(通过投票或评论衡量),将被关闭。
  • 需要支持 状态下超过 20 天的 PR 被标记为“过时”,如果在 30 天内没有采取任何行动,将被关闭。
  1. 文档 PRs:
  • 涉及 docs/docs 中文档内容的 PR。
  • 分类指南:
  • 修复单个文件中的拼写错误或小错误并通过 CI 的 PR 应直接归类为 审核中
  • 在问题中讨论并达成一致的更改的 PR 应直接归类为 审核中
  • 添加新页面或更改文档结构的 PR 应该归入 需要支持
  • 我们努力标准化文档格式,以简化审查过程。
  • CI 作业会针对文档运行,以确保遵循标准,自动化大部分审查。
  1. PR 必须使用英语
  • 非英语的 PR 将在没有审查的情况下关闭。
  • 这样可以确保所有维护者都能有效审查 PR。

如何查看 PR 的状态

请参见截图:

PR Status

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

评审优先级

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

  • 可工作:按预期工作(无错误)。
  • 有用:通过即用组件和简化应用构建的运行时改善大型语言模型应用开发。
  • 简单:易于使用且文档齐全。

我们相信这个过程反映了我们的优先事项,如果您觉得不是,我们欢迎反馈。

Github 讨论

我们欢迎您对这个过程的反馈。请随时在 这个 GitHub 讨论中添加评论。


Was this page helpful?


You can also leave detailed feedback on GitHub.

扫我,入群扫我,找书