I love that you are pushing this forward. Just a note on mailing list
practice - I think we might want a round of discussion before declaring a
vote. A vote is a formal thing and this seems a bit more open-ended still.
Couple of thoughts:
- What is the action when an SLO is missed?
- Contributors are definitely encouraged to volunteer for initial reviews.
Helping the community like that is great, and something I'd look at when
considering someone as a potential committer.
Kenn
On Tue, Jun 5, 2018 at 1:20 PM Alan Myrvold <amyrv...@google.com> wrote:
> Proposal 1: +1
> Proposal 2: 0
>
> Additional comments:
> Does this apply to committers only, or are contributors encourage to
> volunteer as an additional reviewer?
> I like the idea of documenting who is keen to review which area, plus
> reviewer availability.
> From a contributor standpoint, it is worth avoiding long delays; perhaps
> having a dashboard or email of reviews that are awaiting feedback?
> Will there be a document to propose tooling?
> The 24 hours appears to be 7 days a week, 365/6 days a year? It would be
> good to build in time for everyone to disconnect.
>
> On Tue, Jun 5, 2018 at 1:07 PM Scott Wegner <sweg...@google.com> wrote:
>
>> 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
>>>>
>>>>
