---
title: Contributing
description: This guide outlines the contribution process, whether you're fixing a bug, implementing a feature, or adding improvements and APIs. After committing your...
url: https://www.elastic.co/elastic/docs-builder/docs/3028/extend/kibana/contributing
products:
  - Kibana
---

# 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](https://www.elastic.co/community/contributor) for points and rewards.
Read [*Getting started*](https://www.elastic.co/elastic/docs-builder/docs/3028/extend/kibana/development-getting-started) to get your environment up and running, then read [*Best practices*](https://www.elastic.co/elastic/docs-builder/docs/3028/extend/kibana/development-best-practices). And don't forget that [Elastic's Open Source Community Code of Conduct](https://www.elastic.co/community/codeofconduct) applies to code contributions too.
- [Testing](https://www.elastic.co/elastic/docs-builder/docs/3028/extend/kibana/development-tests)
- [How we use Git and GitHub](https://www.elastic.co/elastic/docs-builder/docs/3028/extend/kibana/development-github)
- [Interpreting CI Failures](https://www.elastic.co/elastic/docs-builder/docs/3028/extend/kibana/interpreting-ci-failures)
- [CI Metrics](https://www.elastic.co/elastic/docs-builder/docs/3028/extend/kibana/ci-metrics)
- [Documentation during development](https://docs-v3-preview.elastic.dev/elastic/docs-builder/docs/3028/extend/contribute-docs)
- [Submitting a pull request](https://www.elastic.co/elastic/docs-builder/docs/3028/extend/kibana/development-pull-request)
- [Effective issue reporting in Kibana](https://www.elastic.co/elastic/docs-builder/docs/3028/extend/kibana/kibana-issue-reporting)
- [Signing the contributor license agreement](#signing-contributor-agreement)
- [Localization](#kibana-localization)
- [Release Notes Process](#kibana-release-notes-process)
- [Linting](https://www.elastic.co/elastic/docs-builder/docs/3028/extend/kibana/kibana-linting)


## Signing the contributor license agreement

Sign the [Contributor License Agreement](http://www.elastic.co/contributor-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.

### Note on contributing code written with the assistance of AI

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.

## Localization

For details on our localization practices, refer to the [Localization section](/elastic/docs-builder/docs/3028/extend/kibana/development-best-practices#kibana-localization-best-practices).
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.

## Release Notes Process

Part of this process only applies to maintainers, since it requires access to GitHub labels.
Kibana publishes [Release Notes](https://www.elastic.co/elastic/docs-builder/docs/3028/release-notes/kibana) 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.

### Create the Release Notes text

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](https://github.com/elastic/kibana/pull/65796)).
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`.


### Add your labels

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`.