审核流程
概述
本文档概述了LangChain维护者审核拉取请求(PR)的流程。该流程的主要目标是提升LangChain开发者的体验。
审核状态
我们使用三种主要状态对PR进行分类,这些状态在右侧边栏中标记为项目项状态,可以在这里查看详细信息。
-
初步分类:
-
所有新提交PR的初始状态。
-
需要维护者将其分类为其他状态之一。
-
需要支持:
-
需要社区反馈或额外输入的PR,以便继续推进。
-
如果收到5个赞,它将自动提升到待办事项列表。
-
当应用此状态时,会生成自动评论,解释流程和赞的要求。
-
如果PR在此状态下保持25天,将通过自动评论标记为“过时”。
-
如果在30天内没有进一步的操作,PR将自动关闭。
-
审核中:
-
PR正在我们团队积极审核中。
-
这些会定期进行审核和监控。
注意: 一个PR一次只能有一个状态。
注意: 您可能会注意到3个额外的状态:完成、关闭和内部, 这些状态与此生命周期无关。完成和关闭的PR已被合并或关闭, 分别。Internal是指由核心维护者提交的PR,这些PR由提交者拥有 由提交者拥有。
审核指南
- 涉及/libs/core的PR:
- 直接影响核心代码并可能影响最终用户的PR。
- 优先级指南:大多数PR应直接进入
审核中
或关闭。 - 这些PR被给予最高优先级,并且审核速度最快。
- 没有简明动机描述的PR(无论是在PR摘要中还是在链接的问题中)可能会在没有深入审核的情况下被关闭。请不要使用LLM生成冗长的PR描述。
- 没有单元测试的PR可能会被关闭。
- 功能请求应首先作为GitHub问题提出,并与LangChain维护者讨论。未经事先讨论提交的大型PR可能会被关闭。
- 涉及 /libs/langchain 的 PR:
- 高影响力的 PR 与核心 PR 密切相关,但优先级略低。
- 分类指南: 大多数 PR 应直接进入
审核中
或关闭。 - 这些 PR 会被积极审核和关闭,类似于核心 PR。
- 新功能请求应事先在问题中与核心维护团队讨论。
- 涉及 /libs/partners/ 的 PR:
- 涉及集成包的 PR。
- 分类指南: 大多数 PR 应直接进入
审核中
或关闭。 - 审核可能由我们的团队进行,或根据 PR 的内容移交给合作伙伴的开 发团队。
- 我们与大多数合作伙伴开发团队保持沟通,以促进这一过程。
- 社区 PRs:
- 大多数社区 PRs 的初始状态为 "需要支持"。
- 分类指南: 大多数 PR 应该归类为
需要支持
。高流量集成的 bug 修复应直接归类为审核中
。 - 分类指南: 所有新功能和集成应归类为
需要支持
,如果没有获得足够的支持(通过投票或评论衡量),将被关闭。 - 在
需要支持
状态下超过 20 天的 PR 被标记为“过时”,如果在 30 天内没有采取任何行动,将被关闭。
- 文档 PRs:
- 涉及 docs/docs 中文档内容的 PR。
- 分类指南:
- 修复单个文件中的拼写错误或小错误并通过 CI 的 PR 应直接归类为
审核中
。 - 在问题中讨论并达成一致的更改的 PR 应直接归类为
审核中
。 - 添加新页面或更改文档结构的 PR 应该归入
需要支持
。 - 我们努力标准化文档格式,以简化审查过程。
- CI 作业会针对文档运行,以确保遵循标准,自动化大部分审查。
- PR 必须使用英语:
- 非英语的 PR 将在没有审查的情况下关闭。
- 这样可以确保所有维护者都能有效审查 PR。
如何查看 PR 的状态
请参见截图:
要查看所有开放 PR 的状态,请访问 LangChain 项目板.
评审优先级
我们的目标是通过专注于制作以下软件来提供最佳的开发体验:
- 可工作:按预期工作(无错误)。
- 有用:通过即用组件和简化应用构建的运行时改善大型语言模型应用开发。
- 简单:易于使用且文档齐全。
我们相信这个过程反映了我们的优先事项,如果您觉得不是,我们欢迎反馈。
Github 讨论
我们欢迎您对这个过程的反馈。请随时在 这个 GitHub 讨论中添加评论。