On 14/08/15 10:42 -0400, Assaf Muller wrote:
First I'd like to say that I recognize that this discussion is incredibly personal. Brandon and Russell, please do not be offended, but I know that I probably would be if this very public thread involved myself. That being said, please know that from my perspective this is *not* personal, rather I see this as a general discussion about the precedent that we are creating here.Responses in-line. On Fri, Aug 14, 2015 at 9:32 AM, Kyle Mestery <mest...@mestery.com> wrote: On Fri, Aug 14, 2015 at 6:29 AM, Ihar Hrachyshka <ihrac...@redhat.com> wrote:it feels to me that leaving neutron-core group as a "meta-group" thatincludes everyone who makes significant positive impact in any of those repos is not optimal.This is where I'd disagree. I think in general teams pay too much attentionto stats, which are incredibly easy to game. Case in point, with the current objections people have over Brandon and Russell being nominated, I could have waited 4-6 weeks and let them amass a plethora of review stats, but what would the point of that have been? None what so ever. I think the point here is that if someone is focusing on another project then it's debatable if they should become a core in the Neutron project itself. Very simply put, if someone is a core in a subproject and is doing a fantastic job, but that person is not truly involved in the Neutron project itself, then that person becoming core in Neutron to me is dangerous. Before someone becomes core, I would like to be familiar with their expertise in Neutron so that I know if to trust their +2 or not on a given area in Neutron. If that person didn't really focus on Neutron then I have no way of being familiar with their expertise, thus no ability to trust them even if I'm generally a trusting person.
I'm not really familiar with Neutron's workflow but as an outsider and also based on my experience from other projects, the separation of concerns from a review perspective is very useful. Teams that govern several projects are be better off giving reviewing rights to folks in a per-project basis rather than doing it cross-team. I'd go as far as saying that folks with review rights in the server don't necessarily need to have review rights in smaller projects. The reason I'm saying this is because I believe that reviewer rights is not a prize but a volunteer job. The moment I'm asked whether I want to join a reviewers team in a project, I gotta be honest with what my available time will allow me to do. To what I just said, I'd also add the familiarity with the code-base, etc. Just my $0.02, Flavio -- @flaper87 Flavio Percoco
pgpGiXIqLqCmO.pgp
Description: PGP signature
__________________________________________________________________________ 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
