Rename CONTRIBUTING to CONTRIBUTING.md

Renaming document allows a CONTRIBUTING guide to be better formatted and therefore more accessible.

1 files changed, 36 insertions, 0 deletions

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
new file mode 100644
index 000000000..55fcedccd
--- /dev/null
+++ b/CONTRIBUTING.md
@@ -0,0 +1,36 @@
+A good way to help is to test, and report bugs.
+See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html if you
+want to help that way. Testing is invaluable in making a piece
+of software solid and usable.
+
+Patches are preferably to be sent via a github pull request. If that
+can't be done, patches in "git format-patch" format can be sent
+(eg, posted to fpaste.org with a long enough timeout and a link
+posted to #monero-dev on irc.freenode.net).
+
+Patches should be self contained. A good rule of thumb is to have
+one patch per separate issue, feature, or logical change. Also, no
+other changes, such as random whitespace changes or reindentation.
+Following the code style of the particular chunk of code you're
+modifying is encourgaged. Proper squashing should be done (eg, if
+you're making a buggy patch, then a later patch to fix the bug,
+both patches should be merged).
+
+Commit messages should be sensible. That means a subject line that
+describes the patch, with an optional longer body that gives details,
+documentation, etc.
+
+Comments are encouraged.
+
+If modifying code for which Doxygen headers exist, that header must
+be modified to match.
+
+When submitting a pull request on github, make sure your branch is
+rebased. No merge commits nor stray commits from other people in
+your submitted branch, please. You may be asked to rebase if there
+are conflicts (even trivially resolvable ones).
+
+PGP signing commits is strongly encouraged. That should explain why
+the previous paragraph is here.
+
+Tests would be nice to have if you're adding functionality.