Refresh contributing to fit Dogecoin

* Remove references to lead maintainer.
* Put branch strategy near the top so people raise PRs against the right branch.
* Emphasise the need to test, and the types of tests involved.
* Add links to community.
This commit is contained in:
Ross Nicoll 2021-05-25 16:40:02 +01:00 committed by Ross Nicoll
parent 8515c7b46f
commit d716845e25

View file

@ -1,18 +1,18 @@
# Contributing to Dogecoin Core
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.
Dogecoin Core is an open source project, and we would welcome contributions which provably
improve the state of the software. For those wanting to discuss changes, or look for work
that needs doing, please see:
Firstly in terms of structure, there is no particular concept of "Core
developers" in the sense of privileged people. Open source often naturally
revolves around meritocracy where longer term contributors gain more trust from
the developer community. However, some hierarchy is necessary for practical
purposes. As such there are repository "maintainers" who are responsible for
merging pull requests as well as a "lead maintainer" who is responsible for the
release cycle, overall merging, moderation and appointment of maintainers.
* [Projects](https://github.com/dogecoin/dogecoin/projects)
* [Dogecoindev on reddit](https://www.reddit.com/r/dogecoindev/)
* [Discord](https://discord.gg/dogecoin) (in particular the #core-dev channel)
## Branch Strategy
Dogecoin Core's default branch is intentionally a stable release, so that anyone downloading the code and compiling it gets a stable release.
Active development occurs on branches named after the version they are targetting, for example the 1.14.4 branch is named `1.14.4-dev`.
When raising PRs, please raise against the relevant development branch, **not** against the `master` branch.
## Contributor Workflow
@ -22,9 +22,15 @@ facilitates social contribution, easy testing and peer review.
To contribute a patch, the workflow is as follows:
- Fork repository
- Create topic branch
- Commit patches
- Fork repository in GitHub, and clone it your development machine.
- Create topic branch from the relevant development branch.
- As these branches are in the contributor's local repository, naming is not critical,
although it is recommended that you include the target version. If the change relates
to an issue, including its number in the branch name is also a good idea.
- Commit patches to the branch.
- Test your changes, which **must** include the unit and RPC tests passing. Changes will not be accepted if they do not pass tests.
- Push topic branch to your copy of the repository.
- Raise PR via GitHub.
The project coding conventions in the [developer notes](doc/developer-notes.md)
must be adhered to.
@ -50,39 +56,6 @@ about Git.
- Push changes to your fork
- Create pull request
The title of the pull request should be prefixed by the component or area that
the pull request affects. Valid areas as:
- *Consensus* for changes to consensus critical code
- *Docs* for changes to the documentation
- *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 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.
Examples of trivial PRs are changes to:
- comments
- whitespace
- variable names
- logging and messages
- *Utils and libraries* for changes to the utils and libraries
- *Wallet* for changes to the wallet code
Examples:
Consensus: Add new opcode for BIP-XXXX OP_CHECKAWESOMESIG
Net: Automatically create hidden service, listen on Tor
Qt: Add feed bump button
Trivial: Fix typo in init.cpp
If a pull request is specifically not to be considered for merging (yet) please
prefix the title with [WIP] or use [Tasks Lists](https://help.github.com/articles/basic-writing-and-formatting-syntax/#task-lists)
in the body of the pull request to indicate tasks are pending.
The body of the pull request should contain enough description about what the
patch does together with any justification/reasoning. You should include
references to any discussions (for example other tickets or mailing list
@ -154,12 +127,12 @@ where possible keep them short, uncomplex and easy to verify.
## "Decision Making" Process
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
The following applies to code changes to the Dogecoin Core project, and is not
to be confused with overall Dogecoin
Network Protocol consensus changes.
Whether a pull request is merged into Dogecoin Core rests with the project merge
maintainers and ultimately the project lead.
maintainers.
Maintainers will take into consideration if a patch is in line with the general
principles of the project; meets the minimum standards for inclusion; and will