Open Stack

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 <mestery at mestery.com> wrote:
>
>    On Fri, Aug 14, 2015 at 6:29 AM, Ihar Hrachyshka <ihrachys at redhat.com>
>    wrote:
>   
>        it feels to me that leaving neutron-core group as a "meta-group" that
>        includes 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 attention
>    to 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150814/7ea2cd86/attachment.pgp>