split libs review rotation in two

[yaahc]

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.

[yaahc]

This would end up assigning all library PRs to libs due to this dirs mapping:

That was my intent, I figured as a starting point we could rely on the libs, team to reassign to libs-api when appropriate.

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 sounds like a great idea! I think there's a message field so I'll set that up.

[yaahc]

I wonder if this will work...

r? @Mark-Simulacrum

Edit: survey says no, looks like I can't set the assignee, so this will have to do as a ping.

[Mark-Simulacrum]

Looks good with the conflict fixed.