Contributing

This guide outlines the contribution process, whether you're fixing a bug, implementing a feature, or adding improvements and APIs. After committing your code, explore the Elastic Contributor Program for points and rewards.

Read Getting started to get your environment up and running, then read Best practices. And don't forget that Elastic's Open Source Community Code of Conduct applies to code contributions too.

• Testing
• How we use Git and GitHub
• Interpreting CI Failures
• CI Metrics
• Documentation during development
• Submitting a pull request
• Effective issue reporting in Kibana
• Signing the contributor license agreement
• Localization
• Release Notes Process
• Linting

Sign the Contributor License Agreement. This grants us the right to distribute your code without restriction, ensuring its origin and continued availability to users. You only need to sign the CLA once.

While any development process is welcome, your PR remains entirely your contribution. By opening a PR, you confirm thorough review, testing, and confidence in your proposed changes.

For details on our localization practices, refer to the Localization section.

We currently only accept translations from our engaged translators, and cannot incorporate external suggestions. We appreciate your interest and aim to develop a process for external contributions in the future.

Part of this process only applies to maintainers, since it requires access to GitHub labels.

Kibana publishes Release Notes for major and minor releases. Release Notes summarize merged PRs in user-friendly language. A script generates these notes by collecting merged PRs for each release.

Release Notes text is sourced from your PR title or a single paragraph in the PR description.

To provide a custom paragraph, use a Release note: or ## Release note header in your PR description, followed by the text. (e.g., this PR).

When you create the Release Notes text, use the following best practices:

• Use active voice.
• Use sentence case.
• When you create a PR that adds a feature, start with Adds.
• When you create a PR that improves an existing feature, start with Improves.
• When you create a PR that fixes existing functionality, start with Fixes.
• When you create a PR that deprecates functionality, start with Deprecates.

To make sure that your PR is included in the Release Notes, add the right label.

1. Label the PR with the targeted version (ex: v7.3.0).

2. Label the PR with the appropriate GitHub labels:

   • release_note:feature — New user-facing features, significant enhancements to features, and significant bug fixes (in rare cases).
   • release_note:enhancement — Minor UI changes and enhancements.
   • release_note:fix — Fixes for bugs that existed in the previous release.
   • release_note:deprecation — Deprecates functionality that existed in previous releases.
   • release_note:breaking — Breaking changes that weren’t present in previous releases.
   • release_note:skip — Changes that should not appear in the Release Notes. For example, docs, build, and test fixes, or unreleased issues that are only in main.