-
Notifications
You must be signed in to change notification settings - Fork 72
Review rotation policy: remove reviewer from active review rotation if there's prolonged lack of feedback on randomly-rolled PRs / indication that unavailability is temporary #856
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
Comments
Important This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Concerns or objections can formally be registered here by adding a comment.
Concerns can be lifted with:
See documentation at https://forge.rust-lang.org |
@rustbot second |
@rfcbot concern quantify-time-before-setting-reviewer-off-rotation We need to specify a time or there will be arguments about what the right time is supposed to be. |
Spelled out 4 weeks as a rough threshold, subject to future adjustments as necessary. @rfcbot resolve quantify-time-before-setting-reviewer-off-rotation |
Remove estebank from automated review assignment First of all, Esteban thanks for all the reviews 💙 I think you've been quite busy IRL recently, so I'm proposing to remove you from the *automated* review assignment to prevent randomly rolling compiler PRs to you until you have more availability. If this is just temporary, please close this PR! This is [just a way to improve our fairness when assigning reviews, trying to find a balance between leaving time to Rust contributors review on their terms and availability and avoid having PRs waiting for too long](rust-lang/compiler-team#856). > [!NOTE] > > This only prevents randomly-rolled compiler PRs from being auto assigned to you, it does not prevent explicit `r?` assignments. **Please feel free to re-add yourself back to the active review rotation once you have more availability (if you feel like it).** - If you want, it's also possible to only opt-out of the *general* compiler review rotation (`r? compiler`) but keep e.g. `r? diagnostics` rolls. r? compiler_leads
Remove estebank from automated review assignment First of all, Esteban thanks for all the reviews 💙 I think you've been quite busy IRL recently, so I'm proposing to remove you from the *automated* review assignment to prevent randomly rolling compiler PRs to you until you have more availability. If this is just temporary, please close this PR! This is [just a way to improve our fairness when assigning reviews, trying to find a balance between leaving time to Rust contributors review on their terms and availability and avoid having PRs waiting for too long](rust-lang/compiler-team#856). > [!NOTE] > > This only prevents randomly-rolled compiler PRs from being auto assigned to you, it does not prevent explicit `r?` assignments. **Please feel free to re-add yourself back to the active review rotation once you have more availability (if you feel like it).** - If you want, it's also possible to only opt-out of the *general* compiler review rotation (`r? compiler`) but keep e.g. `r? diagnostics` rolls. r? compiler_leads
Rollup merge of rust-lang#140579 - jieyouxu:temp-remove, r=wesleywiser Remove estebank from automated review assignment First of all, Esteban thanks for all the reviews 💙 I think you've been quite busy IRL recently, so I'm proposing to remove you from the *automated* review assignment to prevent randomly rolling compiler PRs to you until you have more availability. If this is just temporary, please close this PR! This is [just a way to improve our fairness when assigning reviews, trying to find a balance between leaving time to Rust contributors review on their terms and availability and avoid having PRs waiting for too long](rust-lang/compiler-team#856). > [!NOTE] > > This only prevents randomly-rolled compiler PRs from being auto assigned to you, it does not prevent explicit `r?` assignments. **Please feel free to re-add yourself back to the active review rotation once you have more availability (if you feel like it).** - If you want, it's also possible to only opt-out of the *general* compiler review rotation (`r? compiler`) but keep e.g. `r? diagnostics` rolls. r? compiler_leads
Proposal
Motivation
Life happens. Sometimes compiler reviewers are just busy. Sometimes compiler reviewers on active compiler review rotation simply don't have enough time / don't feel like reviewing randomly rolled PRs, during extremely hectic / busy periods of time. And that's completely understandable.
At the same time, contributors submitting PRs for compiler changes can also reasonably expect that they will receive feedback within a reasonable timeframe, or at least indication that the randomly rolled compiler reviewer (on active review rotation) acknowledges the PR but may not get to it soon. It can be frustrating if the PR stays open for prolonged periods of time, yet receives no feedback from the randomly rolled compiler reviewer, accumulating merge conflicts.
See prior discussions in:
Proposed course of action
If a compiler reviewer on active compiler review rotation has not provided feedback on most randomly-rolled compiler PRs for more than 4 weeks, remove the busy/inactive compiler reviewer from active compiler review rotation. Note that this prevents randomly assigned compiler PRs but intentionally does not prevent explicit/manual
r?
assignment.The busy/inactive compiler reviewer is of course more-than-welcomed to re-add themselves to the active compiler review rotation, when they have more availability.
This is a two-way door, because:
Removal protocol
assign.adhoc_groups.compiler
triagebot.toml
config.Mentors or Reviewers
@Noratrieb who proposed this, but needs to have no blocking concerns from compiler team in general.
Process
The main points of the Major Change Process are as follows:
@rustbot second
.-C flag
, then full team check-off is required.@rfcbot fcp merge
on either the MCP or the PR.You can read more about Major Change Proposals on forge.
The text was updated successfully, but these errors were encountered: