Merge pull request #118 from jim-parry/explanation/signing

Explain reasoning for secure signing

Author: lonnieezell

user_guide_src/source/contributing/process.rst

@@ -23,6 +23,38 @@ at the same time, we might really want X but disagree with Y, meaning we
 cannot merge the request. Using the Git-Flow branching model you can create
 new branches for both of these features and send two requests.
 
+Why Signing Is Important
+=======================
+
+We ask that contributions have code commits signed. This is important in order
+to prove, as best we can, the provenance of contributions.
+
+The developer pushing a commit as part of a PR isn't necessarily the person
+who committed it originally, if the commit is not signed. This distorts the
+commit history and makes it hard to tell where code came from.
+
+If a person "signs" a commit, they are free to use any name, specifically
+one not their own. Again, the commit history cannot be relied on to determine
+the origin of the code, if one developer is spoofing another. A malicious person 
+could commit bad code (for instance a virus) and make it look like another
+developer created it.
+
+The best solution, while not fool-proof, is to "securely sign" your
+commits. Such commits are digitally signed, with a GPG-key, and
+associated with your github account. It still isn't foolproof, because
+a malicious developer could create a bogus email and account, but it is
+more reliable than an unsigned or a "signed" commit.
+
+If you don't sign your commits, we **may** accept your contribution,
+assuming it meets usefulness and contribution guidelines, but only
+if it isn't critical code and only after checking it carefully.
+If code performs an important role, we will insist that it be signed, and if
+it is critical code (however we interpret that), we will insist that your
+contributions be securely signed.
+
+Read below to find out how to sign your commits :)
+
+
 Basic Signing
 =============
 You must sign your work, certifying that you either wrote the work or