Merge branch 'origin/jed/contributing' [PR #137]

* origin/jed/contributing:
  Comment out refrence to 'maint' branch until relevant
  Contributing: be more precise and add some references

Author: jedbrown

CONTRIBUTING.md

@@ -1,24 +1,38 @@
 # How to Contribute
 
-Contributions to libCEED are welcome.
-
+Contributions to libCEED are encouraged.
+<!---
 Please use a pull request to the appropriate branch ('maint' for
 backward-compatible bug fixes for the last stable release, 'master' for
 new features and everything else).
+-->
+Please make your commits well-organized and
+[atomic](https://en.wikipedia.org/wiki/Atomic_commit#Atomic_commit_convention),
+using `git rebase --interactive` as needed.  Check that tests
+(including "examples") pass using `make prove-all`.  If adding a new
+feature, please add or extend a test so that your new feature is
+tested.
+
+In typical development, every commit should compile, be covered by the
+test suite, and pass all tests.  This improves the efficiency of
+reviewing and facilitates use of
+[`git bisect`](https://git-scm.com/docs/git-bisect).
 
-Please make your commits well-organized and atomic, using `git rebase
---interactive` as needed.  Open an issue or RFC pull request to discuss
-any significant changes before investing time.  Check that the tests
-pass using `make prove` or `make test`.  If adding a new feature, please
-add or extend a test so that it is tested.
+Open an issue or RFC (request for comments) pull request to discuss
+any significant changes before investing time.  It is useful to create
+a WIP (work in progress) pull request for any long-running development
+so that others can be aware of your work and help to avoid creating
+merge conflicts.
 
 Write commit messages for a reviewer of your pull request and for a
 future developer (maybe you) that bisects and finds that a bug was
-introduced in your commit.  The assumptions that are clear in your head
-right now are likely not.  Give credit where credit is due using tags
-such as `Reported-by: Helpful User <[email protected]>`.  Please use a
-real name and email for your author information (`git config user.name`
-and `user.email`).
+introduced in your commit.  The assumptions that are clear in your
+mind while committing are likely not in the mind of whomever (possibly
+you) needs to understand it in the future.
+
+Give credit where credit is due using tags such as `Reported-by:
+Helpful User <[email protected]>`.  Please use a real name and email
+for your author information (`git config user.name` and `user.email`).
 
 Please avoid "merging from upstream" (like merging 'master' into your
 feature branch) unless there is a specific reason to do so, in which
@@ -27,6 +41,10 @@ case you should explain why in the merge commit.
 [Junio](https://gitster.livejournal.com/42247.html) and
 [Linus](http://yarchive.net/comp/linux/git_merges_from_upstream.html).
 
+You can use `make style` to help conform to coding conventions of the
+project, but try to avoid mixing whitespace or formatting changes with
+content changes (see atomicity above).
+
 By submitting a pull request, you are affirming the following.
 
 ## [Developer's Certificate of Origin 1.1](https://developercertificate.org/).