<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;} 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 for the response,<font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"> Hemanth</font>! Those are some excellent questions.
</p>
<p><br>
</p>
<p>In order to avoid diverging the conversation, I would like to give my general sense of direction. Please do keep in mind that a lot of these thoughts need to be better formulated, preferably on a different thread.</p>
<p><br>
</p>
<p>Core-members would be generic concept unlike core-reviewers. The one important thing that this should achieve is clear understanding of the individuals (usually ones who are new or interact less often in Glance) - who actually is a "Core" in the program?
There are a few things that can be part of their rights like being able to vote for important decisions (like the current thread), they may or may not have core-reviewer rights based on their participation area. For example, they could be security liaison
or they may _officially_ do release management for the libraries without being a core-reviewer, etc. The responsibilities should complement the rights.<br>
</p>
<p><br>
</p>
<p>Those are just initial thoughts and can be better formulated. I will attempt to craft out the details of the core-member concept in the near future and you all are welcome to join me in doing so.<br>
</p>
<p><br>
</p>
<p style="">Hope that answered your questions, at least for the time being!</p>
<p><br>
</p>
<div id="Signature">
<div style="font-family:Tahoma; font-size:13px">Cheers<br>
-Nikhil<br>
</div>
</div>
<div dir="ltr" style="font-size:12pt; color:#000000; background-color:#FFFFFF; font-family:Calibri,Arial,Helvetica,sans-serif">
<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> Hemanth Makkapati <hemanth.makkapati@RACKSPACE.COM><br>
<b>Sent:</b> Friday, March 6, 2015 7:15 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>
<p>I like the idea of a 'core-member'. But, how are core-members different from core-reviewers? For instance, with core-reviewers it is very clear that these are folks you would trust with merging code because they are supposed to have a good understanding
of the overall project. What about core-members? Are core-members essentially just core-reviewers who somehow don't fit the criteria of core-reviewers but are good candidates nevertheless? Just trying to understand here ... no offense meant.<br>
</p>
<p><br>
</p>
<p>Also, +1 to both the criteria for removing existing cores and addition of new cores.</p>
<p><br>
</p>
<p>-Hemanth.<br>
</p>
<div dir="ltr" style="font-size:10pt; color:#000000; background-color:#FFFFFF; font-family:Verdana,Geneva,sans-serif">
<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> Nikhil Komawar <nikhil.komawar@RACKSPACE.COM><br>
<b>Sent:</b> Friday, March 6, 2015 4:04 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>
<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>
</div>
</div>
</div>
</div>
</body>
</html>