CONTRIBUTING

Mangos is primarily the work of Garrett D'Amore, but other people
have contributed to improve it, and we welcome additional contributions.
If you're thinking of contributing, here's what you should know.

 1. First check to make sure if an issue for the problem you're addressing,
    or feature you're adding, has already been filed.  If not, file one here:

	https://github.com/go-mangos/mangos/issues

    Please indicate in the description of the issue thta you're working on
    the issue, so we don't duplicate effort.

 2. By submitting code to the project, you are asserting that the work is
    either your own, or that you are authorized to submit it to this project.
    Further, you are asserting that the project may continue to use, modify,
    and redistribute your contribution under the terms in the LICENSE file.

 3. We maintain an "always release ready" stance for the master branch.  That
    is, at any point in time the tree should be in a state that a release
    could be cut, and bisect should never find a point where an issue is
    incompletely fixed or addressed.

 # The remaining items below are consequences of the items above.

 4. All code must pass go vet, and be go fmt compliant.

 5. New features should have tests, and the existing tests must continue
    to pass.  We use the go test framework.

 6. Every issue must be fixed by at most one git commit, which shall normally
    be identified in the first line of the commit message using the syntax

	"fixes #<issue#> <exact issue synopsis>"

    You can have multiple such lines if your commit addresses multiple issues,
    but this is normally discouraged.

 7. No merge commits.  Rebase if you need to.

 8. Additional text may follow the above line(s), separated from them by an
    empty line.  Normally this is not necessary, since the information should
    be in the bug tracking system.  Look at the git log to see examples.

 9. We don't place copyright statements in the individual files, as we have
    a blanket copyright statement.  Instead, feel free to add your name to the
    end of the AUTHORS file.  (Please do this, particularly for non-trivial
    changes!)

10. Submit a github pull request.  Ideally just one bug per PR if possible,
    and based upon the latest commit in the github master branch.

11. We may rebase your changes, including squashing multiple commits,
    or ask you to do so, if you have not followed the procedure above, or
    if other changes have been made to the tree since you committed.

Thank you for your contributions!