How to contribute

Apache Kafka is developed under the Apache Software Foundation, and the contribution process is therefore the standard ASF model: discuss on the mailing list, file a JIRA, open a GitHub PR, and have a committer review and merge it. This page is the project-specific cheat sheet — for the canonical version, read the upstream pages it links to.

The high-level loop

1. Find or file a JIRA. Bug reports, KIP work items, and most non-trivial changes live as tickets at https://issues.apache.org/jira/browse/KAFKA.
2. Discuss before you build, when in doubt. Behavior changes, public API changes, protocol changes, and configuration changes require a Kafka Improvement Proposal (KIP) discussed on the dev@ list. See the KIP wiki.
3. Fork the repo on GitHub. Branch from trunk. PR titles must start with the JIRA key, e.g. KAFKA-12345: Reset offsets when ....
4. Run lint, build, and the relevant tests locally (see Development workflow and Testing).
5. Open a PR against apache/kafka:trunk. A committer triages and reviews; trivial PRs may be merged after one approving committer. Larger ones often see multiple reviewers.
6. Address review comments. Force-pushing to your branch is fine; squashing happens at merge time.
7. Wait for a committer to merge. Only ASF Kafka committers can merge.

The full text of these expectations is at https://kafka.apache.org/contributing.html and https://cwiki.apache.org/confluence/display/KAFKA/Contributing+Code+Changes. CONTRIBUTING.md in the repo root is just a pointer to these.

When you need a KIP

Any of the following requires a KIP:

• Adding, removing, or changing a public class or method (anything outside an internals/ package).
• Adding, removing, or changing a configuration option.
• Adding, removing, or changing an RPC, an RPC version, or any field in clients/src/main/resources/common/message/.
• Changing wire formats, on-disk formats, or message schemas.
• Changing default behavior in a way users could observe.

If you are not sure, ask on dev@kafka.apache.org before writing code.

What's in this section

• Development workflow — branching, building, the JIRA → PR cycle.
• Testing — the JUnit tags, integration tests, Trogdor, and ducktape.
• Debugging — log4j, attach-mode, common broker failure modes.
• Patterns and conventions — code style, error handling, threading, public-API rules.
• Tooling — Gradle, Checkstyle, SpotBugs, Spotless, JaCoCo, ducktape, JMH.

Definition of done

Before requesting review, a PR should:

• Build clean: ./gradlew compileJava compileScala compileTestJava compileTestScala.
• Pass static checks: ./gradlew checkstyleMain checkstyleTest spotlessCheck spotbugsMain spotbugsTest.
• Pass the relevant tests: at minimum the touched modules' test task.
• Have a JIRA reference in the title and a description that links to the JIRA / KIP.
• Add or update tests for any behavior change.
• Update Javadoc / Scaladoc for any API change.
• For configuration or RPC changes, update the docs under docs/.

Backporting

Kafka maintains release branches (3.7, 3.8, 4.0, …). Bug fixes are committed first to trunk, then cherry-picked to active release branches by a committer (or by the contributor at a committer's request). Feature work generally goes to trunk only.

Communication channels

• Mailing lists — dev@kafka.apache.org (development), users@kafka.apache.org (user questions). Subscribe via https://kafka.apache.org/contact.
• JIRA — https://issues.apache.org/jira/browse/KAFKA.
• KIP wiki — https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Improvement+Proposals.
• GitHub — pull requests, issues for low-level CI and tooling questions.