Versions Compared

Old Version 9

changes.mady.by.user Ismael Juma Juma

Saved on

compared with

New Version 10

changes.mady.by.user Ismael Juma Juma

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: Minor tweak regarding JIRA assignment (a bit more duplication, but clearer).

...

  1. Find the existing Kafka JIRA ticket that the change pertains to.

    1. Do not create a new JIRA ticket if creating a change to address an existing ticket in JIRA; add to the existing discussion and work instead.

    2. To avoid conflicts, assign the JIRA ticket to yourself if you plan to work on it.

    3. Look for existing pull requests that are linked from the JIRA ticket, to understand if someone is already working on it.

  2. If the change is new, then it usually needs a new JIRA ticket. However, trivial changes, where "what should change" is virtually the same as "how it should change" do not require a JIRA ticket. Example: "Fix typos in Foo scaladoc"

  3. If required, create a new JIRA ticket:

    1. Provide a descriptive Title. "Update web UI" or "Problem in scheduler" is not sufficient. "Kafka support fails to handle empty queue during shutdown" is good.

    2. Write a detailed Description. For bug reports, this should ideally include a short reproduction of the problem. For new features, it may include a design document (or a Kafka Improvement Proposal if it's a major change).

    3. Set required fields: Type, Priority, Fix Versions and optionally Labels.

    4. Do not include a patch file; pull requests are used to propose the actual change.

    5. To avoid conflicts, assign the JIRA ticket to yourself if you plan to work on it. Leave it unassigned otherwise.

    6. Do not include a patch file; pull requests are used to propose the actual change.

  4. If the change is a large change, consider inviting discussion on the issue at dev@kafka.apache.org first before proceeding to implement the change.

...