|
|
@ -130,7 +130,7 @@ pull requests which attempt to do too much, are overly large, or overly complex |
|
|
|
as this makes review difficult. |
|
|
|
as this makes review difficult. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
###Features |
|
|
|
### Features |
|
|
|
|
|
|
|
|
|
|
|
When adding a new feature, thought must be given to the long term technical debt |
|
|
|
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 |
|
|
|
and maintenance that feature may require after inclusion. Before proposing a new |
|
|
@ -139,7 +139,7 @@ maintain it (including bug fixing). If features get orphaned with no maintainer |
|
|
|
in the future, they may be removed by the Repository 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 |
|
|
|
Refactoring is a necessary part of any software project's evolution. The |
|
|
|
following guidelines cover refactoring pull requests for the project. |
|
|
|
following guidelines cover refactoring pull requests for the project. |
|
|
@ -187,7 +187,7 @@ other kinds of patches because of increased peer review and consensus building |
|
|
|
requirements. |
|
|
|
requirements. |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
###Peer Review |
|
|
|
### Peer Review |
|
|
|
|
|
|
|
|
|
|
|
Anyone may participate in peer review which is expressed by comments in the pull |
|
|
|
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 |
|
|
|
request. Typically reviewers will review the code for obvious errors, as well as |
|
|
|