Merge pull request #20 from obsidiansystems/contribution-guide

Version v0.1.0

CONTRIBUTING.md

@@ -0,0 +1,67 @@
+# Contribution Guide
+
+Contributions and issue reports are encouraged and appreciated!
+
+- [Opening Issues](#opening-issues)
+- [Submitting Changes](#submitting-changes)
+  - [Guidelines for Commit Messages](#guidelines-for-commit-messages)
+  - [Guidelines for Pull Requests](#guidelines-for-pull-requests)
+  - [Code Quality](#code-quality)
+  - [Documentation](#documentation)
+
+## Opening Issues
+
+Before opening an issue, please check whether your issue has already been reported. Assuming it has not:
+
+* Describe the issue you're encountering or the suggestion you're making
+* Include any relevant steps to reproduce or code samples you can. It's always easier for us to debug if we have something that demonstrates the error.
+* Let us know what version of Hydra Pay you were using. If you're using a github checkout, provide the git hash.
+* Describe how you're using Hydra Pay (i.e. development with obelisk, nix executable, docker container, etc.).
+
+## Submitting Changes
+
+### Guidelines for Commit Messages
+
+#### Summary Line
+The summary line of your commit message should summarize the changes being made. Commit messages should be written in the imperative mood and should describe what happens when the commit is applied.
+
+One way to think about it is that your commit message should be able to complete the sentence:
+"When applied, this commit will..."
+
+#### Body
+For breaking changes, new features, refactors, or other major changes, the body of the commit message should describe the motivation behind the change in greater detail and may include references to the issue tracker. The body shouldn't repeat code/comments from the diff.
+
+### Guidelines for Pull Requests
+
+Wherever possible, pull requests should add a single feature or fix a single bug. Pull requests should not bundle several unrelated changes.
+
+### Code Quality
+
+#### Warnings
+
+Your pull request should add no new warnings to the project. It should also generally not disable any warnings.
+
+#### Build and Test
+
+Make sure the project builds and that the tests pass! This will generally also be checked by CI before merge, but trying it yourself first means you'll catch problems earlier and your contribution can be merged that much sooner!
+
+To check that things are still working, run the project's build/test command. For many projects this command is:
+
+```bash
+nix-build release.nix
+```
+
+### Documentation
+
+#### In the code
+We're always striving to improve documentation. Please include [haddock](https://haskell-haddock.readthedocs.io/en/latest/index.html) documentation for any added code, and update the documentation for any code you modify.
+
+#### In the [Changelog](ChangeLog.md)
+Add an entry to the changelog when your PR:
+* Adds a feature
+* Deprecates something
+* Includes a breaking change
+* Makes any other change that will impact users
+
+#### In the [Readme](README.md)
+The readme is the first place a lot of people look for information about the repository. Update any parts of the readme that are affected by your PR.

ChangeLog.md

@@ -2,7 +2,7 @@
 
 This project's release branch is `master`. This log is written from the perspective of the release branch: when changes hit `master`, they are considered released.
 
-##  Unreleased
+##  Version v0.1.0
 
 * Automated spin-up and shut down of Hydra Node networks
 * Proxy addresses to streamline fund managment and enforce security invariants

README.md

@@ -576,3 +576,7 @@ Once Hydra Pay is available, you will simply run either the provided docker cont
 ### Can I run plutus scripts on a Head using Hydra Pay?
 
 Not initially, we will be guaging the need/interest in this feature as Hydra Pay evolves and we get feedback from developers.
+
+## Contributing
+
+Contributions and issue reports are encouraged and appreciated! Refer to the [Contributing](CONTRIBUTING.md) guide for information about getting started.