How to contribute

We are always very happy to have contributions, whether for trivial cleanups or big new features.

If you don't know Java or Scala you can still contribute to the project. An important area is the clients. We want to have high quality, well documented clients for each programming language. These, as well as the surrounding ecosystem of integration tools that people use with Kafka®, are critical aspects of the project.

Nor is code the only way to contribute to the project. We strongly value documentation and gladly accept improvements to the documentation.

Reporting An Issue

Reporting potential issues as JIRA tickets is more than welcome as a significant contribution to the project. But please be aware that JIRA tickets should not be used for FAQs: if you have a question or are simply not sure if it is really an issue or not, please contact us first before you create a new JIRA ticket. To create a new JIRA ticket, please follow the instructions in this page.

Contributing A Code Change

To submit a change for inclusion, please do the following:

• If the change is non-trivial please include some unit tests that cover the new functionality.
• If you are introducing a completely new feature or API it is a good idea to start a wiki and get consensus on the basic design first.
• Make sure you have observed the recommendations in the style guide.
• Follow the detailed instructions in Contributing Code Changes.
• Note that if the change is related to user-facing protocols / interface / configs, etc, you need to make the corresponding change on the documentation as well. For wiki page changes feel free to edit the page content directly (you may need to contact us to get the permission first if it is your first time to edit on wiki); website docs live in the code repo under `docs` so that changes to that can be done in the same PR as changes to the code. Website doc change instructions are given below.
• It is our job to follow up on patches in a timely fashion. Nag us if we aren't doing our job (sometimes we drop things).

Contributing A Change To The Website

To submit a change for inclusion please do the following:

• Follow the instructions in Contributing Website Changes.
• It is our job to follow up on patches in a timely fashion. Nag us if we aren't doing our job (sometimes we drop things). If the patch needs improvement, the reviewer will mark the jira back to "In Progress" after reviewing.

Finding A Project To Work On

The easiest way to get started working with the code base is to pick up a really easy JIRA and work on that. This will help you get familiar with the code base, build system, review process, etc. We flag these kind of starter bugs here.

Please request a JIRA account using ASF's Self-serve portal. After that you can assign yourself to the JIRA ticket you have started working on so others will notice.

If your work is considered a "major change" then you would need to initiate a Kafka Improvement Proposal (KIP) along with the JIRA ticket (more details can be found here). Please ask us to grant you the permission on wiki space in order to create a KIP wiki page.

Once you have gotten through the basic process of checking in code, you may want to move on to a more substantial project. We try to curate this kind of project as well, and you can find these here.

Becoming a Committer

We are always interested in adding new contributors. What we look for is a series of contributions, good taste, and an ongoing interest in the project. Kafka PMC looks at the following guidelines for promoting new committers:

• Made significant contributions in areas such as design, code and/or documentation. The following are some examples (list not exclusive):
  • Submitted and completed non-trivial KIPs.
  • Fixed critical bugs (including performance improvements).
  • Made major tech-debt cleanup.
  • Made major documentation (web docs and java docs) improvements.
• Consistently helped the community in at least one of the following areas since more than 6 months back (list not exclusive):
  • Mailing list participation.
  • Code reviews and KIP reviews.
  • Release validations including testing and benchmarking, etc.
  • Evangelism events: technical talks, blog posts, etc.
• Demonstrated good understanding and exercised good technical judgement on at least one component of the codebase (e.g. core, clients, connect, streams, tests) from contribution activities in the above mentioned areas.

Collaborators

The Apache build infrastructure has provided two roles to make project management easier. These roles allow non-committers to perform some administrative actions like triaging pull requests or triggering builds. See the ASF documentation (note: you need to be logged in to the wiki):

• Jenkins PR Whitelisted Users
• Github Collaborators

In an effort to keep the Apache Kafka project running smoothly, and also to help contributors become committers, we have enabled these roles (See the Apache Kafka Infra config). To keep this process lightweight and fair, we keep the list of contributors full by specifying the top N non-committers (sorted by number of commits they have authored in the last 12 months), where N is the maximum size of that list (currently 10). Authorship is determined by git shortlog. The list will be updated as part of the major/minor release process, three to four times a year.