Rename CONTRIBUTING to CONTRIBUTING.md

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

1 files changed, 0 insertions, 36 deletions

diff --git a/CONTRIBUTING b/CONTRIBUTING
deleted file mode 100644
index 55fcedccd..000000000
--- a/CONTRIBUTING
+++ /dev/null
@@ -1,36 +0,0 @@
-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.