split libs review rotation in two #389
Conversation
There was a problem hiding this comment.
This would end up assigning all library PRs to libs due to this dirs mapping:
highfive/highfive/configs/rust-lang/rust.json
Lines 103 to 108 in 9c691d5
Maybe highfive could comment on library PRs instructing that if the PR contains a new library API or contains a stabilization of a library feature that has not already completed FCP in its tracking issue, then please comment with r? rust-lang/libs-api @rustbot label +T-libs-api
That was my intent, I figured as a starting point we could rely on the libs, team to reassign to libs-api when appropriate.
That sounds like a great idea! I think there's a message field so I'll set that up. |
yaahc
force-pushed
the
libs-rotations
branch
2 times, most recently
from
201d84b to
37e31ba
Compare
|
I wonder if this will work... Edit: survey says no, looks like I can't set the assignee, so this will have to do as a ping. |
|
Looks good with the conflict fixed. |
Add mention message for authors to categorize their own PRs Update message and fix trailing cc remove unnecessary trailing newlines Add thomcc to review rotation as well
…crum Autolabel library PRs with T-libs Continuation of rust-lang/highfive#389 We're trying to improve the libs team review structure and part of that is defaulting PRs to the T-libs team to act as a mini-triage team for all the libs teams / project groups. Highfive doesn't do issue tagging so we will rely on triagebot to pre-triage for t-libs to post-triage :)
The libs team discussed how we could improve review bandwidth for libs vs libs-api PRs and came to the conclusion that the best first step would be to separate the review rotations.
The goal of this split is to allow team members to focus on subsets of library work that they're most interested in and to allow independent growth of the review rotation focused on non-API affecting changes (aka libs PRs vs libs-api PRs). The libs APIs are generally less common, easier to review, often more time sensitive, and a much better entry point for new contributors interested in participating in the libs team. These properties make this an ideal starting point for new libs reviewers and contributors. By splitting the review rotations and focusing on increasing review bandwidth for non-API changes we can make this contribution experience more pleasant which will encourage repeat contributors and increase how much important bug fix / perf improvement / doc improvement style work we get done as a team.