Special Release Two an Article to Help You Understand the Entire Process of Participating in an Open Source Community

Special Release Two An Article to Help You Understand the Entire Process of Participating in an Open Source Community #

Hello, I’m Hu Xi. Since the launch of the course, I have often been asked the following question: “I want to participate in the Apache Kafka community, what should I do?” Today, I will provide you with the best practice steps to participate in the Apache open source community, especially the Kafka community.

By following these best practices, you can easily participate in the community’s daily development and even become a member of the community’s contributors. Even if you don’t plan to join the community development for now, these best practices can help you quickly find appropriate resources and save you time and effort when facing Kafka challenges. For example, when diagnosing many Kafka issues, the community mailing list and Jira board are often better tools than search engines.

In general, participating in open source communities usually involves completing 5 steps, as shown in the following diagram:

Although I have numbered each step in the diagram, it does not imply a specific sequence. You are free to implement them in any order. Next, I will guide you through each of these five aspects step by step.

  1. Master Kafka source code ———

You need to have a deep understanding of Kafka’s source code. After all, the purpose of participating in the open source community is to contribute our own code. Whether it is fixing bugs or adding new features to Kafka, you need to have a comprehensive knowledge of the relevant source code in order to proceed. The coursework we currently have is designed to help you achieve this. By completing this course diligently, you will have a deep and extensive understanding of the Kafka server-side source code, laying the foundation for your subsequent contributions.

  1. Subscribe to Kafka mailing lists ———

In my opinion, this is the most important step in participating in open source communities, bar none! Subscribing to mailing lists is the fastest and most effective way to stay informed about community updates. The Kafka mailing lists are among the most active in the entire Apache community.

According to the Apache Community Annual Report 2018, Kafka’s two mailing lists, users and dev, rank 4th and 2nd respectively in the top 5 most active mailing lists, illustrating the high popularity of the community.

The Kafka mailing lists mainly include [email protected] and [email protected]. If Kafka users encounter any problems during usage, they can send emails to the first mailing list for inquiries, while the second mailing list is mainly used for various discussions related to Kafka development. In my personal experience, the dev mailing list has higher value, as there are many discussions and exchanges related to Kafka design and improvement suggestions, which are definitely worth checking out.

Subscribing to these mailing lists is quite simple. You need to send an email to the corresponding subscription email address for both mailing lists. For example, if you want to subscribe to the dev mailing list, you can send an email titled “Subscribe to Kafka dev mailing list” to [email protected], and you will receive emails from the dev mailing list every day. Similarly, you need to send an email to [email protected] to subscribe to the users mailing list.

After successful subscription, you can send emails and ask questions to the users and dev mailing lists. However, you must remember the difference between these two mailing lists:

  • users: Discusses issues related to using Kafka.
  • dev: Discusses issues related to Kafka development.

It is worth noting that both mailing lists receive a large number of emails every day. If you find it overwhelming, you can unsubscribe. The unsubscribe process is similar to the subscription process; you just need to send an email to the corresponding unsubscribe email address. The unsubscribe email address for users is users-unsub[email protected], and for dev it is [email protected].

  1. Obtain Jira permission ——— Currently, Kafka uses Jira for project management, responsible for managing Kafka bugs and tracking new feature proposals. If you want to participate in the Kafka community, you must have Jira access. What does it mean to have access? It means you need to apply for a Jira account. Once you have applied for an account, you also need to send an email to [email protected] requesting to have your Jira ID added to the Kafka Contributor list. Only when your Jira ID is added to the Contributor list will you be eligible to claim Jira tickets, which are commonly referred to as bug fixes.

  2. Granting KIP Permissions ———

In a previous special episode, I mentioned KIP (Kafka Improvement Proposals), which are proposals for new Kafka features. In general, you do not need any permissions to browse these proposals. However, if you want to submit your own proposal, you must apply for KIP account permissions in advance. To do this, you need to send an email to [email protected].

Let me provide an example. You can write an email with the subject “Granting permission for Create KIP” and the body “Please grant permission for Create KIP to wiki ID: “. Then, send the email to the dev mailing list. In about 1 to 2 working days, you will receive an email informing you that your ID has been granted the permission.

At this point, you can go back to the KIP page and click the Create KIP button to write your new feature proposal following the page structure. It is worth noting that once you create your proposal page, there are two places you need to modify on the main KIP page.

First, you must update the next KIP number as shown in the figure below:

Second, you must add the address of your proposal page to the KIPs under discussion table and indicate its status as Under Discussion.

In addition to these steps, you also need to send an email to the dev mailing list, declaring that you have created a KIP and want to initiate a new round of discussions. The following image shows an example of a discussion email I sent when I was responsible for a certain KIP:

After completing all of this, the remaining step is to wait for community developers to discuss your KIP. Your job is to answer various questions raised by them and explain why this KIP is an important feature.

  1. Submitting a Pull Request (PR) ——————–

The last and most crucial step in participating in the community is to submit our own Pull Request (PR) to the community. Currently, community PRs can generally be divided into two categories: regular PRs and MINOR PRs.

Let’s start with MINOR PRs. As the name suggests, MINOR PRs are those with minor changes, such as when you are reading Kafka source code comments and find a misspelled word or unclear variable naming. For this kind of issue, you can directly submit a PR to the community. When naming such PRs, there is a customary convention in the community that they should start with “MINOR: “, as shown in the figure below:

Contributing MINOR PRs does not require creating a Jira ticket beforehand, which is a characteristic of this type of PR.

The other type of PR is a regular PR. Before submitting this type of PR, you must ensure that the problem to be fixed has a corresponding ticket in Jira, and preferably, the Jira Assignee is yourself. If the Assignee is not you, it means that someone else in the community is already working on the issue, and you should respect their work. If you know how to fix the problem, you can politely ask in a comment on the corresponding Jira ticket if you can fix the ticket. If the original Assignee agrees to your request, there is no harm in submitting your own PR.

Once you submit a PR, community developers will conduct a code review and provide many suggestions for modifications. You need to handle these comments carefully. When the Committer believes that your code meets the requirements, they will leave a comment with “LGTM” (Look Good To Me) and let you know that the code can be merged into the main branch. At this point, you officially become a contributor to Apache Kafka.

Summary #

Today, I introduced you to best practices for participating in the Kafka community. I hope that after completing this lesson, you can step by step achieve your goal of becoming a Kafka Contributor, or even the next community Committer! Of course, everyone has different actual goals and expectations, so you can also participate in the community in a targeted and limited way to meet your specific needs.

Finally, I would like to share with you a suggestion for Chinese participants in open source communities: Don’t only communicate with Chinese developers, but also engage in cooperation and communication with developers from other countries. I have found that many Chinese developers only seek help from Chinese speakers in the Kafka community. However, developers from other countries in the community are also very friendly and easy to communicate with. I suggest you have more conversations with them as well, and I believe you will have different and valuable experiences.

Post-class Discussion #

What is your original intention for participating in the Kafka community or even the open-source community, or what interesting experiences have you had in participating in the open-source community in the past? What do you think is the biggest significance or value of doing these things?

Please feel free to express your thoughts in the comments section and discuss with me. You are also welcome to share today’s content with your friends.