Hi Salvatore I got your point.
I have two idea for improvement. (idea1) Introduce metrics to show median of waiting_days/ LOC This is based on your idea. One suggestion from me is big patch need more time. so How about divide it by LOC? (Idea2) Improve UI for showing patches which is waiting reviews only. I have quickly checked the long live patches (1). Sometimes submitter takes a long time to fix the patch, sometimes the patch will drop from reviewers radar. so I believe it is helpful to check the long-live review which is waiting review. I'll update the https://github.com/russellb/openstack-stats/blob/master/openreviews.py#L101 to show actual waiting reviews. (*1) [S] is mainly waiting Submitters, [R] is mainly waiting Reviewers. [B] is waiting both. Longest waiting reviews (based on latest revision): [S] 17 days, 10 hours, 25 minutes - https://review.openstack.org/32339 (Move lbaas extension to core API) [R] 17 days, 22 hours, 6 minutes - https://review.openstack.org/21489 (netns-cleanup: kill metadata proxy server) [S] 20 days, 15 hours, 24 minutes - https://review.openstack.org/30441 (bp: pxeboot-port, provide pxeboot on ports) [R] 42 days, 16 hours, 13 minutes - https://review.openstack.org/28137 (Make the metadata namespace proxy transparent.) [S] 196 days, 22 hours, 50 minutes - https://review.openstack.org/17436 (Allow user to specify None value to attributes) Longest waiting reviews (based on first revision): [B] 100 days, 21 hours, 54 minutes - https://review.openstack.org/24771 (multi-host feature) [R] 113 days, 13 hours, 34 minutes - https://review.openstack.org/23718 (Support router-interface-add/delete by port_id) [B] 133 days, 15 hours, 19 minutes - https://review.openstack.org/21979 (Add bridge_lib.py to wrap brctl calls in LinuxBridge Agent) [R]140 days, 3 hours, 54 minutes - https://review.openstack.org/21489 (netns-cleanup: kill metadata proxy server) [S] 206 days, 4 hours, 21 minutes - https://review.openstack.org/17436 (Allow user to specify None value to attributes) (*2) Note: the value in waiting reviewers in http://russellbryant.net/openstack-stats/all-openreviews.html is misleading, because the definition of waiting_review is actually "waiting the first review which says -1 or -2" (see https://github.com/russellb/openstack-stats/blob/master/openreviews.py#L101) Memo: This is how to use https://github.com/russellb/openstack-stats/ python openreviews.py -u nati-ueno -k ~/.ssh/id_rsa -p projects/quantum.json -l 1000 Best Nachi 2013/6/28 Salvatore Orlando <[email protected]>: > Nachi, > > this wasn't a rank against missing reviews! > I hope nobody gets offended. > > My goal is to see if we can do something to improve our turnaround times. > The metric we need to improve, I think, are median time to first review and > median time to approval/abandon. > I'd prefer the median compared to the average as a metric. > > Salvatore > > > On 28 June 2013 14:54, Nachi Ueno <[email protected]> wrote: >> >> Hi Salvatore >> >> Thank you for your pointing this. >> I'll improve my review counts. >> >> Best >> Nachi >> >> 2013/6/28 Salvatore Orlando <[email protected]>: >> > Not great apparently [1]. >> > If this were a soccer league among openstack projects, we would have >> > been >> > relegated! >> > >> > As the things stand right now, I am part of the problem, due to lack of >> > reviews [2] >> > Even if we could all do with more reviews from the core team (barring >> > the >> > ones who are already doing a great job), I reckon that the biggest >> > problem >> > is the wait time for the first review. >> > A possible cause, in my opinion, lies in the review days. >> > Since each core has a specific area of expertise, patches for that area >> > might end up lying in limbo until that core's review day comes. From my >> > perspective, I am trying, as much as possible, to allocate a slice of my >> > time every day for reviews; another thing I'm doing is to pick patches >> > from >> > the bottom at least one day a week to avoid starvation. >> > However, I desperately need to improve my react time to new patchsets, >> > as I >> > often miss them. Gerrit emails are very high volume, so email >> > notifications >> > often get lost. Suggestions are welcome. >> > >> > Another cause are plugin-specific patches. Some of these reviews, >> > especially >> > for plugins with no core members, sit for a rather long time. It would >> > be >> > good if every plugin sub-team lead can nominate an "alternate core dev" >> > that >> > patch authors can ping for reviews. >> > >> > Salvatore >> > >> > [1] http://russellbryant.net/openstack-stats/all-openreviews.html >> > [2] http://russellbryant.net/openstack-stats/quantum-reviewers-30.txt >> > >> > -- >> > Mailing list: https://launchpad.net/~quantum-core >> > Post to : [email protected] >> > Unsubscribe : https://launchpad.net/~quantum-core >> > More help : https://help.launchpad.net/ListHelp >> > > > -- Mailing list: https://launchpad.net/~quantum-core Post to : [email protected] Unsubscribe : https://launchpad.net/~quantum-core More help : https://help.launchpad.net/ListHelp
