Thank you for the feedback Flavio and Gary! I've noted down your concerns and will address them in a separate thread. So, I think we'd go ahead with nominations mentioned here (by Monday) and start the core-member discussion later.
Thanks, -Nikhil ________________________________________ From: Gary Kotton <gkot...@vmware.com> Sent: Sunday, March 8, 2015 11:45 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Glance] Core nominations. On 3/8/15, 2:34 PM, "Flavio Percoco" <fla...@redhat.com> wrote: >On 07/03/15 23:16 +0000, Nikhil Komawar wrote: >>Thank you for the response, Hemanth! Those are some excellent questions. >> >> >>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. >> >> >>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. >> >> >>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. > >I think I misread the original proposal with ragards to >"core-members". As it is explained here, I'm opposed on having this. >As soon as you start tagging people and adding more layers to the >community, it'll be harder to manage it and more importantly it'll be >more fragmented than it is, which is something I believe we don't >need. Agree 100% > >Citing the example you mentioned in your previous email: > >> "There are a few things that can be part of their rights like being >> able to vote for important decisions" > >This breaks openess and it reads like: "If you're not a 'core-member', >your vote won't count" > >We've fought hard to remove all these kind of labels and exclusive >rights by reducing them to the minimum, hence the core-reviewers team. > >Anyone should feel free to vote, speak up and most importantly, >everyones opinion *must* be taken into account. > >I'll wait for your final proposal to give a more constructive and >extended opinion based on that. > >Flavio > >> >> >>Hope that answered your questions, at least for the time being! >> >> >>Cheers >>-Nikhil >>━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ >>━━━━━━ >>From: Hemanth Makkapati <hemanth.makkap...@rackspace.com> >>Sent: Friday, March 6, 2015 7:15 PM >>To: OpenStack Development Mailing List (not for usage questions) >>Subject: Re: [openstack-dev] [Glance] Core nominations. >> >> >>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> >>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 , along >>with >>all of our other policies around operating in Neutron . >> >> >>https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack >>_neutron_blob_master_doc_source_policies_&d=AwIFaQ&c=Sqcl0Ez6M0X8aeM67LKI >>iDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=Q >>mQYMELbTDPVi2GwQ4VXQUrISU26zvqZ3HF7sRakbAM&s=nhf5jHMT2--d5SOm5pQD8ME3ATSG >>XhALfj7GHkwzieE&e= >>core-reviewers.rst >> >>https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack >>_neutron_tree_master_doc_source_policies&d=AwIFaQ&c=Sqcl0Ez6M0X8aeM67LKIi >>DJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3-diTlNj4GyNc&m=Qm >>QYMELbTDPVi2GwQ4VXQUrISU26zvqZ3HF7sRakbAM&s=KtneG6roTtYIAIEe2a2uv9pYoq5p2 >>n9kbGiLuPIiBZc&e= >> >> >> On 3/5/15, 17:38, "Mikhail Fedosin" <mfedo...@mirantis.com> wrote: >> >> >I think yes, it does. But I mean that now we're writing a document >>called >> >Glance Review Guidelines >> > >> >>>https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_doc >>>ument_d_1Iia0BjQoXvry9XSbf30DRwQt-2D-2DODglw-2DZTT-5F5R&d=AwIFaQ&c=Sqcl0 >>>Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq9N3 >>>-diTlNj4GyNc&m=QmQYMELbTDPVi2GwQ4VXQUrISU26zvqZ3HF7sRakbAM&s=qkoKPqPJoCI >>>x2FMp-Af4TJW2TA2Jj_OcULHtRCnsLO4&e= >> >JabsI/edit?usp=sharing >> >>><https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_do >>>cument_d_1Iia0BjQoXvry9XSbf30DRwQt-2D-2DODglw-2DZTT-5F5-0A&d=AwIFaQ&c=Sq >>>cl0Ez6M0X8aeM67LKIiDJAXVeAw-YihVMNtXt-uEs&r=VlZxHpZBmzzkWT5jqz9JYBk8YTeq >>>9N3-diTlNj4GyNc&m=QmQYMELbTDPVi2GwQ4VXQUrISU26zvqZ3HF7sRakbAM&s=n-whXxsc >>>MfkKVxiUz_D5z1UTOK90rBJOmTEuKv2QJcU&e= > >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>: >> > >> >-----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://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 >> >> > >>_________________________________________________________________________ >>_ >>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 > > >-- >@flaper87 >Flavio Percoco __________________________________________________________________________ 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 __________________________________________________________________________ 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