-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Bors policy question: Auto-reassignment on r+ #59489
Comments
@rfcbot merge |
Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged team members:
No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
@rfcbot reviewed |
What should happen when the PR author approves the PR themselves (like when users are delegated and forget to Also, sometimes we do |
Would the original reviewer be unassigned? If we do |
Sure; seems fine... that's an implementation detail imo ;)
Seems reasonable -- otherwise pick the first?
Seems like @pietroalbini's note... so we'd skip in that case? |
We cannot assign to users that are not members of the repo, correct? |
Nope, to be able to be assigned an user needs at least to have explicit read access to the repo. |
We should probably conservatively do nothing on |
@petrochenkov hehe; maybe not... let's see ;) there have been similar situations that have worked. As for |
@Centril |
Last time in #56951 the list has 26 people. For this there are 42 people. Let's see :) IIRC |
@Centril Sorry, for some reason I mixed this up with your "test, please ignore" issue and thought review hadn't actually been requested from me. My bad! |
Since there are only 3 checkboxes remaining and I've tried to reach those involved on many occasions I'm going to take the liberty to tick one of them (under the same "on leave" rationale) so that we can move on... |
@rfcbot reviewed |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to merge, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon. |
Currently, the behavior of @bors is that whenever you
@bors r+
or@bors r=UserFooBar
, the reviewer doesn't change. However, this makes it less clear who the current reviewer is. For example, the assignee might not have even looked at the PR before someone else has r+ed it. I believe having an up to date assignee more frequently would simplify triage. Also, as @pnkfelix noted:While one could
r? @Centril @bors r+
and such all the time, people often forget this and it instead causes churn to do so manually. As an example, there's #59468.Instead, I propose that:
r+
a PR, you get r? as well.r=UserFooBar
, and @UserFooBar is not assigned, then they will be assigned.The tagged teams are those that typically use @bors in this repo or perform triage and who will therefore be affected by this policy.
The text was updated successfully, but these errors were encountered: