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 <g...@google.com> 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: >>>>> >>>>> 1. Create a code review guideline document. >>>>> 2. Build/setup code review tools and dashboards for Beam. >>>>> 3. 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 >>>>> >>>>
