1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
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.
|
