Conversation
|
|
||
| on: | ||
| pull_request_target: | ||
| types: [opened] |
There was a problem hiding this comment.
Hi @Phlip79, I noticed this is only triggered on opened. Does the team want to include reopened as well? If a PR is closed and then reopened, it would currently bypass the 'force-to-draft' logic and stay in 'Ready for review' mode.
| - Comment “/ok to test commid_id” to kick off testing suite | ||
| - Add the “Expert Review” label | ||
| - Select an expert reviewer from each expert group as a reviewer. If you’re unsure who to select, pick a “maintainer” or manager. | ||
| - Expert reviewers are auto-assigned when the PR is marked “Ready for Review” |
There was a problem hiding this comment.
Strictly speaking, they will be notified after ready for review. Reviewers are attached as soon as the PR is being opened irrespective of draft mode. But I’ll leave finding the right level of technical depth to you
| - **Expert reviewers should review within 1 business day.** Message the assigned reviewer if it is taking longer. The reviewer either needs to review the PR or suggest an alternate reviewer. | ||
| - If the reviewer is not responding after 2 business days, escalate to the reviewer's manager. | ||
| - Add the “Final Review” label after experts approve | ||
| - If the reviewer is not responding after 2 business days, escalate to the reviewer’s manager. |
There was a problem hiding this comment.
Who is this note for? Maybe it’s obsolete nowadays?
There was a problem hiding this comment.
I.e. how do we do that if we cannot reach out to everyone? Maybe via MCore-oncall?
|
/claude review |
What does this PR do ?
Changing the review process to:
Before this PR is merged in I will change all open PRs that do not have the "Expert Review" or "Final Review" process to draft PRs.
Contribution process
flowchart LR A[Pre-checks] --> B[PR Tests] subgraph Code Review/Approval C1[Expert Review] --> C2[Final Review] end B --> C1 C2 --> D[Merge]Pre-checks
Core 0.8)Code review
The following process is enforced via the CODEOWNERS file for changes into
megatron/core. For changes outside ofmegatron/core, it is up to the PR author whether or not to tag the Final Reviewer team.For MRs into `main` branch
Feel free to message or comment the @mcore-oncall to help accelerate your merge into main. The less complex your PR is, the faster it will be approved and merged!
(Step 1): Add PR label
Expert Review(Step 2): Collect the expert reviewers reviews
Expert Reviewlabel when your PR is ready for review.Final Review might get declined if these requirements are not fulfilled.
(Step 3): Final Review
Final Reviewlabel(Optional Step 4): Cherry-pick into release branch
If this PR also needs to be merged into
core_r*release branches, after this PR has been merged, selectCherry-pickto open a new PR into the release branch.For MRs into `dev` branch
The proposed review process for `dev` branch is under active discussion.MRs are mergable after one approval by either
eharper@nvidia.comorzijiey@nvidia.com.Merging your PR
Any member of core-adlr and
core-nemowill be able to merge your PR.