<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<style type="text/css" style="display:none"><!--P{margin-top:0;margin-bottom:0;} --></style>
</head>
<body dir="ltr" style="font-size:10pt;color:#000000;background-color:#FFFFFF;font-family:Verdana,Geneva,sans-serif;">
<p>Thank you all for the input outside of the program:<font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"> Kyle</font>, Ihar, Thierry, Daniel!</p>
<p><br>
</p>
<p>Mike, Ian: It's a good idea to have the policy however, we need to craft one that is custom to the Glance program. It will be a bit different to ones out there as we've contributors who are dedicated to only subset of the code - for example just glance_store
 or python-glanceclient or metadefs. From here on, we may see that for Artifacts and other such features. It's already being observed for metadefs.</p>
<p><br>
</p>
<p>While I like Mike's suggestion to (semi-)adopt what Nova and Neutron are doing, it also makes me wonder if that's going to help us in long term. If not, then what can we do now to set a good path forward?</p>
<p><br>
</p>
<p>Flavio, Erno, Malini, Louis, Mike: Drafting a guideline policy and implementing rotation based on that was my intent so that everyone is aware of the changes in the program. That would let the core reviewers know what their duties are and let non-cores know
 what they need to do to become cores. Moreover, I've a idea for proposing a "core-member status" for our program than just core-reviewer. That seems more applicable for a few strong regular contributors like Travis and Lakshmi who work on bug fixes, bug triaging
 and client improvements however, do not seem to keep momentum on reviews. The core status can affect project decisions hence, this change may be important. This process may involve some interactions with governance so, will take more time.</p>
<p><br>
</p>
<p>Malini: I wish to take a strategic decision here rather an agile one. That needs a lot of brainpower before implementation. While warning and acting is good, it seems less applicable for this case. Simply because, we need to make a positive difference in
 the interactions of the community and we've a chance of doing that here.<br>
