How to reduce the "committed time" for contributions

[Anna Szonyi <sz...@cloudera.com.INVALID>]

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

Re: How to reduce the "committed time" for contributions

[Julien Le Dem <ju...@wework.com.INVALID>]

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 <sz...@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
>