Skip to content
This repository has been archived by the owner on May 7, 2024. It is now read-only.

Latest commit

 

History

History
64 lines (40 loc) · 3.03 KB

CONTRIBUTING.md

File metadata and controls

64 lines (40 loc) · 3.03 KB
Raw

How to contribute

gsctl is Apache 2.0 licensed and accepts contributions via GitHub pull requests. This document outlines some of the conventions on commit message formatting, contact points for developers and other resources to make getting your contribution into gsctl easier.

Email and chat

  • IRC: #giantswarm IRC channel on freenode.org
  • Email: support@giantswarm.io

Getting started

  • Fork the repository on GitHub
  • Read the README.md for build instructions

Reporting Bugs and Creating Issues

Reporting bugs is one of the best ways to contribute. If you find bugs or documentation mistakes in the gsctl project, please let us know by opening an issue. We treat bugs and mistakes very seriously and believe no issue is too small. Before creating a bug report, please check there that one does not already exist.

To make your bug report accurate and easy to understand, please try to create bug reports that are:

  • Specific. Include as much details as possible: which version, what environment, what configuration, etc. You can also attach logs.

  • Reproducible. Include the steps to reproduce the problem. We understand some issues might be hard to reproduce, please includes the steps that might lead to the problem. If applicable, you can also attach affected data dir(s) and a stack trace to the bug report.

  • Isolated. Please try to isolate and reproduce the bug with minimum dependencies.

  • Unique. Do not duplicate existing bug reports.

  • Scoped. One bug per report. Do not follow up with another bug inside one report.

You might also want to read Elika Etemad’s article on filing good bug reports before creating a bug report.

We might ask you for further information to locate a bug.

Contribution flow

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

  • Create a feature branch from where you want to base your work. This is usually master.
  • Make commits of logical units.
  • Make sure your commit messages are in the proper format (see below).
  • Push your changes to a topic branch in your fork of the repository.
  • Submit a pull request to giantswarm/gsctl.
  • Adding unit tests will greatly improve the chance for getting a quick review and your PR accepted.
  • Your PR must receive an approval from Giant Swarm staff.
  • Before merging your PR be sure to squash all commits into one.

Thanks for your contributions!

Code style

The coding style suggested by the Golang community is used. See the style doc for details.

Please follow this style to make the code easy to review, maintain, and develop.

Format of the Commit Message

We follow a rough convention for commit messages that is designed to answer two questions: what changed and why. The subject line should feature the what and the body of the commit should describe the why.