Skip to content

Latest commit

 

History

History
57 lines (33 loc) · 3.59 KB

CONTRIB.md

File metadata and controls

57 lines (33 loc) · 3.59 KB
Raw

How to contribute

must-gather-clean is an Apache 2.0 licensed project and accepts contributions via GitHub pull requests (PRs).

This document outlines some conventions on commit message formatting, contact points for developers, and other resources to help get contributions into the project.

Getting started

  • Fork the repository on GitHub
  • See the developer guide for build instructions

Reporting bugs and creating issues

Reporting bugs is one of the best ways to contribute. Before filing a bug report, ensure the bug hasn't already been reported by searching through the project Issues.

Any new contribution should be accompanied by a new or existing issue. This issue can help track work, discuss the design and implementation, and help avoid wasted efforts or multiple people working on the same issue, compared to submitting a PR first. Trivial changes, like fixing a typo in the documentation, do not require the creation of a new issue.

Contribution flow

This is a rough outline of what a contributor's workflow looks like:

  • Identify or create an issue.
  • Create a topic branch from where to base the contribution. This is usually the main branch.
  • Make commits of logical units, or squash your change into a single commit.
  • Please run make test and make verify to ensure your change is in good shape.
  • Push changes in a topic branch to a personal fork of the repository.
  • Submit a pull request to the repository.
  • Wait and respond to feedback from the maintainers listed in the OWNERS file.

Thanks for contributing!

Code Review

Contributing PRs with a reasonable title and description can go a long way with helping ease the burden of the review process.

It can be helpful after submitting a PR to self-review your changes. This allows you to communicate sections that reviewers should spend time combing over, asking for feedback on a particular implementation, or providing justification for a set of changes in-line ahead of time.

When opening PRs that are in a rough draft or WIP state create a draft PR. This can help save reviewer's time by communicating the state of a PR ahead of time. Draft PRs can be a good way to get early feedback from reviewers on the implementation, focusing less on smaller details, and more on the general approach of changes.

We appreciate small and self-contained PRs, if possible, split your big changes into several smaller PRs. This will help us to review your changes faster.

Each PR must be labeled with at least one "lgtm" label and at least one "approved" label before it can be merged. Maintainers that have approval permissions are listed in the "approvers" column in the root OWNERS file.

Code style

The coding style suggested by the Golang community is used throughout the project:

In addition to the linked style documentation, must-gather-clean formats Golang packages using the gofmt and golangci-lint tooling. Before submitting a PR, please run make verify and make update-gofmt locally and commit the results. This will help expedite the review process, focusing less on style conflicts, and more on the design and implementation details.

Please follow this style to make the project easier to review, maintain and develop.

Documentation

If the contribution changes the existing APIs or user interface it must include sufficient documentation to explain the use of the new or updated feature.