doc: Add GitHub pr template#14217
Conversation
b632a20 to
77dc435
Compare
Please provide clear motivation for this patch 😃 |
|
ACK |
77dc435 to
ecc80fc
Compare
There was a problem hiding this comment.
Markdown nit:
2018-09-15 11:00:30 mdl(pr=14217): .github/PULL_REQUEST_TEMPLATE.md:13: MD006 Consider starting bulleted lists at the beginning of the line
ecc80fc to
1e6aa1d
Compare
There was a problem hiding this comment.
2018-09-15 17:29:22 proselint(pr=14217): .github/PULL_REQUEST_TEMPLATE.md:4:20: weasel_words.very Substitute 'damn' every time you're inclined to write 'very;' your editor will delete it and the writing will be just as it should be. Found once elsewhere.
There was a problem hiding this comment.
2018-09-15 17:29:22 proselint(pr=14217): .github/PULL_REQUEST_TEMPLATE.md:4:20: weasel_words.very Substitute 'damn' every time you're inclined to write 'very;' your editor will delete it and the writing will be just as it should be. Found once elsewhere.
1e6aa1d to
c603130
Compare
|
utACK c603130f7926b863198d10ac6fd707fc05a78ec6 |
There was a problem hiding this comment.
a/an thorough explanation
c603130 to
fa0c680
Compare
|
re-utACK fa0c680b9a566c3d272e28898777de94fcd0d342 |
|
Addressed all comment/feedback |
There was a problem hiding this comment.
Not sure if I'm reading this right, but is the intention to say that a change needs to
- significantly improve user experience
or - significantly improve developer experience
or is it more that a change has to
- improve user experience
or - significantly improve developer experience
Because the way I read it is that significantly applies to both terms, but I imagine that significantly is only supposed to apply to the second term. Because why would you turn down a papercut fix that smoothes the UX a little?
IOW, maybe this could be rephrased to be less ambiguous
|
ACK fa0c680 It might be worth saying something about test coverage. I'm not sure what our established policy is here, but maybe something like: * All changes should have accompanying unit tests (see `src/test/`) or functional tests (see `test/`).
PR authors should note which tests cover modified code. If no tests exist for a region of
modified code, new tests should accompany the change. |
jnewbery
left a comment
There was a problem hiding this comment.
ACK.
I've offered my preferred colour of paint for your shed. Feel free to use it or not.
There was a problem hiding this comment.
Please note that 'please note that' is conent-free in almost all circumstances, and is usually better left out. :)
There was a problem hiding this comment.
I'd also change 'are' to 'may be'
There was a problem hiding this comment.
I'd move this to the end. The next paragraph 'Please provide clear motivation...' is more important.
fa0c680 to
fadc2a9
Compare
|
Added the test coverage requirement. |
|
reACK |
|
It seems like this PR is doing two different things:
I personally only like the first thing and not the second thing, but don't want to interfere if this is how maintainers want to handle PRs. |
|
@ryanofsky The policy was introduced about a year ago: 91c39e3 |
|
LGTM (restarted travis job) |
There was a problem hiding this comment.
"are always welcome, but might be rejected" is a bit awkward—I think it should note why features are rejected. For example, to keep the project from expanding in scope, as it dilutes focus and increases maintenance burden. Or that we don't want to add dependencies. Contributors should consider first whether it isn't possible to build system outside of the bitcoin core codebase.
|
ACK (with nit) |
|
Since this guide will influence the type of contributions we get: shouldn't we mention security work? Personally I'm much more excited to see a PR submitted which strengthens the long term security of the project in some form compared to when I see a PR submitted which implements some shiny new feature :-) The formulation "Features are always welcome […]" contrasted to "Bug fixes are most welcome when […]" sounds almost like we're encouraging new users to help expand the feature set of Core :-) |
fadc2a9 to
fa6f85a
Compare
fa6f85a to
fae9e84
Compare
|
Addressed all feedback, hopefully. |
|
Something that might be worth mentioning is the special security requirements/trade-offs that apply to changes to the consensus critical parts of the code base. Perhaps also mentioning the rough boundaries of the consensus critical code. More specifically it might be worth mentioning why a change of type A would be an obvious ACK if applied to say the Qt part of the code base while it would be an obvious NACK if applied to the consensus critical part of the code base. Basically to drive home the point that we're extremely focused on correctness and security for good reasons :-) |
|
@practicalswift I believe this is covered in the contributions guideline: https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md#peer-review? |
|
fae9e84 doc: Add GitHub pr template (MarcoFalke) Pull request description: Bitcoin Core has a very thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. Authors should provide clear motivation for patches and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly. Tree-SHA512: 83b379d75934089f13ba173e6ec847845f954f10f83e406ef9722836aa093170c612b4214f22cd5939d59f66a50f5d0e52aa0059423e8e7261bb176f1c546a08
fae9e84 doc: Add GitHub pr template (MarcoFalke) Pull request description: Bitcoin Core has a very thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. Authors should provide clear motivation for patches and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly. Tree-SHA512: 83b379d75934089f13ba173e6ec847845f954f10f83e406ef9722836aa093170c612b4214f22cd5939d59f66a50f5d0e52aa0059423e8e7261bb176f1c546a08
fae9e84 doc: Add GitHub pr template (MarcoFalke) Pull request description: Bitcoin Core has a very thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time. Authors should provide clear motivation for patches and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly. Tree-SHA512: 83b379d75934089f13ba173e6ec847845f954f10f83e406ef9722836aa093170c612b4214f22cd5939d59f66a50f5d0e52aa0059423e8e7261bb176f1c546a08
Bitcoin Core has a very thorough review process and even the most trivial change needs to pass a lot of eyes and requires non-zero or even substantial time effort to review. There is a huge lack of active reviewers on the project, so patches often sit for a long time.
Authors should provide clear motivation for patches and explain how it improves Bitcoin Core user experience or Bitcoin Core developer experience significantly.