<div dir="ltr"><div>I agree with Travis that 2-3 minutes is not enough, that may not be even enough to talk about one bug. :)</div><div><br></div><div>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.</div><div><br></div><div>We can rotate this responsibility among cores every month - even non-core if someone wants to volunteer.</div><div><br></div><div>-Lin</div><div><br></div><div>[1] <a href="https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Keystone_Weekly_Bug_Reports">https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting#Keystone_Weekly_Bug_Reports</a></div><div><br></div><div><br></div><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 28, 2015 at 7:22 PM, Tripp, Travis S <span dir="ltr"><<a href="mailto:travis.tripp@hpe.com" target="_blank">travis.tripp@hpe.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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.<br>
<div class=""><div class="h5"><br>
<br>
<br>
<br>
<br>
On 9/28/15, 3:57 AM, "Rob Cresswell (rcresswe)" <<a href="mailto:rcresswe@cisco.com">rcresswe@cisco.com</a>> wrote:<br>
<br>
>Hi folks,<br>
><br>
>I¹m wondering if we could try marking out a small 2-3 minute slot at the<br>
>start of each weekly meeting to highlight Critical/ High bugs that have<br>
>code up for review, as well as important blueprints that have code up for<br>
>review. These would be blueprints for features that were identified as<br>
>high priority at the summit.<br>
><br>
>The thought here is that we were very efficient in L-RC1 at moving code<br>
>along, which is nice for productivity, but not really great for stability;<br>
>it would be good to do this kind of targeted work earlier in the cycle.<br>
>I¹ve noticed other projects doing this in their meetings, and it seems<br>
>quite effective.<br>
><br>
>Rob<br>
><br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>