Contributing

The source code for both KUDO (opens new window) and KUDO Operators (opens new window) lives on GitHub. We welcome feature requests and bug reports in the form of issues (opens new window), and of course code - which includes documentation! - in the form of pull requests (opens new window) (PRs).

There's a ton of stuff to do and there's opportunities to contribute in a variety of ways. We'd suggest that newcomers look at issues tagged with 'good first issue' (opens new window) and 'help wanted' (opens new window) and then then jump into #kudo on the Kubernetes Slack (opens new window) to discuss.

Please also take some time to read our Contributing Guidelines (opens new window).

Raising an Issue

If you've hit a bug, have an idea for a new feature, or want to suggest some other kind of change then we welcome an issue detailing your problem or your suggestion. Ideally we'd ask that people reach out in the Slack channel and join one of our weekly meetings so that other developers and users can help iterate.

Creating a Pull Request

Yes please! Bring us your code! There's a whole lot of work to do, and we're committed to building an active community around KUDO in order to ensure its longevity.

PRs raised against either repo have a default template which help guide contributors to focus on the details necessary for a speedy review. Again, please follow-up with discussion in the Slack channel. We're also happy for people to submit draft PRs which can then be worked through with other members of the KUDO community.

Reviewing a Pull Request

This process is adapted from the one defined for contributing to Kubernetes (opens new window) itself, so should be familiar. We use Prow (opens new window) to help automate this process.

• Examine the PR description and read any associated issues or links for context;
• Look over all changed files, and if you have a comment or a question on any highlighted section then start a review;
• Continue to add comments using this review process and when you've finished, choose either 'comment' for general commentary or 'request changes' for anything you deem important enough to warrant further work;
• If you spot a relatively trivial error such as a typo or something that's not directly related to the stated purpose of the PR then you can let the submitter know by prefixing your review comment with nit:. These are not necessarily blockers to the PR itself but it gives the author an opportunity to make amendments;
• If you think the PR is ready to be merged, then you can add the command /approve to your summary comment. Note that only those listed in the approvers section of the OWNERS (opens new window) file can use this command;
• PRs can be assigned to an individual with the /assign command. If you think a proposed change needs a specific person's input, use this command along with their GitHub username to get their attention;
• If a PR has the lgtm and / or the approve label then it will be merged automatically;
  • You can apply the do-not-merge/hold label in order to stop PRs from being merged automatically.

Typically, a PR needs a review and an approval from two core developers (opens new window) in order to be merged.