-
Notifications
You must be signed in to change notification settings - Fork 47
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add pr/review guidelines #456
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some minor suggestions for improving the flow of the page. I added a bit of prose which please feel free to ignore.
.. toctree:: | ||
:maxdepth: 1 | ||
|
||
PRs and Reviews <prs-and-reviews.rst> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a note, if you adopt the below heading change you don't need to rename the link here. It doesn't matter too much though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was a bit picky, but please don't be offended ; )
We can work through the comments together, if you like
|
||
- For bug fix PRs: add test which would catch the issue without the fix | ||
- Do newly added tests have the correct granularity? | ||
- Do tests have a suitable runtime or are unnecessarily large? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Remove words after "runtime"
Reviewer Behavior | ||
----------------- | ||
|
||
- provide timely feedback and respond to changes by the author of the pull request in a reasonable amount of time; it's best to give feedback to pull requests as quickly as possible. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- After establishing what PR stands for, use PR throughout (vs. "pull request")
----------------- | ||
|
||
- provide timely feedback and respond to changes by the author of the pull request in a reasonable amount of time; it's best to give feedback to pull requests as quickly as possible. | ||
- only request changes if they are ready to resolve the request upon changes by the author of the pull request; stalling pull requests for requested changes that have been addressed is a problem. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Here, do you mean, "please make sure your PR review comments / change requests are not redundant"
- only request changes if they are ready to resolve the request upon changes by the author of the pull request; stalling pull requests for requested changes that have been addressed is a problem. | ||
- only review pull requests that have been marked as ready; we have a bunch of pull requests that explore the feasibility of ideas and just need the CI to run. Similarly, pull requests should only be marked as "ready for review" if the author is reasonably happy with the status. If the author mostly seeks feedback on general design and direction, this should be clearly communicated in the pull request description (either "draft" or "ready for review"). | ||
- mirror communication with pull request author outside of pull requests (on slack, in person, video calls, etc.) in comments to the pull request. | ||
- contact authors directly if more clarification is needed. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Are lines 72 and 73 saying the same thing?
- only review pull requests that have been marked as ready; we have a bunch of pull requests that explore the feasibility of ideas and just need the CI to run. Similarly, pull requests should only be marked as "ready for review" if the author is reasonably happy with the status. If the author mostly seeks feedback on general design and direction, this should be clearly communicated in the pull request description (either "draft" or "ready for review"). | ||
- mirror communication with pull request author outside of pull requests (on slack, in person, video calls, etc.) in comments to the pull request. | ||
- contact authors directly if more clarification is needed. | ||
- not be afraid of reviewing pull requests even if they are (slightly) outside their comfort zone. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Maybe also suggest that potential reviewers can partner with an experienced Kokkos team member to perform review to mature reviewing skills?
Co-authored-by: Francesco Rizzi <[email protected]> Co-authored-by: Nicolas Morales <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me know once the other reviews are addressed
No description provided.