Strongly agree with auto assigning code reviewers, I guess this is one of the main issue for first-starters to whom address their PR.
Also, I’m totally pro for having review style guide which definitively should help to unify review process and make it more transparent for all. Thanks to last efforts to reduce a number of open PRs, there are only about 90 opened ones. I believe that most of them are “in progress” but others are quite inactive. Perhaps, it would make sense to put some efforts to review their status before they will be closed automatically by stale bot. Alexey > On 28 Jun 2018, at 10:24, Etienne Chauchot <echauc...@apache.org> wrote: > > 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 of >> automatically assigning code reviewers, e.g. via >> https://help.github.com/articles/about-codeowners/ >> <https://help.github.com/articles/about-codeowners/> >> On Wed, Jun 27, 2018 at 11:10 AM Scott Wegner <sc...@apache.org >> <mailto: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 >> <mailto: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 >> <mailto: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 >> <https://www.apache.org/foundation/policies/conduct.html> >> >> On Tue, Jun 26, 2018 at 5:48 PM Huygaa Batsaikhan <bat...@google.com >> <mailto: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 >> <mailto: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 >> <mailto: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 >> <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
