mirror of
https://github.com/hwchase17/langchain.git
synced 2026-02-21 06:33:41 +00:00
91 lines
4.9 KiB
Plaintext
91 lines
4.9 KiB
Plaintext
# Review Process
|
|
|
|
## Overview
|
|
|
|
This document outlines the process used by the LangChain maintainers for reviewing pull requests (PRs). The primary objective of this process is to enhance the LangChain developer experience.
|
|
|
|
## Review Statuses
|
|
|
|
We categorize PRs using three main statuses, which are marked as project item statuses in the right sidebar and can be viewed in detail [here](https://github.com/orgs/langchain-ai/projects/12/views/1).
|
|
|
|
- **Triage**:
|
|
- Initial status for all newly submitted PRs.
|
|
- Requires a maintainer to categorize it into one of the other statuses.
|
|
|
|
- **Needs Support**:
|
|
- PRs that require community feedback or additional input before moving forward.
|
|
- Automatically promoted to the backlog if it receives 5 upvotes.
|
|
- An auto-comment is generated when this status is applied, explaining the flow and the upvote requirement.
|
|
- If the PR remains in this status for 25 days, it will be marked as “stale” via auto-comment.
|
|
- PRs will be auto-closed after 30 days if no further action is taken.
|
|
|
|
- **In Review**:
|
|
- PRs that are actively under review by our team.
|
|
- These are regularly reviewed and monitored.
|
|
|
|
**Note:** A PR may only have one status at a time.
|
|
|
|
**Note:** You may notice 3 additional statuses of Done, Closed, and Internal that
|
|
are external to this lifecycle. Done and Closed PRs have been merged or closed,
|
|
respectively. Internal is for PRs submitted by core maintainers, and these PRs are owned
|
|
by the submitter.
|
|
|
|
## Review Guidelines
|
|
|
|
1. **PRs that touch `/libs/core`**:
|
|
- PRs that directly impact core code and are likely to affect end users.
|
|
- **Triage Guideline**: most PRs should either go straight to `In Review` or closed.
|
|
- These PRs are given top priority and are reviewed the fastest.
|
|
- PRs that don't have a **concise** descriptions of their motivation (either in PR summary or in a linked issue) are likely to be closed without an in-depth review. Please do not generate verbose PR descriptions with an LLM.
|
|
- PRs that don't have unit tests are likely to be closed.
|
|
- Feature requests should first be opened as a GitHub issue and discussed with the LangChain maintainers. Large PRs submitted without prior discussion are likely to be closed.
|
|
|
|
2. **PRs that touch `/libs/langchain`**:
|
|
- High-impact PRs that are closely related to core PRs but slightly lower in priority.
|
|
- **Triage Guideline**: most PRs should either go straight to `In Review` or closed.
|
|
- These are reviewed and closed aggressively, similar to core PRs.
|
|
- New feature requests should be discussed with the core maintainer team beforehand in an issue.
|
|
|
|
3. **PRs that touch `/libs/partners/`**:
|
|
- PRs involving integration packages.
|
|
- **Triage Guideline**: most PRs should either go straight to `In Review` or closed.
|
|
- The review may be conducted by our team or handed off to the partner's development team, depending on the PR's content.
|
|
- We maintain communication lines with most partner dev teams to facilitate this process.
|
|
|
|
4. **Community PRs**:
|
|
- Most community PRs will get an initial status of "needs support".
|
|
- **Triage Guideline**: most PRs should go to `Needs support`. Bugfixes on high-traffic integrations should go straight to `In review`.
|
|
- **Triage Guideline**: all new features and integrations should go to `Needs support` and will be closed if they do not get enough support (measured by upvotes or comments).
|
|
- PRs in the `Needs Support` status for 20 days are marked as “stale” and will be closed after 30 days if no action is taken.
|
|
|
|
5. **Documentation PRs**:
|
|
- PRs that touch the documentation content in `docs/docs`.
|
|
- **Triage Guideline**:
|
|
- PRs that fix typos or small errors in a single file and pass CI should go straight to `In Review`.
|
|
- PRs that make changes that have been discussed and agreed upon in an issue should go straight to `In Review`.
|
|
- PRs that add new pages or change the structure of the documentation should go to `Needs Support`.
|
|
- We strive to standardize documentation formats to streamline the review process.
|
|
- CI jobs run against documentation to ensure adherence to standards, automating much of the review.
|
|
|
|
6. **PRs must be in English**:
|
|
- PRs that are not in English will be closed without review.
|
|
- This is to ensure that all maintainers can review the PRs effectively.
|
|
|
|
## How to see a PR's status
|
|
|
|
See screenshot:
|
|
|
|
|
|
|
|
*To see the status of all open PRs, please visit the [LangChain Project Board](https://github.com/orgs/langchain-ai/projects/12/views/2).*
|
|
|
|
## Review Prioritization
|
|
|
|
Our goal is to provide the best possible development experience by focusing on making software that:
|
|
|
|
- Works: Works as intended (is bug-free).
|
|
- Is useful: Improves LLM app development with components that work off-the-shelf and runtimes that simplify app building.
|
|
- Is easy: Is intuitive to use and well-documented.
|
|
|
|
We believe this process reflects our priorities and are open to feedback if you feel it does not.
|