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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 >>> >>>
