Contribution Guide

The best project to contribute to is one you actually use. If you have built something with LangChain, you already understand its API and its pain points. Start there.

Ask yourself:

• What AI libraries do I import in my side projects?
• What tools have I wished worked differently?
• What bugs have I worked around instead of reporting?

Your frustrations are contribution opportunities. Browse all projects.

Before you invest hours, spend 10 minutes checking:

• Recent activity: commit in the last 30 days, preferably the last 7
• PR responsiveness: how long between open and first review?
• CONTRIBUTING.md quality: clear setup? clear PR workflow?
• Good first issues: are there any, and are they recent?
• Test suite: does it run cleanly on main?
• Community tone: read the last 10 closed PRs to see how maintainers treat contributors

Red flags: last commit 6+ months ago, no CONTRIBUTING.md, maintainer being curt in PR reviews, CI broken on main.

1. Claim the issue. Comment: "I would like to work on this. Could you assign it to me?"
2. Fork the repo on GitHub.
3. Clone your fork and add upstream as a remote.
4. Create a branch: git checkout -b fix-typo-in-readme
5. Make your changes following the project's conventions.
6. Run tests and linter. Fix anything broken.
7. Commit with a clear message: git commit -m "fix: correct typo in installation docs"
8. Push to your fork and open a PR with a clear description.
9. Respond to review feedback politely and push new commits to the same branch.

• API keys and costs. Many projects need an LLM API key to run tests. Check CONTRIBUTING.md for free/mock alternatives. Never commit keys.
• Non-deterministic tests. LLM output varies. Test structure, not exact content. Use LLM-as-judge for quality.
• Evals matter. If your PR changes LLM behavior, run the eval suite before and after. Report both results.
• Model version drift. The same model name can change output across versions. Pin model versions in tests.
• Heavy dependencies. Use virtual environments. Try uv or pixi for faster installs.

A good PR title describes what changed, not how. Types: feat, fix, docs, refactor, test, chore.

A good PR description answers:

1. What did you change?
2. Why did you change it?
3. How can a reviewer test it?

Use Closes #123 to auto-close the related issue when merged. Keep PRs small — one logical change per PR.

• Giant PRs. Keep them small and focused.
• No PR description. Reviewers need context.
• Ignoring CONTRIBUTING.md. Every project has its own rules.
• Not running tests locally. Why make CI catch failures?
• Getting discouraged by review feedback. It is normal and expected. Not personal.
• Working on main. Always use a feature branch.

Your contribution journey should look like:

1. First: typo or small docs fix
2. Second: missing test or small bug
3. Third: small feature or medium bug
4. Fourth+: anything you want

Each successful contribution builds maintainer trust. Over time, you get assigned harder work and more responsibility.