Contribute to Conductor
-
Star the repo
The fastest way to help, and how most people find the project. Star conductor-oss/conductor.
-
Fork and build
Clone, build, and run the server locally before your first change. Start with Build from source.
-
Find a good first issue
Issues triaged as approachable, with enough context to start. Browse good first issue.
-
Ask before you build
For anything non-trivial, open a discussion first. It saves rework.
Ways to contribute
Code is the obvious one, and not the only one that matters.
| Where it goes | |
|---|---|
| Fix a bug | The repo that owns the code — see Repositories |
| Add a persistence or queue backend | A new module in the server repo, opt-in by configuration |
| Improve an SDK | The language's own repo |
| Fix or extend the docs | docs/ in the server repo |
| Report a bug | Issues, with steps to reproduce |
| Propose a feature | Discussions first, then an issue |
| Answer a question | Discussions or Slack |
| Report a vulnerability | Privately — see Get Help |
Documentation contributions are worth calling out. Docs here are derived from source rather than written from memory, so a doc fix usually means opening the controller or SDK method and correcting the page to match what the code actually does. That makes docs an unusually good first contribution: you learn the codebase while fixing something real.
Before your first pull request
- Build it locally. Build from source, then
./gradlew test. - Discuss anything non-trivial. A feature discussed first is a feature that gets merged. See Contribution Guide.
- Read the conventions. Interface-first design, DAO interfaces in
core, Spotless formatting, tests without mocks — Best Practices. - Target
main. It is the stable branch and the only PR target.