Updating Dogecoin references in CONTRIBUTING
This commit is contained in:
parent
4272f9bbb1
commit
abf2bfede4
|
@ -1,7 +1,7 @@
|
||||||
Contributing to Bitcoin Core
|
Contributing to Dogecoin Core
|
||||||
============================
|
============================
|
||||||
|
|
||||||
The Bitcoin Core project operates an open contributor model where anyone is
|
The Dogecoin Core project operates an open contributor model where anyone is
|
||||||
welcome to contribute towards development in the form of peer review, testing
|
welcome to contribute towards development in the form of peer review, testing
|
||||||
and patches. This document explains the practical process and guidelines for
|
and patches. This document explains the practical process and guidelines for
|
||||||
contributing.
|
contributing.
|
||||||
|
@ -57,12 +57,12 @@ the pull request affects. Valid areas as:
|
||||||
|
|
||||||
- *Consensus* for changes to consensus critical code
|
- *Consensus* for changes to consensus critical code
|
||||||
- *Docs* for changes to the documentation
|
- *Docs* for changes to the documentation
|
||||||
- *Qt* for changes to bitcoin-qt
|
- *Qt* for changes to dogecoin-qt
|
||||||
- *Mining* for changes to the mining code
|
- *Mining* for changes to the mining code
|
||||||
- *Net* or *P2P* for changes to the peer-to-peer network code
|
- *Net* or *P2P* for changes to the peer-to-peer network code
|
||||||
- *RPC/REST/ZMQ* for changes to the RPC, REST or ZMQ APIs
|
- *RPC/REST/ZMQ* for changes to the RPC, REST or ZMQ APIs
|
||||||
- *Scripts and tools* for changes to the scripts and tools
|
- *Scripts and tools* for changes to the scripts and tools
|
||||||
- *Tests* for changes to the bitcoin unit tests or QA tests
|
- *Tests* for changes to the dogecoin unit tests or QA tests
|
||||||
- *Trivial* should **only** be used for PRs that do not change generated
|
- *Trivial* should **only** be used for PRs that do not change generated
|
||||||
executable code. Notably, refactors (change of function arguments and code
|
executable code. Notably, refactors (change of function arguments and code
|
||||||
reorganization) and changes in behavior should **not** be marked as trivial.
|
reorganization) and changes in behavior should **not** be marked as trivial.
|
||||||
|
@ -157,11 +157,11 @@ where possible keep them short, uncomplex and easy to verify.
|
||||||
"Decision Making" Process
|
"Decision Making" Process
|
||||||
-------------------------
|
-------------------------
|
||||||
|
|
||||||
The following applies to code changes to the Bitcoin Core project (and related
|
The following applies to code changes to the Dogecoin Core project (and related
|
||||||
projects such as libsecp256k1), and is not to be confused with overall Bitcoin
|
projects such as libsecp256k1), and is not to be confused with overall Dogecoin
|
||||||
Network Protocol consensus changes.
|
Network Protocol consensus changes.
|
||||||
|
|
||||||
Whether a pull request is merged into Bitcoin Core rests with the project merge
|
Whether a pull request is merged into Dogecoin Core rests with the project merge
|
||||||
maintainers and ultimately the project lead.
|
maintainers and ultimately the project lead.
|
||||||
|
|
||||||
Maintainers will take into consideration if a patch is in line with the general
|
Maintainers will take into consideration if a patch is in line with the general
|
||||||
|
@ -179,7 +179,7 @@ In general, all pull requests must:
|
||||||
- where bugs are fixed, where possible, there should be unit tests
|
- where bugs are fixed, where possible, there should be unit tests
|
||||||
demonstrating the bug and also proving the fix. This helps prevent regression.
|
demonstrating the bug and also proving the fix. This helps prevent regression.
|
||||||
|
|
||||||
Patches that change Bitcoin consensus rules are considerably more involved than
|
Patches that change Dogecoin consensus rules are considerably more involved than
|
||||||
normal because they affect the entire ecosystem and so must be preceded by
|
normal because they affect the entire ecosystem and so must be preceded by
|
||||||
extensive mailing list discussions and have a numbered BIP. While each case will
|
extensive mailing list discussions and have a numbered BIP. While each case will
|
||||||
be different, one should be prepared to expend more time and effort than for
|
be different, one should be prepared to expend more time and effort than for
|
||||||
|
@ -220,7 +220,7 @@ higher in terms of discussion and peer review requirements, keeping in mind that
|
||||||
mistakes could be very costly to the wider community. This includes refactoring
|
mistakes could be very costly to the wider community. This includes refactoring
|
||||||
of consensus critical code.
|
of consensus critical code.
|
||||||
|
|
||||||
Where a patch set proposes to change the Bitcoin consensus, it must have been
|
Where a patch set proposes to change the Dogecoin consensus, it must have been
|
||||||
discussed extensively on the mailing list and IRC, be accompanied by a widely
|
discussed extensively on the mailing list and IRC, be accompanied by a widely
|
||||||
discussed BIP and have a generally widely perceived technical consensus of being
|
discussed BIP and have a generally widely perceived technical consensus of being
|
||||||
a worthwhile change based on the judgement of the maintainers.
|
a worthwhile change based on the judgement of the maintainers.
|
||||||
|
@ -229,7 +229,7 @@ a worthwhile change based on the judgement of the maintainers.
|
||||||
Release Policy
|
Release Policy
|
||||||
--------------
|
--------------
|
||||||
|
|
||||||
The project leader is the release manager for each Bitcoin Core release.
|
The project leader is the release manager for each Dogecoin Core release.
|
||||||
|
|
||||||
Copyright
|
Copyright
|
||||||
---------
|
---------
|
||||||
|
|
Loading…
Reference in a new issue