blockworks-foundation
/
solana
mirror of https://github.com/blockworks-foundation/solana.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

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:
Brooks 2023-04-06 08:43:22 -04:00 committed by GitHub
parent e14f77790b
commit 4452ba59b0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 33 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

33
CONTRIBUTING.md
View File

@ -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"