From dc35c736428aead0791f65ecb005bd95ccf9cd62 Mon Sep 17 00:00:00 2001 From: Mike C Date: Sun, 9 Apr 2017 13:14:09 -0600 Subject: Rename CONTRIBUTING to CONTRIBUTING.md Renaming document allows a CONTRIBUTING guide to be better formatted and therefore more accessible. --- CONTRIBUTING | 36 ------------------------------------ CONTRIBUTING.md | 36 ++++++++++++++++++++++++++++++++++++ 2 files changed, 36 insertions(+), 36 deletions(-) delete mode 100644 CONTRIBUTING create mode 100644 CONTRIBUTING.md 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. 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. -- cgit v1.2.3