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 >>>> >>>
