Thanks for starting this discussion Anna. I agree we need to improve and should try your suggestions What do others think?
On Tue, Oct 16, 2018 at 11:46 Anna Szonyi <szo...@cloudera.com.invalid> wrote: > 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 >
