Proposal 1: +0
Proposal 2: +1
Additional Comments:
I like the idea of providing a clear expectation to contributors on how
promptly they can expect code review feedback. From your proposal, my main
feedback would to prefer a single goal instead of two. Having a single goal
seems simpler when choosing a code reviewer ("PersonA might have more
context on my change, but PersonB will give quicker feedback.."). Multiple
tiers of commitment also feels like it implies level of commitment to the
community ("PersonB must be more committed to Beam than PersonA because
they agreed to faster code reviews").
There is a balance to strike: we should provide prompt feedback and clear
expectations for code contributors, but we shouldn't set unreasonable
targets for code reviewers. I'd be interested in hearing from others
whether 24-hours seems unreasonable.
I think that we should also make it clear with any policy that opting-in is
optional and not required to be part of the Beam community. There are many
ways to contribute to Beam, and opting-in to reviewing code contributions
is just one of them.
On Mon, Jun 4, 2018 at 3:20 PM Huygaa Batsaikhan <bat...@google.com> wrote:
> Proposal 1: +1
> Proposal 2: +1
> Additional Comments: This is an example vote
>
> On Mon, Jun 4, 2018 at 3:15 PM Huygaa Batsaikhan <bat...@google.com>
> wrote:
>
>> A few months ago, Reuven sent out an email
>> <https://lists.apache.org/thread.html/6c213d28c8e8c1a23614fb4d1837744bd044b6a68f3c47975333e71b@%3Cdev.beam.apache.org%3E>
>> about improvements to Beam's code review process. Because the email covered
>> multiple issues, we did not really dig deep into each of them. One of the
>> suggestions was to agree on a code review response turnaround time (SLO
>> <https://en.wikipedia.org/wiki/Service_level_objective>). Here is the
>> direct quote:
>>
>> It would be great if we could agree on a response-time SLA for Beam code
>> reviews. The response might be “I am unable to do the review until next
>> week,” however even that is better than getting no response.
>>
>>
>> All the comments on the original thread supported having an agreed upon
>> SLO. Therefore, I would like to discuss possible response-time SLO and
>> finalize it within this thread. For the purpose of this discussion, let's
>> put aside related topics such as the need of tooling support like PR
>> dashboard or reviewer availability for future discussions.
>>
>> *My proposals*
>>
>> *Proposal 1*
>> I propose having a *Default* review response time as *3 business days*.
>> This aligns with the frequency we consider most developers are checking the
>> dev list. My reasoning is, if one is checking the dev list, they could also
>> check their PR review queue.
>>
>> *Proposal 2*
>> I propose having an *Opt-in* review response time as *24 hours*.
>> Contributors are happy when reviewers respond swiftly to their PRs.
>> Specially, when we are making multiple small changes to Beam, waiting for
>> even a few days is frustrating. I understand that not all the reviewers can
>> review PRs daily. However, if some of us can incorporate half an hour of
>> beam review to our schedule, it could improve contributors' experience
>> drastically. Therefore, I suggest us having opt-in response time of 24
>> hours. We can discuss how we can communicate this SLO to contributors and
>> reviewers in a separate thread.
>>
>> Please vote on these 2 proposals and propose any other solutions using
>> within this template:
>>
>> Template:
>> Proposal 1: <+-1> <?explanation>
>> Proposal 2: <+-1> <?explanation>
>> Additional Comments: <?explanation>
>>
>> Example answer:
>> Proposal 1: +1 Great idea
>> Proposal 2: +1
>> Additional Comments: I have this idea foobar ....
>>
>> Thank you,
>> Huygaa
>>
>>
