Skip to content

Contribution Guidelines

Before using Keptn as a contributor to the Keptn lifecycle-toolkit repository, it is expected that you comply with the guidelines while making contributions towards the repository.

These guidelines are appropriate for both software and documentation. For additional guidelines that are relevant only to documentation, see Contribution guidelines for documentation.

Guidelines for contributing

  • Always fork the repository then clone that fork to your local system rather than clone main directly. Keptn, like most open source projects, severely restricts who can push changes directly to the main branch to protect the integrity of the repository.
  • Smaller PR's are easier to review and so generally get processed more quickly; when possible, chunk your work into smallish PR's. However, we recognize that documentation work sometimes requires larger PRs, such as when writing a whole new section or reorganizing existing files.
  • You may want to squash your commits before creating the final PR, to avoid conflicting commits. This is not mandatory; the maintainers will squash your commits during the merge when necessary.
  • Be sure that the description of the pull request itself is meaningful and clear. This helps reviewers understand each commit and provides a good history after the PR is merged.
  • If your PR is not reviewed in a timely fashion, feel free to post a gentle reminder to the #keptn Slack channel.
  • Resolve review comments and suggestions promptly.

If you see a problem and are unable to fix it yourself or have an idea for an enhancement, please create an issue on the GitHub repository.

  • Provide specific and detailed information about the problem and possible solutions to help others understand the issue.
  • When reporting a bug, provide a detailed list of steps to reproduce the bug. If possible, also attach screenshots that illustrate the bug.
  • If you want to do the work on an issue, include that information in your description of the issue or in a comment to the issue.

Proposing new work

  • When proposing new work, start by creating an issue or ticket in the project's issue tracker.
  • Actively participate in the refinement sessions that are part of the weekly community meetings.
  • In these sessions, everyone discusses the proposed work, whether it is a good idea, what exactly should be done and how it aligns with the project goals.
  • After the discussions, maintainers engage in a process known as Scrum Poker. This involves a voting mechanism where maintainers collectively assess the size and complexity of the proposed work, helping to decide whether it should proceed.

Comments