Skip to main content

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.

  • 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 of 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:

PR Status

To see the status of all open PRs, please visit the LangChain Project Board.

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.

Github Discussion​

We welcome your feedback on this process. Please feel free to add a comment in this GitHub Discussion.

Was this page helpful?