Misc/update contributing guidelines (#173)

* Add code of conduct.

* Update contributing guidelines.

CODE_OF_CONDUCT.md

@@ -0,0 +1,5 @@
+# Code of Conduct
+
+The signac team is committed to fostering a diverse and welcoming community.
+The signac project has therefore adopted the [Contributor Covenant Code of Conduct](https://signac.io/conduct/).
+Please email [signac-support@umich.edu](mailto:signac-support@umich.edu) if you have any questions or concerns.

CONTRIBUTING.md

@@ -13,9 +13,9 @@ All contributors must agree to the Contributor Agreement ([ContributorAgreement.
 
 ### General guidelines
 
-  * Use the [git flow](https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) model of development:
-    - Bug fixes should be based on `master` if they affect a current release of the package.
-    - New features should be developed in a feature branch based on `develop`.
+  * Use the [OneFlow](https://www.endoflineblog.com/oneflow-a-git-branching-model-and-workflow) model of development:
+    - Both new features and bug fixes should be developed in branches based on `master`.
+    - Hotfixes (critical bugs that need to be released *fast*) should be developed in a branch based on the latest tagged release.
   * Write code that is compatible with all supported versions of Python (listed in [setup.py](https://github.com/glotzerlab/signac/blob/master/setup.py)).
   * Avoid introducing dependencies -- especially those that might be harder to install in high-performance computing environments.
   * Create [unit tests](https://en.wikipedia.org/wiki/Unit_testing) and [integration tests](https://en.wikipedia.org/wiki/Integration_testing) that cover the common cases and the corner cases of the code.

doc/support.rst

@@ -61,8 +61,8 @@ Finally, we recommend to setup a `Flake8 <http://flake8.pycqa.org/en/latest/>`_
 With the *flake8* hook, your code will be checked for syntax and style before you make a commit.
 The continuous integration pipeline for the package will perform these checks as well, so running these tests before committing / pushing will prevent the pipeline from failing due to style-related issues.
 
-The git-flow development workflow
----------------------------------
+The development workflow
+------------------------
 
 Prior to working on a patch, it is advisable to create an `issue <https://github.com/glotzerlab/signac/issues>`_ that describes the problem or proposed feature.
 This means that the code maintainers and other users get a chance to provide some input on the scope and possible limitations of the proposed changes, as well as advise on the actual implementation.
@@ -73,8 +73,8 @@ Unrelated changes, such as minor fixes to unrelated bugs encountered during impl
 Branches should be named after the following pattern: ``<prefix>/issue-<#>-optional-short-description``.
 Choose from one of the following prefixes depending on the type of change:
 
-  * ``fix/``: Any changes that fix a bug in the code or an error in the documentation; should be based on the *master* branch.
-  * ``feature/``: Any changes that introduce a new feature; should be based on the *develop* branch.
+  * ``fix/``: Any changes that fix the code and documentation.
+  * ``feature/``: Any changes that introduce a new feature.
   * ``release/``: Reserved for release branches.
 
 If your change does not seem to fall into any of the above mentioned categories, use ``misc/``.