Hi,
Thanks for that ! I left comments in the doc, mostly agreements and also a
comment about public communication.
Etienne
Le mercredi 27 juin 2018 à 15:29 -0700, Robert Bradshaw a écrit :
> Thanks for writing this up! I especially like the idea ofautomatically
> assigning code reviewers, e.g. viahttps://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
