gains CONTRIBUTING.md#5
Conversation
|
|
||
| ## Pull Request Expectations | ||
|
|
||
| Draft PRs are recommended for early feedback. |
There was a problem hiding this comment.
I'm not super fond of this. Because when I get tagged in a PR that keeps having commits made to it - so I get numerous emails about a PR - I start treating the emails as spam. It's too much noise.
There was a problem hiding this comment.
Hmm, just want to flag that "opening a draft PR" and "requesting a review" are (and definitely should be) separate actions.
Which is a very good flag, and something worth making explicit in this document, I will add that.
In your experience are those happening simultaneously, and the noise comes from requesting a review on a PR in draft mode (e.g. RMI/practices#73), or are your peers opening PRs, in draft mode, and requesting a review immediately?
There was a problem hiding this comment.
My recommendation would be a flow similar to:
- Open a PR in draft mode when it is roughly ready, to trigger CI (and work in public) don't request review (for example: Feat/re prioritize stitch#164)
- When the developer is happy with the PR (CI passes, PR title and description are reasonable) then open the PR and request review (like this: Observability Package stitch#160)
For the maintainer, step 1 doesn't trigger any required action. Step 2 is what needs to be acted on (and fwiw, I believe you can set up GH e-mail notification accordingly to only send on PR review request).
06d1f0c
This a direct copy of the file CONTRIBUTING.md from the practices repo.
We should delete it from
practicesonce this PR is merged to avoid duplication.