Mirroristas/kaspad
2
0
Fork 0
mirror of https://github.com/kaspanet/kaspad.git synced 2026-03-14 12:24:58 +00:00
Code Issues Packages Projects Releases Wiki Activity

[NOD-494] Update readmes (#543)

Browse Source 
* [NOD-494] Updated main README.md

* [NOD-494] Updated blockdag/README.md

* [NOD-494] Aligned text length in main README.md

* [NOD-494] Updated most remaining packages READMEs + deleted util/coinset

* [NOD-494] Update integration README

* [NOD-494] Did a final pass over all readmes

* [NOD-494] Updated README for DNSSeeder with more info on how to create a functioning setup

* [NOD-494] Remove all double spaces from readmes

* [NOD-494] Minor fixes in READMEs + update license to kaspanet developers

* [NOD-494] Add backtick around ecc and util in hdkeychain README
This commit is contained in:
Svarog
2019-12-16 17:37:17 +02:00
committed by stasatdaglabs
parent a140327dd2
commit 1cd2eb9308
53 changed files with 405 additions and 1911 deletions
Download Patch File Download Diff File Expand all files Collapse all files

66
docs/code_contribution_guidelines.md
View File

@@ -22,17 +22,17 @@
Developing cryptocurrencies is an exciting endeavor that touches a wide variety
of areas such as wire protocols, peer-to-peer networking, databases,
cryptography, language interpretation (transaction scripts), RPC, and
websockets. They also represent a radical shift to the current fiscal system
websockets. They also represent a radical shift to the current fiscal system
and as a result provide an opportunity to help reshape the entire financial
system. There are few projects that offer this level of diversity and impact
system. There are few projects that offer this level of diversity and impact
all in one code base.
However, as exciting as it is, one must keep in mind that cryptocurrencies
represent real money and introducing bugs and security vulnerabilities can have
far more dire consequences than in typical projects where having a small bug is
minimal by comparison. In the world of cryptocurrencies, even the smallest bug
in the wrong area can cost people a significant amount of money. For this
reason, the btcd suite has a formalized and rigorous development process which
minimal by comparison. In the world of cryptocurrencies, even the smallest bug
in the wrong area can cost people a significant amount of money. For this
reason, the kaspad suite has a formalized and rigorous development process which
is outlined on this page.
We highly encourage code contributions, however it is imperative that you adhere
@@ -43,9 +43,9 @@ to the guidelines established on this page.
### 2. Minimum Recommended Skillset
The following list is a set of core competencies that we recommend you possess
before you really start attempting to contribute code to the project. These are
before you really start attempting to contribute code to the project. These are
not hard requirements as we will gladly accept code contributions as long as
they follow the guidelines set forth on this page. That said, if you don't have
they follow the guidelines set forth on this page. That said, if you don't have
the following basic qualifications you will likely find it quite difficult to
contribute.
@@ -59,7 +59,7 @@ contribute.
the code your change relies on, and the code which relies on your changed code
Building on top of those core competencies, the recommended skill set largely
depends on the specific areas you are looking to contribute to. For example,
depends on the specific areas you are looking to contribute to. For example,
if you wish to contribute to the cryptography code, you should have a good
understanding of the various aspects involved with cryptography such as the
security and performance implications.
@@ -69,9 +69,9 @@ security and performance implications.
### 3. Required Reading
- [Effective Go](http://golang.org/doc/effective_go.html) - The entire btcd
suite follows the guidelines in this document. For your code to be accepted,
suite follows the guidelines in this document. For your code to be accepted,
it must follow the guidelines therein.
- [Original Satoshi Whitepaper](http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fbitcoin.org%2Fbitcoin.pdf&ei=os3VUuH8G4SlsASV74GoAg&usg=AFQjCNEipPLigou_1MfB7DQjXCNdlylrBg&sig2=FaHDuT5z36GMWDEnybDJLg&bvm=bv.59378465,d.b2I) - This is the white paper that started it all. Having a solid
- [Original Satoshi Whitepaper](http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CCkQFjAA&url=http%3A%2F%2Fbitcoin.org%2Fbitcoin.pdf&ei=os3VUuH8G4SlsASV74GoAg&usg=AFQjCNEipPLigou_1MfB7DQjXCNdlylrBg&sig2=FaHDuT5z36GMWDEnybDJLg&bvm=bv.59378465,d.b2I) - This is the white paper that started it all. Having a solid
foundation to build on will make the code much more comprehensible.
<a name="DevelopmentPractices" />
@@ -86,7 +86,7 @@ branch.
### 4.1 Share Early, Share Often
We firmly believe in the share early, share often approach. The basic premise
We firmly believe in the share early, share often approach. The basic premise
of the approach is to announce your plans **before** you start work, and once
you have started working, craft your changes into a stream of small and easily
reviewable commits.
@@ -110,19 +110,19 @@ This approach has several benefits:
### 4.2 Testing
One of the major design goals of all core btcd packages is to aim for complete
test coverage. This is financial software so bugs and regressions can cost
people real money. For this reason every effort must be taken to ensure the
code is as accurate and bug-free as possible. Thorough testing is a good way to
test coverage. This is financial software so bugs and regressions can cost
people real money. For this reason every effort must be taken to ensure the
code is as accurate and bug-free as possible. Thorough testing is a good way to
help achieve that goal.
Unless a new feature you submit is completely trivial, it will probably be
rejected unless it is also accompanied by adequate test coverage for both
positive and negative conditions. That is to say, the tests must ensure your
positive and negative conditions. That is to say, the tests must ensure your
code works correctly when it is fed correct data as well as incorrect data
(error paths).
Go provides an excellent test framework that makes writing test code and
checking coverage statistics straight forward. For more information about the
checking coverage statistics straight forward. For more information about the
test coverage tools, see the [golang cover blog post](http://blog.golang.org/cover).
A quick summary of test practices follows:
@@ -156,7 +156,7 @@ func CompactToBig(compact uint32) *big.Int {
**RIGHT**
```Go
// CompactToBig converts a compact representation of a whole number N to a
// big integer. The representation is similar to IEEE754 floating point
// big integer. The representation is similar to IEEE754 floating point
// numbers.
//
// Like IEEE754 floating point, there are three basic components: the sign,
@@ -207,8 +207,8 @@ comment can make.
### 4.4 Model Git Commit Messages
This project prefers to keep a clean commit history with well-formed commit
messages. This section illustrates a model commit message and provides a bit
of background for it. This content was originally created by Tim Pope and made
messages. This section illustrates a model commit message and provides a bit
of background for it. This content was originally created by Tim Pope and made
available on his website, however that website is no longer active, so it is
being provided here.
@@ -217,9 +217,9 @@ Here’s a model Git commit message:
```
Short (50 chars or less) summary of changes
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of an email and the rest of the text as the body. The blank
line separating the summary from the body is critical (unless you omit
the body entirely); tools like rebase can get confused if you run the
two together.
@@ -251,7 +251,7 @@ a good thing.
subtract 4 columns for the indent on the left and 4 more for symmetry on the
right, we’re left with 72 columns.
- git format-patch --stdout converts a series of commits to a series of emails,
using the messages for the message body. Good email netiquette dictates we
using the messages for the message body. Good email netiquette dictates we
wrap our plain text emails such that there’s room for a few levels of nested
reply indicators without overflow in an 80 column terminal.
@@ -260,14 +260,14 @@ a good thing.
### 5. Code Approval Process
This section describes the code approval process that is used for code
contributions. This is how to get your changes into btcd.
contributions. This is how to get your changes into btcd.
<a name="CodeReview" />
### 5.1 Code Review
All code which is submitted will need to be reviewed before inclusion into the
master branch. This process is performed by the project maintainers and usually
master branch. This process is performed by the project maintainers and usually
other committers who are interested in the area you are working in as well.
##### Code Review Timeframe
@@ -275,21 +275,21 @@ other committers who are interested in the area you are working in as well.
The timeframe for a code review will vary greatly depending on factors such as
the number of other pull requests which need to be reviewed, the size and
complexity of the contribution, how well you followed the guidelines presented
on this page, and how easy it is for the reviewers to digest your commits. For
on this page, and how easy it is for the reviewers to digest your commits. For
example, if you make one monolithic commit that makes sweeping changes to things
in multiple subsystems, it will obviously take much longer to review. You will
in multiple subsystems, it will obviously take much longer to review. You will
also likely be asked to split the commit into several smaller, and hence more
manageable, commits.
Keeping the above in mind, most small changes will be reviewed within a few
days, while large or far reaching changes may take weeks. This is a good reason
days, while large or far reaching changes may take weeks. This is a good reason
to stick with the [Share Early, Share Often](#ShareOften) development practice
outlined above.
##### What is the review looking for?
The review is mainly ensuring the code follows the [Development Practices](#DevelopmentPractices)
and [Code Contribution Standards](#Standards). However, there are a few other
and [Code Contribution Standards](#Standards). However, there are a few other
checks which are generally performed as follows:
- The code is stable and has no stability or security concerns
@@ -303,9 +303,9 @@ checks which are generally performed as follows:
### 5.2 Rework Code (if needed)
After the code review, the change will be accepted immediately if no issues are
found. If there are any concerns or questions, you will be provided with
found. If there are any concerns or questions, you will be provided with
feedback along with the next steps needed to get your contribution merged with
master. In certain cases the code reviewer(s) or interested committers may help
master. In certain cases the code reviewer(s) or interested committers may help
you rework the code, but generally you will simply be given feedback for you to
make the necessary changes.
@@ -317,7 +317,7 @@ This process will continue until the code is finally accepted.
Once your code is accepted, it will be integrated with the master branch.
Typically it will be rebased and fast-forward merged to master as we prefer to
keep a clean commit history over a tangled weave of merge commits. However,
keep a clean commit history over a tangled weave of merge commits. However,
regardless of the specific merge method used, the code will be integrated with
the master branch and the pull request will be closed.
@@ -351,5 +351,5 @@ Rejoice as you will now be listed as a [contributor](https://github.com/kaspanet
### 6.2. Licensing of Contributions
All contributions must be licensed with the
[ISC license](https://github.com/kaspanet/kaspad/blob/master/LICENSE). This is
[ISC license](https://github.com/kaspanet/kaspad/blob/master/LICENSE). This is
the same license as all of the code in the btcd suite.