# Decreasing review time for Pull Requests

> **Disclaimer**: this document is a draft of some ideas presented and discussed in various meetings but contains no actionables

## Goals

Define a new workflow to reduce the time it takes for:
- **new** PRs to be reviewed
- speed up subsequent reviews of existing PRs

A random sample of PRs that took a bit to be reviewed and needed multiple pings: [#103657](https://github.com/rust-lang/rust/pull/103657), [#96840](https://github.com/rust-lang/rust/pull/96840), [#100987](https://github.com/rust-lang/rust/pull/100987), [#102881](https://github.com/rust-lang/rust/pull/102881), [#101680](https://github.com/rust-lang/rust/pull/101680), [#97550](https://github.com/rust-lang/rust/pull/97550)

We know (or suppose) that PRs are left unreviewed for a couple of reasons: notifications get lost, reviewer is autoassigned but doesn't pick up, people's capacity varies during time, not everyone may be familiar with everything (i.e. the pool of reviewers with proper context may be actually smaller).

## The plan

1. **Formalize a new subteam of T-compiler** f.e. `compiler-reviewers`. This team can intersect the teams [compiler](https://github.com/rust-lang/team/blob/master/teams/compiler.toml) and [compiler-contributors](https://github.com/rust-lang/team/blob/master/teams/compiler-contributors.toml) but can also have new faces ***(Q: *opinions about this*? oli: anyone who already has r+ rights seems fine to me)*** and will be made of people committing to take on new PRs with a reasonable delay.
This team will not be the first line of reviewers but will be a quicker backup for reassignments.
Invoking `r? rust-lang/compiler-reviewers` will assign to someone of this new team (I've checked the triagebot code, hopefully this should work OOTB)

A real-world example could look like this:
- someone opens a new PR, runs `r? rust-lang/compiler` and someone is picked
- After ~10 days without review, @**apiraino** rerolls `r? rust-lang/compiler-reviewers` without asking anyone (as part of the new procedure). The new reviewer is expected to jump in about a week.
- this step could also be automated

2. **Write a blog post** with a "Call For Contributors" looking for people to join this new subteam, explaining that `T-compiler` is working on improving this part of the contributor experience.

All this will hopefully help with **new PRs**.

## PRs that are already being reviewed

@**apiraino** will keep on pinging the assigned reviewer but will try to slowly move the target response time from 3 weeks down to about 2 weeks (if the PR is not blocked on something else):
- If the assigned reviewer is in the `compiler-reviewers` team the expectation is that this should not cause churn
- If the reviewer is in the `compiler` or `compiler-contributor` team the frequency of the ping can be slightly more relaxed