# Decreasing review time for Rust compiler contributions > **Disclaimer**: this document is a draft of some ideas presented and discussed in various meetings but contains no actionables --- Hello community, This is an announcement of a new initiative from the Rust team compiler. **Summary**: we want to tackle the problem of slow review times. Contributors submit patches to the Rust project and sometimes have to wait up to weeks for a feedback. We realize how frustrating this can be, we will be running an experiment aimed to gradually reduce review times (our goal is to lower it down to about 10 days). ## The problem We understand that pull requests are left unreviewed for a number of reasons. Among them: - Github notifications are lost - A reviewer is autoassigned by the `@rustbot` but doesn’t pick up the review, because ... - ... people's capacity varies during time - ... not everyone is familiar with every part of the Rust compiler (i.e. the pool of reviewers with proper context may be actually smaller) - The pull request in is a state where it's not clear how to proceed Many compiler hackers are volunteers, we really appreciate their work and for this reason we cannot ask anyone to commit to an arbitrary effort not compatible with their bandwidth. On the other end we have people submitting patches to the Rust project with some expectations: code reviews should make contributing a pleasant experience and encourage people to contribute more. To solve this tension we will try to: 1) look in the current pool of contributors for people with more bandwidth, able to commit to a shorter review window 2) increase the number of contributors helping with reviews While we cannot guarantee reviews within a _few days_, it is reasonable to target about 10 days for a substantial feedback. To reach this goal we will open a new informal team next to the [rust-lang/compiler] and [rust-lang/compiler-contributors]: the [rust-lang/compiler-reviewers] team. The `rust-lang/compiler-reviewers` can intersect the other two teams (basically anyone having rights to review and approve pull requests on the Rust Github project). [rust-lang/compiler]: https://github.com/rust-lang/team/blob/master/teams/compiler.toml [rust-lang/compiler-contributors]: https://github.com/rust-lang/team/blob/master/teams/compiler-contributors.toml [rust-lang/compiler-reviewers]: # ## The lifecycle of a pull request A contributor opens a new pull request; when ready, they ask for a review with `r? compiler`: a reviewer is autoassigned (or `r? @github_user` for a specific person). If after about 10 days there's no feedback, someone from the compiler team (or `WG-Prioritization` team) rolls again `r? rust-lang/compiler-reviewers` and a new reviewer will be autoassigned. This new reviewer has committed to react in about 7 days. "React" here means unblocking the review, either suggesting how to proceed or - if the work on the pull request looks good - approve for merging. That should bring down the _worst case_ to 10 + 7 = about 17 days. It's a first goal we want to start with then gradually bring it even further down, if the conditions will us allow us. A pull request often goes through multiple rounds of reviews before being merged (or declined). Often other people chime in with comments. In addition, some time is spent on testing and profiling the patch (will this patch influence the compiler performance? Will it introduce breaking changes? Are Rust Analyzer and Clippy happy? Etc.). This time is not accounted in this estimate. For these (and other) reasons reviewers see their backlog grow constantly so we don't expect a pull request to be _merged_ in 10 days, unless it's a trivial change. Our goal is to provide a substancial feedback to the contributor after 7 days after they signaled that the pull request is available for review. It's important to note that in order to avoid pull request idling, both the contributor and the reviewer need to assign to the other party the review flag: 1. Contributor asks for a review with `@rustbot ready` 2. Reviewer checks the pull request and close the review with `@rustbot author` 3. Repeat from 1. until the pull request receives an `r+` (i.e. is approved for merge) Pull requests started with one reviewer and being left lagging a bit behind will be reassigned to someone else after one or two reminders. This may sound dismissive, but it's not - we are just being mindful of contributors. We also understand (and are flexible about) that during specific period of the year the general availability of people may be reduced and people take their PTO (Personal Time Off): contributing to the Rust compiler should not get in the way of personal life. ## Intended audience (i.e. how you can contribute) This program will work if we have the support of the community: if you would like pull requests to be merged quicker and are already somewhat familiar with the Rust compiler, get in contact with us and help us make it happen! If you already have review rights and can commit to a more structured review cycle - you are a great candidate for `rust-lang/compiler-reviewers`. If you are not yet officially reviewing pull requests but think you can help, please get in contact with us. Being familiar with the `rustc` codebase (even only some parts!) is probably a requisite. For newcomers there will be other specific initiatives to get them started. ## How to get in contact The compiler/WG-prioritization team will be in support and will monitor this experiment and report the results. The official channel for existing (and aspiring!) compiler contributors is on Zulip at the [#t-compiler stream](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler). Feel free to get in contact.