I wasn’t really envisioning a big discussion on the bugs; more like a brief notice period to let reviewers know high-priority items. Could definitely spend longer over it if that is preferred. Timing aside, the overall idea sounds good though?
Lin: That’s a good idea. A wiki page would probably suffice. Rob From: Lin Hua Cheng <[email protected]<mailto:[email protected]>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]<mailto:[email protected]>> Date: Tuesday, 29 September 2015 04:11 To: "OpenStack Development Mailing List (not for usage questions)" <[email protected]<mailto:[email protected]>> Subject: Re: [openstack-dev] [Horizon] Horizon Productivity Suggestion I agree with Travis that 2-3 minutes is not enough, that may not be even enough to talk about one bug. :) We could save some time if we have someone monitoring the bugs/feature and publish the high priority item into a report - something similar to what Keystone does [1]. Reviewers can look this up every time if they need to prioritize their reviews. We can rotate this responsibility among cores every month - even non-core if someone wants to volunteer. -Lin [1] https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Keystone_Weekly_Bug_Reports On Mon, Sep 28, 2015 at 7:22 PM, Tripp, Travis S <[email protected]<mailto:[email protected]>> wrote: Things always move more quickly at the end of a cycle because people feel release pressure, but I do think this is a good idea. 2 - 3 minutes isn’t very realistic. It would need to be planned for longer. On 9/28/15, 3:57 AM, "Rob Cresswell (rcresswe)" <[email protected]<mailto:[email protected]>> wrote: >Hi folks, > >I¹m wondering if we could try marking out a small 2-3 minute slot at the >start of each weekly meeting to highlight Critical/ High bugs that have >code up for review, as well as important blueprints that have code up for >review. These would be blueprints for features that were identified as >high priority at the summit. > >The thought here is that we were very efficient in L-RC1 at moving code >along, which is nice for productivity, but not really great for stability; >it would be good to do this kind of targeted work earlier in the cycle. >I¹ve noticed other projects doing this in their meetings, and it seems >quite effective. > >Rob > > >__________________________________________________________________________ >OpenStack Development Mailing List (not for usage questions) >Unsubscribe: >[email protected]?subject:unsubscribe<http://[email protected]?subject:unsubscribe> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe<http://[email protected]?subject:unsubscribe> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
