Contributing & Feedback
There are two different things people mean by "contributing" here — pick the one that matches what you're trying to do.
Using the SDK and found a bug, want a feature, or have feedback
This is the path for almost everyone during the beta — you don't need to write any Kendra Orchestrator SDK code for this.
- Bug report — open an issue using the
bug report template.
Include a minimal reproduction that runs offline against
MockLM(no API key, no network) if at all possible — that's the fastest path to a fix. - Feature request or API feedback — open an issue using the
feature request template.
This is exactly the feedback channel the beta exists for: what ships in
1.0is shaped by what beta users report against the0.xpublic API — see Versioning. - A usage question, not a defect — use GitHub Discussions instead of an issue.
- A security vulnerability — never a public issue. See
SECURITY.mdfor the private reporting channel and what to expect.
Kendralabs/korch-sdk is public — no repository access request needed to file an issue, start a
discussion, or open a PR.
Contributing code
The full engineering workflow — branching model, the local gate (lint/types/tests/coverage),
architecture boundaries, PR expectations, and the release process — is documented in
CONTRIBUTING.md at the
repository root. It assumes you're comfortable with the project's dev → staging → main branching
model (.claude/rules/branching-and-promotion.md)
and is written for both human and AI-agent contributors — the repository is configured for
Claude Code out of the box.
Community standards
Participation in this project — issues, discussions, PRs, and any other project space — is
governed by the
Contributor Covenant Code of Conduct.
Report a violation to conduct@kendralabs.com.
Next
- FAQ — conceptual questions that come up often.
- Troubleshooting — concrete error messages and fixes.
- Versioning — what beta feedback actually changes before
1.0.