nanomsg.org/go/mangos/v2@v2.0.9-0.20200203084354-8a092611e461/CONTRIBUTING (about)

     1  Mangos is primarily the work of Garrett D'Amore, but other people
     2  have contributed to improve it, and we welcome additional contributions.
     3  If you're thinking of contributing, here's what you should know.
     4  
     5   1. First check to make sure if an issue for the problem you're addressing,
     6      or feature you're adding, has already been filed.  If not, file one here:
     7  
     8  	https://github.com/nanomsg/mangos/issues
     9  
    10      Please indicate in the description of the issue that you're working on
    11      the issue, so we don't duplicate effort.
    12  
    13   2. By submitting code to the project, you are asserting that the work is
    14      either your own, or that you are authorized to submit it to this project.
    15      Further, you are asserting that the project may continue to use, modify,
    16      and redistribute your contribution under the terms in the LICENSE file.
    17  
    18   3. We maintain an "always release ready" stance for the master branch.  That
    19      is, at any point in time the tree should be in a state that a release
    20      could be cut, and bisect should never find a point where an issue is
    21      incompletely fixed or addressed.
    22  
    23   # The remaining items below are consequences of the items above.
    24  
    25   4. All code must pass `go vet`, and be `go fmt` compliant.
    26  
    27   5. New features should have tests, and the existing tests must continue
    28      to pass.  We use the go test framework.
    29  
    30   6. Every issue must be fixed by at most one git commit, which shall normally
    31      be identified in the first line of the commit message using the syntax
    32  
    33  	"fixes #<issue#> <exact issue synopsis>"
    34  
    35      You can have multiple such lines if your commit addresses multiple issues,
    36      but this is normally discouraged.
    37  
    38   7. No merge commits.  Rebase if you need to.
    39  
    40   8. Additional text may follow the above line(s), separated from them by an
    41      empty line.  Normally this is not necessary, since the information should
    42      be in the bug tracking system.  Look at the git log to see examples.
    43  
    44   9. We don't place copyright statements in the individual files, as we have
    45      a blanket copyright statement.  Instead, feel free to add your name to the
    46      end of the AUTHORS file.  (Please do this, particularly for non-trivial
    47      changes!)
    48  
    49  10. Submit a GitHub pull request.  Ideally just one bug per PR if possible,
    50      and based upon the latest commit in the GitHub master branch.
    51  
    52  11. We may rebase your changes, including squashing multiple commits,
    53      or ask you to do so, if you have not followed the procedure above, or
    54      if other changes have been made to the tree since you committed.
    55  
    56  Thank you for your contributions!