2016-11-01 10:11:19 +00:00
|
|
|
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.
|
|
|
|
|
|
2016-10-17 22:17:45 +00:00
|
|
|
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.
|
