docs(release): document release process

update CONTRIBUTING.MD and make a CHANGELOG for the first release

CHANGELOG.md

@@ -0,0 +1,29 @@
+# go-fil-markets changelog
+
+# go-fil-markets 0.1.0
+
+Initial tagged release for Filecoin Testnet Phase 2
+
+### Contributors
+
+❤️ Huge thank you to everyone that made this release possible! By alphabetical order, here are all the humans who contributed commits in `go-fil-markets` to date:
+
+- [acruikshank]
+- [anorth]
+- [arajasek]
+- [ergastic]
+- [hannahhoward]
+- [ingar]
+- [jsign]
+- [laser]
+- [magik6k]
+- [mishmosh]
+- [shannonwells]
+- [whyrusleeping]
+
+### 🙌🏽 Want to contribute?
+
+Would you like to contribute to this repo and don’t know how? Here are a few places you can get started:
+
+- Check out the [Contributing Guidelines](https://github.com/filecoin-project/go-fil-markets/blob/master/CONTRIBUTING.md)
+- Look for issues with the `good-first-issue` label in [go-fil-markets](https://github.com/filecoin-project/go-fil-markets/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+label%3A%22e-good-first-issue%22+)

CONTRIBUTING.md

@@ -18,10 +18,27 @@ For best results, before submitting a PR, make sure:
 Special Note:
 If editing README.md, please conform to the [standard readme specification](https://github.com/RichardLitt/standard-readme/blob/master/spec.md).
 
-Before a PR can be merged to `master`, it must:
+### PR Process
+
+Active development of `go-fil-markets` occurs on the `development` branch. All PRs should be made to the `development` branch, which is the default branch on Github.
+
+Before a PR can be merged to `development`, it must:
 1. Pass continuous integration.
+1. Be rebased and up to date with the development branch
 1. Be approved by at least two maintainers
 
+When merging normal PRs to development, always use squash and merge to maintain a linear commit history.
+
+### Release Process
+
+The `master` branch is consider our production branch, and should always be up to date with the latest tagged release.
+
+There are two ways to update `master`. The first is to cut a new full release by making a PR from `development` to `master` with the latest changes from development. When the PR is merged, it MUST be merged via a merge commit. At this point, make a new tagged version release and seperately, make a second PR back to `development` from `master` once the release is verified as ready to go, to get the merge commit in development. (maintaining a shared commit history). Only a lead maintainer may merge to `master`.
+
+The second way to update `master` is to hotfix it. Hot fixes are branched off `master` and merged directly back into `master` to fix critical bugs in a production release. When a creating a hotfix, create a PR to `master` and once approved, merge with `master` then create a seperate PR to merge `master` back to `development` with the hotfix to maintain the shared commit history
+
+Following the release of Filecoin Mainnet, this library will following a semantic versioning scheme for tagged releases.
+
 ### Testing
 
 - All new code should be accompanied by unit tests. Prefer focused unit tests to integration tests for thorough validation of behaviour. Existing code is not necessarily a good model, here.