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
|
||||
and patches. This document explains the practical process and guidelines for
|
||||
contributing.
|
||||
|
@ -57,12 +57,12 @@ the pull request affects. Valid areas as:
|
|||
|
||||
- *Consensus* for changes to consensus critical code
|
||||
- *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
|
||||
- *Net* or *P2P* for changes to the peer-to-peer network code
|
||||
- *RPC/REST/ZMQ* for changes to the RPC, REST or ZMQ APIs
|
||||
- *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
|
||||
executable code. Notably, refactors (change of function arguments and code
|
||||
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
|
||||
-------------------------
|
||||
|
||||
The following applies to code changes to the Bitcoin Core project (and related
|
||||
projects such as libsecp256k1), and is not to be confused with overall Bitcoin
|
||||
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 Dogecoin
|
||||
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 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
|
||||
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
|
||||
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
|
||||
|
@ -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
|
||||
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 BIP and have a generally widely perceived technical consensus of being
|
||||
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
|
||||
--------------
|
||||
|
||||
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
|
||||
---------
|
||||
|
|
Loading…
Reference in a new issue