</p>
<p><br>
</p>
<p>Nevertheless, I do not want to block the new-core additions or ask Flavio et.al. to accommodate for the reviews that the new members would have been able to do (just kidding).<br>
</p>
<p><br>
</p>
<p>Tweaking Flavio's criterion of cleaning up the list for cores who have not done any reviews in the last 2 cycles (Icehouse and Juno), I've prepared a new list below (as Flavio's list did not match up even if we take cycles to be Juno, Kilo). They can be
 added back to the list faster in the future if they consider contributing to Glance again.</p>
<p><br>
</p>
<p>The criterion is:</p>
<p>Reviews <= 50 in combined cycles.</p>
<p><br>
</p>
<p>Proposal to remove the following members(review_count) from the glance-core list:</p>
<ul>
<li>Brian Lamar (0+15)</li><li>Brian Waldon (0+0)</li><li>Dan Prince (3+1)</li><li>Eoghan Glynn (0+3)</li><li>John Bresnahan (31+12)</li></ul>
<p>And we would add the following new members:</p>
<ul>
<li><font size="2"><span style="font-size:10pt;">Ian Cordasco</span></font></li><li><font size="2"><span style="font-size:10pt;">Louis Taylor</span></font></li><li><font size="2"><span style="font-size:10pt;">Mike Fedosin</span></font></li><li><font size="2"><span style="font-size:10pt;">Hemanth Makkapati</span></font></li></ul>
<p><br>
</p>
<p>This way we've a first round of consolidation done. It must be evident that the list-cleanup proposed above is not comprehensive with regards to who is truly inactive. Thus, misses out on a few names due to lack of established criterion. We can do more about
 rotation in the following weeks.</p>
<p><br>
</p>
<p>Hope it works!<br>
</p>
<p><br>
</p>
<div id="Signature">
<div style="font-family:Tahoma; font-size:13px">Regards,<br>
-Nikhil<br>
</div>
</div>
<div style="color: rgb(33, 33, 33);">
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> Kyle Mestery <mestery@mestery.com><br>
<b>Sent:</b> Friday, March 6, 2015 12:45 PM<br>
<b>To:</b> OpenStack Development Mailing List (not for usage questions)<br>
<b>Subject:</b> Re: [openstack-dev] [Glance] Core nominations.</font>
<div> </div>
</div>
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Fri, Mar 6, 2015 at 11:40 AM, Ian Cordasco <span dir="ltr">
<<a href="mailto:ian.cordasco@rackspace.com" target="_blank">ian.cordasco@rackspace.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
I like that idea. Can you start it out with Nova or Neutron’s guidelines?<br>
<span class=""><br>
</span></blockquote>
<div>FYI, the core reviewer guidelines for Neutron are in-tree now [1], along with all of our other policies around operating in Neutron [2].<br>
<br>
[1] <a href="https://github.com/openstack/neutron/blob/master/doc/source/policies/core-reviewers.rst">
https://github.com/openstack/neutron/blob/master/doc/source/policies/core-reviewers.rst</a><br>
[2] <a href="https://github.com/openstack/neutron/tree/master/doc/source/policies">
https://github.com/openstack/neutron/tree/master/doc/source/policies</a><br>
 <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<span class="">On 3/5/15, 17:38, "Mikhail Fedosin" <<a href="mailto:mfedosin@mirantis.com">mfedosin@mirantis.com</a>> wrote:<br>
<br>
>I think yes, it does. But I mean that now we're writing a document called<br>
>Glance Review Guidelines<br>
><br>
><a href="https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5R" target="_blank">https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5R</a><br>
>JabsI/edit?usp=sharing<br>
</span>><<a href="https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5" target="_blank">https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5</a><br>
>RJabsI/edit?usp=sharing> and it has a section "For cores". It's easy to<br>
<div>
<div class="h5">>include some concrete rules there to<br>
>add<br>
>more clarity.<br>
><br>
>2015-03-05 17:46 GMT+03:00 Ihar Hrachyshka<br>
><<a href="mailto:ihrachys@redhat.com">ihrachys@redhat.com</a>>:<br>
><br>
>-----BEGIN PGP SIGNED MESSAGE-----<br>
>Hash: SHA1<br>
><br>
>On 03/05/2015 11:35 AM, Mikhail Fedosin wrote:<br>
>> Yes, it's absolutely right. For example, Nova and Neutron have<br>
>> official rules for that:<br>
>> <a href="https://wiki.openstack.org/wiki/Nova/CoreTeam" target="_blank">https://wiki.openstack.org/wiki/Nova/CoreTeam</a> where it says: "A<br>
>> member of the team may be removed at any time by the PTL. This is<br>
>> typically due to a drop off of involvement by the member such that<br>
>> they are no longer meeting expectations to maintain team<br>
>> membership".<br>
><a href="https://wiki.openstack.org/wiki/NeutronCore" target="_blank">https://wiki.openstack.org/wiki/NeutronCore</a><br>
><<a href="https://wiki.openstack.org/wiki/NeutronCore" target="_blank">https://wiki.openstack.org/wiki/NeutronCore</a>> "The PTL<br>
>> may remove a member from neutron-core at any time. Typically when a<br>
>> member has decreased their involvement with the project through a<br>
>> drop in reviews and participation in general project development,<br>
>> the PTL will propose their removal and remove them. Members who<br>
>> have previously been core may be fast-tracked back into core if<br>
>> their involvement picks back up" So, as Louis has mentioned, it's a<br>
>> routine work, and why should we be any different? Also, I suggest<br>
>> to write the same wiki document for Glance to prevent these issues<br>
>> in the future.<br>
>><br>
><br>
>Does the rule belong to e.g. governance repo? It seems like a sane<br>
>requirement for core *reviewers* to actually review code, no? Or are<br>
>there any projects that would not like to adopt such a rule formally?<br>
><br>
>/Ihar<br>
>-----BEGIN PGP SIGNATURE-----<br>
>Version: GnuPG v1<br>
><br>
>iQEcBAEBAgAGBQJU+GxdAAoJEC5aWaUY1u579mEIAMN/wucsahaZ0yMT2/eo8t05<br>
>rIWI+lBLjNueWJgB+zNbVlVcsKBZ/hl4J0O3eE65RtlTS5Rta5hv0ymyRL1nnUZH<br>
>g/tL3ogEF0SsSBkiavVh3klGmUwsvQ+ygPN5rVgnbiJ+uO555EPlbiHwZHbcjBoI<br>
>lyUjIhWzUCX26wq7mgiTsY858UgdEt3urVHD9jTE2WNszMRLXQ7vsoAik9xDfISz<br>
>E0eZ8WVQKlNHNox0UoKbobdb3YDhmY3Ahp9Fj2cT1IScyQGORnm0hXV3+pRdWNhD<br>
>1M/gDwAf97F1lfNxPpy4JCGutbe5zoPQYLpJExzaXkqqARxUnwhB1gZ9lEG8l2o=<br>
>=lcLY<br>
>-----END PGP SIGNATURE-----<br>
><br>
>__________________________________________________________________________<br>
>OpenStack Development Mailing List (not for usage questions)<br>
>Unsubscribe:<br>
><a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
</div>
</div>
><<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><br>
><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<div class="">
<div class="h5">><br>
><br>
><br>
><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" target="_blank">
OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</body>
</html>