Thanks for writing this up! I especially like the idea of
automatically assigning code reviewers, e.g. via
https://help.github.com/articles/about-codeowners/
On Wed, Jun 27, 2018 at 11:10 AM Scott Wegner <sc...@apache.org> wrote:
>
> Thanks for putting together this proposal Huygaa. Overall looks good to me; I
> added some comments in the doc.
>
> On Tue, Jun 26, 2018 at 7:44 PM Kenneth Knowles <k...@google.com> wrote:
>>
>> Does Kubernetes keep up with their backlog? We were hovering around 100
>> before our recent addition of committers & stalebot, and now around 80. I
>> can imagine their 1000 open PRs might be an OK steady state; they have some
>> 6 month and 2 month PRs but the overall distribution might be sort of like
>> ours. Is the data in a table somewhere? Couple other reference points: Spark
>> has ~500, Flink ~400, Storm ~150, Rust ~150.
>>
>> Kenn
>>
>>
>> On Tue, Jun 26, 2018 at 6:35 PM Rafael Fernandez <rfern...@google.com> wrote:
>>>
>>> I did a quick pass on the doc and left minor comments, thanks! I have some
>>> feedback and thoughts:
>>>
>>> For metrics and tools, there ought to be mature OSS projects out there we
>>> can learn from. I believe Kubernetes has a very healthy practice, it'd be
>>> ideal to learn from them. +Griselda Cuevas can connect you (and people
>>> working on this).
>>> I really like the idea of a style guide (which can evolve) for the various
>>> areas - presumably Java, Python, Go, etc. have their own. The reason I like
>>> it is because reviews become easier -- the reviewer will have an easier
>>> time working with the contributor to make sure together they can introduce
>>> great code that is consistent with the codebase (so they can focus on
>>> functionality and scale discussions, not style, which is published).
>>> I think setting review expectations is hard. Many of us in the community
>>> have various degrees of time devoted to development - some of us are paid
>>> to work on Beam full time, others part time, others are gifting their time
>>> and talent. I find inspiration in the Apache Code of Conduct [1] to instead
>>> empower people to communicate clearly. A company or a developer may choose
>>> to say "This is what you can expect from me", and say, opt-in to email
>>> reminders and such. And when something is time sensitive, we should trust
>>> reviewers to be Apache-y and do a micro version of "Step down consderately"
>>> -- "I can't commit to reviewing this by Friday, I suggest another person.",
>>> for example.
>>>
>>> I think at the end of the day we all need to eliminate guesswork and
>>> promote the healthiest communication we can so we can all continue to grow
>>> the project as fast as we want.
>>>
>>> r
>>>
>>> [1] https://www.apache.org/foundation/policies/conduct.html
>>>
>>> On Tue, Jun 26, 2018 at 5:48 PM Huygaa Batsaikhan <bat...@google.com> wrote:
>>>>
>>>> Reuven, that's great. In this thread, we can continue discussing the usage
>>>> of review tools, dashboards, and metrics.
>>>>
>>>> On Tue, Jun 26, 2018 at 5:27 PM Reuven Lax <re...@google.com> wrote:
>>>>>
>>>>> So I suggested a while ago that we create a code-review guidelines doc,
>>>>> and in fact I was coincidentally just now drafting up a proposal doc.
>>>>> I'll share my proposal doc with the dev list soon.
>>>>>
>>>>> On Tue, Jun 26, 2018 at 5:18 PM Huygaa Batsaikhan <bat...@google.com>
>>>>> wrote:
>>>>>>
>>>>>> Hi, I've been looking into ways to improve Beam's code review process
>>>>>> based on previous discussions on dev list and summits, and I would like
>>>>>> to propose improvement ideas. Please take a look at:
>>>>>> https://s.apache.org/beam-code-review.
>>>>>>
>>>>>> Main proposals suggested in the doc are:
>>>>>>
>>>>>> Create a code review guideline document.
>>>>>> Build/setup code review tools and dashboards for Beam.
>>>>>> Collect metrics to monitor Beam's code review health.
>>>>>>
>>>>>> Feel free to add comments in the doc. I am looking for all sorts of
>>>>>> suggestions including existing code review guidelines, potential code
>>>>>> review tools etc.
>>>>>>
>>>>>> Thanks so much,
>>>>>> Huygaa
