Update CONTRIBUTING.md
This commit is contained in:
parent
6daa23e09c
commit
f822ac4b8a
@ -50,12 +50,12 @@ Pull Request Philosophy
|
|||||||
Patchsets should always be focused. For example, a pull request could add a feature, fix a bug, or refactor code; but not a mixture. Please also avoid super pull requests which attempt to do too much, are overly large, or overly complex as this makes review difficult.
|
Patchsets should always be focused. For example, a pull request could add a feature, fix a bug, or refactor code; but not a mixture. Please also avoid super pull requests which attempt to do too much, are overly large, or overly complex as this makes review difficult.
|
||||||
|
|
||||||
|
|
||||||
###Features
|
### Features
|
||||||
|
|
||||||
When adding a new feature, thought must be given to the long term technical debt and maintenance that feature may require after inclusion. Before proposing a new feature that will require maintenance, please consider if you are willing to maintain it (including bug fixing). If features get orphaned with no maintainer in the future, they may be removed by the Repository Maintainer.
|
When adding a new feature, thought must be given to the long term technical debt and maintenance that feature may require after inclusion. Before proposing a new feature that will require maintenance, please consider if you are willing to maintain it (including bug fixing). If features get orphaned with no maintainer in the future, they may be removed by the Repository Maintainer.
|
||||||
|
|
||||||
|
|
||||||
###Refactoring
|
### Refactoring
|
||||||
|
|
||||||
Refactoring is a necessary part of any software project's evolution. The following guidelines cover refactoring pull requests for the project.
|
Refactoring is a necessary part of any software project's evolution. The following guidelines cover refactoring pull requests for the project.
|
||||||
|
|
||||||
@ -85,7 +85,7 @@ In general, all pull requests must:
|
|||||||
Patches that change NeoBytes 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 other kinds of patches because of increased peer review and consensus building requirements.
|
Patches that change NeoBytes 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 other kinds of patches because of increased peer review and consensus building requirements.
|
||||||
|
|
||||||
|
|
||||||
###Peer Review
|
### Peer Review
|
||||||
|
|
||||||
Anyone may participate in peer review which is expressed by comments in the pull request. Typically reviewers will review the code for obvious errors, as well as test out the patch set and opine on the technical merits of the patch. Project maintainers take into account the peer review when determining if there is consensus to merge a pull request (remember that discussions may have been spread out over github, mailing list and IRC discussions). The following language is used within pull-request comments:
|
Anyone may participate in peer review which is expressed by comments in the pull request. Typically reviewers will review the code for obvious errors, as well as test out the patch set and opine on the technical merits of the patch. Project maintainers take into account the peer review when determining if there is consensus to merge a pull request (remember that discussions may have been spread out over github, mailing list and IRC discussions). The following language is used within pull-request comments:
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user