Dosu Logo
Ask
Documents
CONTRIBUTING
CONTRIBUTING
Type
External
Status
Published
Created
Feb 19, 2026
Updated
Jun 11, 2026
Updated by
Dosu Bot
Source
View

How to Contribute#

We'd love to accept your patches and contributions to this project. To learn more about the project structure and
organization, please refer to Project Governance information. There are just a
few small guidelines you need to follow.

Developer Certificate of Origin (DCO)#

Contributors of this project should state that they agree with the terms published at https://developercertificate.org/
for their contribution. To do this when creating a commit with the Git CLI, a sign-off can be added with
the -s option. The sign-off is stored as part of the commit message
itself.

All files should have the copyright notice.

// Copyright 2026 The kpt Authors
//
// Licensed under the Apache License, Version 2.0 (the "License");
// you may not use this file except in compliance with the License.
// You may obtain a copy of the License at
//
// http://www.apache.org/licenses/LICENSE-2.0
//
// Unless required by applicable law or agreed to in writing, software
// distributed under the License is distributed on an "AS IS" BASIS,
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
// See the License for the specific language governing permissions and
// limitations under the License.

If the file has never been modified: use the creation year only

  • Example: Copyright 2026 The kpt Authors

If the file has been modified: use a year range from creation to last modification

  • Example: Copyright 2024-2026 The kpt Authors

Code reviews#

All submissions, including submissions by project members, require review. We
use GitHub pull requests for this purpose. Consult GitHub Help for more
information on using pull requests.

Process for code reviews. Before requesting human review, a PR must:

  • All tests passing
  • All linting passing
  • Meeting project code quality requirements, including passing all configured static analysis / SonarCloud quality gates and not reducing automated test coverage for the affected components
  • The comments from the first run of automatically generated comments (AI generated comments, SonarCloud comments, bot generated comments, etc.) of the PR are addressed (addressing further re-runs of AI are optional)
  • If it is not possible to resolve an automatic comment, please add a sub-comment indicating why the automated comment cannot be resolved or ask for help in resolving the comment
  • The PR description states whether AI was used to help create the PR; if so, it lists the AI tools used and the areas where they were used

Declare any use of AI#

In addition to the above, the use of AI in the creation of PRs is allowed, but you must declare any use of AI and you must be able to explain the PR code independently of any AI tools.

Update the PR description to state whether you used AI to help you create this PR; if so, list the AI tools you have used and in what areas.

For example:

I have used AI in the creation of this PR.

I have used the following AI tools:
- GitHub Copilot to analyse the code
- Claude Code to generate the function someNewFunctionIAdded()
- Amazon Q to generate unit tests

Attribute AI in the Git commit messages#

Following the guidance of the Linux kernel
we recommend the attribution of AI tools in the commit messages using the following format:

Assisted-by: AGENT_NAME:MODEL_VERSION [TOOL1] [TOOL2]

Where:

  • AGENT_NAME is the name of the AI tool or framework
  • MODEL_VERSION is the specific model version used
  • [TOOL1] [TOOL2] are optional specialized analysis tools used (e.g., coccinelle, sparse, smatch, clang-tidy)

Basic development tools (git, gcc, make, editors) should not be listed.

Example:

Assisted-by: Claude:claude-3-opus coccinelle sparse

Community Guidelines#

This project follows a Code of Conduct.

Community Discussion Groups#

Join following groups/channels to discuss ideas with other kpt contributors.

  1. Join our Slack channel
  2. Join our Discussions

Style Guides#

Contributions are required to follow these style guides:

Contributing to kpt#

The kpt toolchain has several components such as kpt CLI, package orchestrator,
function catalog, function SDKs, Backstage UI plugin and config sync. Each
component has their own development process.
Refer to the pointers below to learn more:

Building the Source#

  1. Clone the project

    git clone https://github.com/kptdev/kpt
cd kpt

  2. Build kpt to $(go env GOPATH)/bin/kpt

    make

  3. Run test

    make all

API Go module#

The api/ directory is a separate Go module (github.com/kptdev/kpt/api). To build and test only that module:

make api

The same checks run with make -C api all.

Version tags and releases (maintainers)#

For step-by-step maintainer instructions (CLI/library vs API, tag shapes, and CI), see release/README.md.

  • kpt CLI (root module github.com/kptdev/kpt): release tags look like v1.2.3. Pushing them runs the kpt Release workflow (GoReleaser, images, provenance).
  • kpt API: publish nested-module git tags such as api/v1.2.3; consumers pin with go get github.com/kptdev/kpt/api@v1.2.3 (see Go modules: VCS version).

Function Catalog#

Function catalog has its own repository. Refer to the
documentation in the krm-functions-catalog
repo.

Documentation#

If you are updating the documentation, please do it in separate PRs from code
changes and PR description should start with Docs:.

Run the docs locally#

Make docs changes and test them by running the site in a docker container with
make serve.

It's usually a good idea to test locally for the following:

  • Broken links
  • Rendering static content

Update docs#

Docs are under documentation/. Refer to the README.md in the folder for details about
documentation contributions.

CONTRIBUTING | Dosu