Hi All, I wanted to follow up on the discussion we had on the weekly sync meeting, namely: how can we reduce the "time to committed" for a contribution without compromising quality.
A few of the ideas we were talking about on the meeting (and some I've seen work on other projects): *For contributors:* - Incentivize newer contributors to cross-review each-others' PRs, so the review burden is reduced on the committers - Utilize feature branches more consistently as master-proxies, so the reviews get smaller, more incremental and should thus reduce the overall complexity of the review for large features, as proposed by Julien - Discuss community best practices wrt PRs that are waiting for feedback: like waiting periods, pinging people, calling interactive review meetings, or anything related. *For committers/reviewers:* - From a reviewer's perspective we could also discuss some best practices or etiquette rules of thumb: e.g. in my previous project we had other committers start timeouts on blocks, reviewers pinging other reviewers if you were going to be unavailable or we would propose some alternative methods for resolving issues (interactive/live reviews/discussions) - We should also make it explicit if a design doc is needed for a particular feature and that the review on that doc is a blocker for the rest of the code reviews, so we don't end up creating PRs before the approach is vetted I wanted to raise this, so we can leverage the collective experience (with processes/best practices) of the community and maybe discuss the useful aspects on the next sync meeting. Best, Anna
