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.


Also, +1 to both the criteria for removing existing cores and addition of new 
cores.


-Hemanth.

________________________________
From: Nikhil Komawar <nikhil.koma...@rackspace.com>
Sent: Friday, March 6, 2015 4:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Core nominations.


Thank you all for the input outside of the program: Kyle, Ihar, Thierry, Daniel!


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.


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?


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.


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.


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).


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.


The criterion is:

Reviews <= 50 in combined cycles.


Proposal to remove the following members(review_count) from the glance-core 
list:

  *   Brian Lamar (0+15)
  *   Brian Waldon (0+0)
  *   Dan Prince (3+1)
  *   Eoghan Glynn (0+3)
  *   John Bresnahan (31+12)

And we would add the following new members:

  *   Ian Cordasco
  *   Louis Taylor
  *   Mike Fedosin
  *   Hemanth Makkapati


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.


Hope it works!


Regards,
-Nikhil
________________________________
From: Kyle Mestery <mest...@mestery.com>
Sent: Friday, March 6, 2015 12:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Core nominations.

On Fri, Mar 6, 2015 at 11:40 AM, Ian Cordasco 
<ian.corda...@rackspace.com<mailto:ian.corda...@rackspace.com>> wrote:
I like that idea. Can you start it out with Nova or Neutron's guidelines?

FYI, the core reviewer guidelines for Neutron are in-tree now [1], along with 
all of our other policies around operating in Neutron [2].

[1] 
https://github.com/openstack/neutron/blob/master/doc/source/policies/core-reviewers.rst
[2] https://github.com/openstack/neutron/tree/master/doc/source/policies

On 3/5/15, 17:38, "Mikhail Fedosin" 
<mfedo...@mirantis.com<mailto:mfedo...@mirantis.com>> wrote:

>I think yes, it does. But I mean that now we're writing a document called
>Glance Review Guidelines
>
>https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5R
>JabsI/edit?usp=sharing
><https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5
>RJabsI/edit?usp=sharing> and it has a section "For cores". It's easy to
>include some concrete rules there to
>add
>more clarity.
>
>2015-03-05 17:46 GMT+03:00 Ihar Hrachyshka
><ihrac...@redhat.com<mailto:ihrac...@redhat.com>>:
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 03/05/2015 11:35 AM, Mikhail Fedosin wrote:
>> Yes, it's absolutely right. For example, Nova and Neutron have
>> official rules for that:
>> https://wiki.openstack.org/wiki/Nova/CoreTeam where it says: "A
>> member of the team may be removed at any time by the PTL. This is
>> typically due to a drop off of involvement by the member such that
>> they are no longer meeting expectations to maintain team
>> membership".
>https://wiki.openstack.org/wiki/NeutronCore
><https://wiki.openstack.org/wiki/NeutronCore> "The PTL
>> may remove a member from neutron-core at any time. Typically when a
>> member has decreased their involvement with the project through a
>> drop in reviews and participation in general project development,
>> the PTL will propose their removal and remove them. Members who
>> have previously been core may be fast-tracked back into core if
>> their involvement picks back up" So, as Louis has mentioned, it's a
>> routine work, and why should we be any different? Also, I suggest
>> to write the same wiki document for Glance to prevent these issues
>> in the future.
>>
>
>Does the rule belong to e.g. governance repo? It seems like a sane
>requirement for core *reviewers* to actually review code, no? Or are
>there any projects that would not like to adopt such a rule formally?
>
>/Ihar
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1
>
>iQEcBAEBAgAGBQJU+GxdAAoJEC5aWaUY1u579mEIAMN/wucsahaZ0yMT2/eo8t05
>rIWI+lBLjNueWJgB+zNbVlVcsKBZ/hl4J0O3eE65RtlTS5Rta5hv0ymyRL1nnUZH
>g/tL3ogEF0SsSBkiavVh3klGmUwsvQ+ygPN5rVgnbiJ+uO555EPlbiHwZHbcjBoI
>lyUjIhWzUCX26wq7mgiTsY858UgdEt3urVHD9jTE2WNszMRLXQ7vsoAik9xDfISz
>E0eZ8WVQKlNHNox0UoKbobdb3YDhmY3Ahp9Fj2cT1IScyQGORnm0hXV3+pRdWNhD
>1M/gDwAf97F1lfNxPpy4JCGutbe5zoPQYLpJExzaXkqqARxUnwhB1gZ9lEG8l2o=
>=lcLY
>-----END PGP SIGNATURE-----
>
>__________________________________________________________________________
>OpenStack Development Mailing List (not for usage questions)
>Unsubscribe:
>openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
><http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
>
>

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: 
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to