Making it easier to contribute to LangChain

[Mason Daugherty (mdrxy)]

We shipped a few changes to how external contributions work. The goal is to save contributors time by aligning on scope before code gets written, and to help maintainers prioritize reviews more effectively.

Talk to us before you code

External PRs now need to reference an approved issue (Fixes #123, Closes #123, or Resolves #123 in the PR description), and you need to be assigned to that issue. PRs that don't meet these requirements will be automatically closed — but don't worry, the bot will tell you exactly what's missing, and your PR will reopen automatically once everything checks out.

The quick version:

1. Find an existing issue or open a new one
2. Comment with a brief plan for how you'd approach the fix or feature (a few sentences is plenty)
3. Once a maintainer approves and assigns you, open your PR with Fixes #<number> in the description before any other content

We especially encourage issue authors to contribute fixes — you're closest to the problem and most likely to understand the context. This process keeps everyone on the same page and avoids the frustration of putting work into a PR that we can't merge.

For the full rundown on contributing, check out our Contributing Guide.

We now recognize repeat contributors

If you've had 5 or more PRs merged, you'll automatically get a trusted-contributor label on your PRs and issues. This helps maintainers spot familiar faces during triage. If you've been contributing for a while — thank you, and your PRs will reflect that now.

FAQ

I'm assigned to an issue but the check still failed?
Make sure your PR description includes one of the auto-close keywords (Fixes, Closes, or Resolves) followed by the issue number. The check re-runs when you edit the description.

---

This is a new process and we're iterating on it. If something feels off or you have suggestions, let us know in this thread.

[Baixin Guo (GBX-Max1220)]

No comments ？

[Mason Daugherty (mdrxy)]

hi Baixin Guo (@GBX-Max1220) can you elaborate?

[ANIRUDDHA ADAK (aniruddhaadak80)]

From my point of view, this is a sensible change because it prevents contributors from doing a lot of work on PRs that were never aligned with maintainer priorities.

The only friction I would watch is the gap between opening an issue and knowing whether it is actually ready for outside work. A lightweight label or maintainer note like ready for external contribution would probably reduce the back and forth a lot for new contributors.

The trusted contributor signal also seems useful. It gives repeat contributors a clearer path without weakening the review process for brand new proposals.

[Mason Daugherty (mdrxy)]

Hi ANIRUDDHA ADAK (@aniruddhaadak80) thank you for the feedback!

knowing whether it is actually ready for outside work

We will tag issues with the help wanted label for things we'd invite people to request be assigned on -- see the contributing guide for more.

[Son Seong Jun (SonAIengine)]

Makes sense for feature work, but curious how this plays out for docs fixes or small tweaks — doesn't want the overhead to kill those contributions. Probably already thought through it, but worth calling out since those PRs add up.

[Assad Yousuf (assadyousuf)]

Mason Daugherty (@mdrxy) You should really consider a way of banning potential contributors that just endlessly open up PRs and issues. It's clear people are setting their agents to essentially DDOS maintaners with slop. Super fustrating the good trusting nature of open source is dying.

[Mason Daugherty (mdrxy)]

We are able to ban users from contributing/commenting/opening PRs/etc. and have done so. That process is currently manual.

[Francisco Boni (insilications)]

hey Mason Daugherty (@mdrxy), weeks ago I opened an issue (#36297) along with a potential PR proposal. Since then, my issue has been flooded with spam from AI agents. Bizarre situation.

[Mason Daugherty (mdrxy)]

Francisco Boni (@insilications) indeed weird times we are in. Thanks for the issue, hope to review soon.

[Rehan Malik (rehan243)]

Oh, interesting shift. I like the idea of aligning on scope earlier — we've had a couple of cases where contributors went deep on a PR only to realize it didn't fit with the overall direction. But question for y'all: how are you handling situations where multiple people want to tackle the same issue? Are you assigning based on first-come, first-serve, or considering other factors like past contributions?

On the automation side, the bot auto-closing PRs without a linked issue is smart, but it makes me wonder how you're handling edge cases. For example, contributions where the issue itself is vague or broad. Are you expecting contributors to refine the scope in their comments before approval? We've used something like this in our internal repos and had to tweak things like requiring a short implementation plan comment before assigning anyone. Something like:

### Approach
1. Add a new parameter to `llm_chain()` for specifying X.
2. Update relevant docs with examples for Y.
3. Write tests for edge case Z and W.

This helped us get better signal on whether the contributor "gets" the problem or if the maintainer needs to jump in sooner.

Also, curious about the trusted contributor piece — are you finding that it significantly reduces review cycles? We've toyed with the idea of an "auto-approve" label for repeat contributors but never fully committed because scaling it felt tricky. Would love to know how you're balancing trust with quality here.

[Rehan Malik (rehan243)]

So we actually dealt with this kind of process bottleneck in one of our repos last year — same problem: lots of drive-by PRs without enough context, and it slowed down maintainers big time. What worked for us was adding a similar "issue-first" policy, but we automated some of the back-and-forth a bit more. We used a combo of GitHub Actions and a Slack integration to notify maintainers when someone commented on a tagged issue, and it cut our response time by ~40%.

One thing we also did was provide a basic template for "brief plans" in our contributing guide. Something like this:

### Plan
- Add/modify `function_name` in `file_name.py` to handle X
- Update `test_file.py` to add cases for A, B, and C
- Update docs at [link] if needed

It made it way easier to align on scope because contributors knew what kind of detail we wanted up front. People started self-filtering ideas that were too vague or massive.

Curious: are you doing anything to actively nudge users toward smaller, more focused issues? We found that sometimes contributors would open these huge "mega issues" trying to cover everything, which made it harder to assign and track progress.

[Anusha Sundaramurthi (anusha-sundaramurthi)]

Thanks for the update! The issue-first workflow makes sense. Looking forward to contributing.

[Ayush Das (AyushDas4890)]

Went through the new flow for the first time this week (#32197 → #38059), and one thing I couldn't work out: is opening the PR before assignment intended usage, or discouraged?

The auto-close message says the PR "will be reopened automatically" once assigned — which reads as "open it now, it'll wake up later". But on issues like #32197 that's produced ~7 parallel approach comments, each with their own pre-opened (now auto-closed) PR, all waiting on the same assignment decision. Everyone has already invested the implementation effort the issue-first policy was meant to defer.

If pre-opening is fine, a small queue signal on the issue (even the bot acking "N plans awaiting maintainer review") would help people decide whether to pile on or pick a different issue. If it's discouraged, it might be worth the bot saying so explicitly. Happy to be told I'm holding it wrong :)

[Mason Daugherty (mdrxy)]

Thanks for calling this out — you're not holding it wrong. The current auto-close wording is ambiguous.

The intended flow is: comment on the issue with the approach you'd like to take, wait for a maintainer to approve/assign it, and only then open the PR. Opening a PR before assignment is discouraged, because it can lead to exactly what happened here: multiple contributors doing implementation work before maintainers have selected an approach.

The "will be reopened automatically" language was meant as a recovery path for accidentally-early PRs, not as the recommended path. We should update the bot message to make that explicit.

I also agree that a small queue signal on the issue could help contributors decide whether to pile onto an issue or pick another one, but the first fix should be clarifying the auto-close copy.