github.com/zntrio/harp/v2@v2.0.9/CONTRIBUTING.md (about)

     1  # How to contribute
     2  
     3  This document outlines some of the conventions on development workflow, commit
     4  message formatting, contact points and other resources to make it easier to get
     5  your contribution accepted.
     6  
     7  ## Getting started
     8  
     9  - Fork the repository on GitHub.
    10  - Read the README.md for build instructions.
    11  - Play with the project, submit bugs, submit patches!
    12  
    13  ## Contribution flow
    14  
    15  This is a rough outline of what a contributor's workflow looks like:
    16  
    17  - Create a topic branch from where you want to base your work. This is usually master.
    18  - Make commits of logical units and add test case if the change fixes a bug or
    19    adds new functionality.
    20  - Run tests and make sure all the tests are passed.
    21  - Make sure your commit messages are in the proper format (see below).
    22  - Push your changes to a topic branch in your fork of the repository.
    23  - Submit a pull request to the repo.
    24  
    25  Thanks for your contributions!
    26  
    27  ## Coding Style
    28  
    29  The coding style suggested by the Golang community is used in this repository. See the
    30  [style doc](https://github.com/golang/go/wiki/CodeReviewComments) for details.
    31  
    32  ## Commit message guidelines
    33  
    34  ### Structure of the commit message
    35  
    36  ```text
    37  <type>(optional scope): <description>
    38  
    39  optional body
    40  
    41  optional footer
    42  ```
    43  
    44  ### **Type**
    45  
    46  - **fix**: The commit represents a bug fix for the bridge components
    47  - **feat**: The commit represents a new feature for the bridge components
    48  - **doc**: The commit represents a change in the documentation
    49  - **chore**: Other changes
    50  
    51  The type **fix** and **feat** will be added to changelog and version will be bumped.
    52  
    53  > Please note that using `BREAKING CHANGE:` will bump the `major` version.
    54  
    55  ### **Optional scope**
    56  
    57  - `fix` and `feat` use the name of command. Example: `fix(vctx): <description>`
    58  - `doc`: try to use name of command. Example: `doc(harp): <description>`
    59  - `chore`: readme, build scripts, dependencies, ..
    60  
    61  ### **Description**
    62  
    63  The description contains succinct description of the change:
    64  
    65  - use the imperative, present tense: "change" not "changed" nor "changes"
    66  - don't capitalize first letter
    67  - no dot (.) at the end
    68  
    69  ### **Optional body**
    70  
    71  Just as in the subject, use the imperative, present tense: "change" not "changed"
    72  nor "changes". The body should include the motivation for the change and contrast
    73  this with previous behavior. This can also reference issues.
    74  
    75  ### **Optional footer**
    76  
    77  All breaking changes have to be mentioned in the footer. You can also reference issues.
    78  
    79  ## Examples
    80  
    81  ```text
    82  feat(harp): add virtual filesystem
    83  
    84  implementd using Afero library
    85  
    86  close #149
    87  ```
    88  
    89  ```text
    90  chore: add contributing guidelines
    91  ```