Skip to main content

​
Opening a PR

  1. Fork the repository
  2. Create a branch: git checkout -b feat/your-feature
  3. Make your changes
  4. Run tests: npm test or pytest
  5. Push: git push origin feat/your-feature
  6. Open a PR against the main branch

​
PR description template

## What this does

[One paragraph explaining the change]

## Why

[Link to the issue this fixes, or explain the problem being solved]

## How to test

[Steps to verify the change works]

## Checklist

- [ ] Tests pass
- [ ] Docs updated
- [ ] CHANGELOG entry added
- [ ] No secrets in the diff

​
Review process

  • A maintainer will be assigned within 2 business days
  • Address review comments with new commits; do not force-push until the review is approved, as it makes the diff hard to follow
  • Once approved, a maintainer will merge

​
Draft PRs

Open as a draft if you want early feedback before the PR is ready for full review. Mark it ready when tests pass and the checklist is complete.

​
Commit squashing

Maintainers will squash-merge PRs by default. Keep your commit messages clean; the PR title becomes the squash commit message and should follow Conventional Commits format. 
feat: add canary deployment strategy
fix: resolve missing OTEL span on session end
docs: add SDK reference page

​
Staying in sync

Keep your branch up to date with main to avoid large merge conflicts: 
git fetch origin
git rebase origin/main
Prefer rebase over merge to keep a clean history.