contributing: Is your PR easy to say "yes" to? (#31059)
Co-authored-by: mvines <mvines@gmail.com> Co-authored-by: Andrew Fitzgerald <apfitzge@gmail.com>
This commit is contained in:
parent
e14f77790b
commit
4452ba59b0
|
@ -147,6 +147,7 @@ generous (and not expected) to rebase or reword commits such that each change
|
|||
matches the logical flow in your PR description.
|
||||
|
||||
### The PR / Issue Labels
|
||||
|
||||
Labels make it easier to manage and track PRs / issues. Below some common labels
|
||||
that we use in Solana. For the complete list of labels, please refer to the
|
||||
[label page](https://github.com/solana-labs/solana/issues/labels):
|
||||
|
@ -194,6 +195,38 @@ a commit. After a reviewer adds feedback, they won't be checking on the status
|
|||
of that feedback after every new commit. Instead, directly mention the reviewer
|
||||
when you feel your PR is ready for another pass.
|
||||
|
||||
### Is your PR easy to say "yes" to?
|
||||
|
||||
PRs that are easier to review are more likely to be reviewed. Strive to make
|
||||
your PR easy to say "yes" to.
|
||||
|
||||
Non-exhaustive list of things that make it *harder* to review:
|
||||
|
||||
* Additional changes that are orthogonal to the problem statement and proposed
|
||||
changes. Instead move those changes to a different PR.
|
||||
* Renaming variables/functions/types unnecessarily and/or without explanation.
|
||||
* Not following established conventions in the function/module/crate/repo.
|
||||
* Changing whitespace: moving code and/or reformatting code. Make such changes
|
||||
in a separate PR.
|
||||
* Force-pushing the branch unnecessarily; this makes it harder to track any
|
||||
previous comments on specific lines of code, and also harder to track changes
|
||||
already reviewed from previous commits.
|
||||
* When force-pushing is required—for example to handle a merge conflict—and
|
||||
no new changes have been made since the previous review, indicating as such
|
||||
is beneficial.
|
||||
* Not responding to comments from previous rounds of review. Follow the
|
||||
guidance in [How to manage review feedback?](#how-to-manage-review-feedback).
|
||||
|
||||
Non-exhaustive list of things that make it *easier* to review:
|
||||
|
||||
* Adding tests for all new/changed behavior.
|
||||
* Including in the PR's description any non-automated testing that was
|
||||
performed.
|
||||
* Including relevant results for changes that target performance improvements.
|
||||
|
||||
Note that these lists are *independent* of how simple/complicated the actual
|
||||
*code* changes are.
|
||||
|
||||
## Draft Pull Requests
|
||||
|
||||
If you want early feedback on your PR, use GitHub's "Draft Pull Request"
|
||||
|
|
Loading…
Reference in New Issue