doc: Update CONTRIBUTING.md

This commit renames SUBMITTING_PATCHES to CONTRIBUTING.md as
well as updates CONTRIBUTING.md to match libseccomp's contributing
document.  The section on running `./regression` wasn't applicable
to the libseccomp-golang project, so it was removed.

Signed-off-by: Tom Hromatka <tom.hromatka@oracle.com>
Signed-off-by: Paul Moore <paul@paul-moore.com>

SUBMITTING_PATCHES → CONTRIBUTING.md

@@ -8,11 +8,11 @@ to the rules described here, but by following the instructions below you
 should have a much easier time getting your work merged with the upstream
 project.
 
-* Test Your Code
+## Test Your Code Using Existing Tests
 
-There are two possible tests you can run to verify your code.  The first test
-is used to check the formatting and coding style of your changes, you can run
-the test with the following command:
+There are two possible tests you can run to verify your code.  The first
+test is used to check the formatting and coding style of your changes, you
+can run the test with the following command:
 
 	# make check-syntax
 
@@ -27,30 +27,13 @@ with the following command:
 
 ... if there are any faults or errors they will be displayed.
 
-* Generate the Patch(es)
+## Add New Tests for New Functionality
 
-Depending on how you decided to work with the libseccomp code base and what
-tools you are using there are different ways to generate your patch(es).
-However, regardless of what tools you use, you should always generate your
-patches using the "unified" diff/patch format and the patches should always
-apply to the libseccomp source tree using the following command from the top
-directory of the libseccomp sources:
+Any submissions which add functionality, or significantly change the existing
+code, should include additional tests to verify the proper operation of the
+proposed changes.
 
-	# patch -p1 < changes.patch
-
-If you are not using git, stacked git (stgit), or some other tool which can
-generate patch files for you automatically, you may find the following command
-helpful in generating patches, where "libseccomp.orig/" is the unmodified
-source code directory and "libseccomp/" is the source code directory with your
-changes:
-
-	# diff -purN libseccomp-golang.orig/ libseccomp-golang/
-
-When in doubt please generate your patch and try applying it to an unmodified
-copy of the libseccomp sources; if it fails for you, it will fail for the rest
-of us.
-
-* Explain Your Work
+## Explain Your Work
 
 At the top of every patch you should include a description of the problem you
 are trying to solve, how you solved it, and why you chose the solution you
@@ -59,7 +42,7 @@ if you can describe/include a reproducer for the problem in the description as
 well as instructions on how to test for the bug and verify that it has been
 fixed.
 
-* Sign Your Work
+## Sign Your Work
 
 The sign-off is a simple line at the end of the patch description, which
 certifies that you wrote it or otherwise have the right to pass it on as an
@@ -97,16 +80,49 @@ your real name, saying:
 
 	Signed-off-by: Random J Developer <random@developer.example.org>
 
-* Email Your Patch(es)
+You can add this to your commit description in `git` with `git commit -s`
+
+## Post Your Patches Upstream
+
+The libseccomp project accepts both GitHub pull requests and patches sent via
+the mailing list.  GitHub pull requests are preferred.  This sections below
+explain how to contribute via either method. Please read each step and perform
+all steps that apply to your chosen contribution method.
+
+### Submitting via Email
+
+Depending on how you decided to work with the libseccomp code base and what
+tools you are using there are different ways to generate your patch(es).
+However, regardless of what tools you use, you should always generate your
+patches using the "unified" diff/patch format and the patches should always
+apply to the libseccomp source tree using the following command from the top
+directory of the libseccomp sources:
+
+	# patch -p1 < changes.patch
+
+If you are not using git, stacked git (stgit), or some other tool which can
+generate patch files for you automatically, you may find the following command
+helpful in generating patches, where "libseccomp.orig/" is the unmodified
+source code directory and "libseccomp/" is the source code directory with your
+changes:
+
+	# diff -purN libseccomp.orig/ libseccomp/
+
+When in doubt please generate your patch and try applying it to an unmodified
+copy of the libseccomp sources; if it fails for you, it will fail for the rest
+of us.
 
 Finally, you will need to email your patches to the mailing list so they can
-be reviewed and potentially merged into the main libseccomp-golang repository.
-When sending patches to the mailing list it is important to send your email in
-text form, no HTML mail please, and ensure that your email client does not
-mangle your patches.  It should be possible to save your raw email to disk and
-apply it directly to the libseccomp source code; if that fails then you likely
-have a problem with your email client.  When in doubt try a test first by
-sending yourself an email with your patch and attempting to apply the emailed
-patch to the libseccomp-golang repository; if it fails for you, it will fail
-for the rest of us trying to test your patch and include it in the main
-libseccomp-golang repository.
+be reviewed and potentially merged into the main libseccomp repository.  When
+sending patches to the mailing list it is important to send your email in text
+form, no HTML mail please, and ensure that your email client does not mangle
+your patches.  It should be possible to save your raw email to disk and apply
+it directly to the libseccomp source code; if that fails then you likely have
+a problem with your email client.  When in doubt try a test first by sending
+yourself an email with your patch and attempting to apply the emailed patch to
+the libseccomp repository; if it fails for you, it will fail for the rest of
+us trying to test your patch and include it in the main libseccomp repository.
+
+### Submitting via GitHub
+
+See [this guide](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/creating-a-pull-request) if you've never done this before.