Open Stack

On Tue, Oct 08, 2013 at 02:31:34PM +0200, Jaromir Coufal wrote:
> Hi Chris,
> 
> On 2013/08/10 13:13, Chris Jones wrote:
> 
>     Hi
> 
>     On 8 October 2013 11:59, Jaromir Coufal <jcoufal at redhat.com> wrote:
> 
>             * Example: It doesn't make sense, that someone who is core-reviewer
>         based on image-builder is able to give +2 on UI or CLI code and
>         vice-versa.
> 
> 
>     I'm not sure this is a technical problem as much as a social problem - if
>     someone isn't able to give a good review (be it -1/+1 or +2) on a
>     particular change, they should just not review it, regardless of which part
>     of the project it relates to.
> 
> I completely agree on this point. It depends on people's judgement.
> 
> Question is if we will depend only on this judgment or we help that with
> splitting reviewers based on projects. I believe that the split can help us.
> Anyway, it is just proposal it depends what others think about that.
> 
> 
>     I'm a tripleo core reviewer, but I have been ignoring the tuskar reviews
>     until I have had some time to play with it and get a feel for the code. You
>     can argue that I therefore shouldn't even have the power to give a +2 on
>     tuskar code, but I would note that before Robert added me to core he wasn't
>     simply watching the quantity of my reviews, he was also giving me feedback
>     on areas I was going wrong. I would imagine that if I was wildly throwing
>     around inappropriate reviews on code I wasn't qualified to review, he would
>     give me feedback on that too and ultimately remove me as a reviewer.
> 
> Well it depends on the approach, if we think first or second way. I might argue
> that you shouldn't have the +2 power for Tuskar until you have bigger
> contribution on Tuskar code (reviews or patches or ...). Just for me it sounds
> logical, because you are not that close to it and you are not familiar with all
> the background there.
> 
> If somebody will be contributing regularly there, he can become core-reviewer
> on that project as well.
> 
> If you did bad code reviews on Tuskar and you were removed the 'core-' status,
> you still can do excellent job on other TripleO projects, so why to lose it at
> all of them?
> 
> Let me give one example:
> There is tuskar-client which is very important project and there is not that
> big activity as in other projects. There are people who actually wrote the
> whole code and based on the amount of work (reviews), they doesn't have to get
> between core-reviewers. In the future, if they need to move forward or quickly
> fix something, they would need to ask some core-reviewer who is not familiar
> with that code, just to approve it.
> 
> You see where I am getting?
> 
> 
>     Perhaps this is something that won't scale well, but I have a great deal of
>     faith in Robert's judgement on who is or isn't reviewing effectively.
> 
> I have no experience with Rob's distribution of core-members and I believe that
> he does it based on his best faith.
> 
> I am just suggesting more project based approach since the whole program
> expanded into more projects. It doesn't have to be strict project based metric,
> it can be combined with 'across projects contribution', so we assure that
> people are aware of the whole effort. But I believe that the project focus
> should stay as primary metric.
> 
> 
> 
>     --
>     Cheers,
> 
>     Chris
> 
> 
> Thanks
> -- Jarda

> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

I generally agree with Jarda w/r/t more project based approach.


I am concerned with case when core reviewers can be overloaded with
review demands.

Of course if this happens we can "just" add another core
reviewer to the group but I would suggest doing it other way - let's
have broader core group at first and gradually lower number of core
members (using metrics, discussion, need, common agreement from
contributors...) by X every Y weeks or so.

This way core reviewers group will shrink till its members feel that
they have just enough reviews on their agenda that it does not hinder
quality of their work.

This will not eliminate any "competition" for core membership but it
will eliminate immediate impact on projects' review process, on
reviewers' workload and will help gradually decide if any project needs
a core-member even if that person is not that active reviewer but can
ensure that patches will not grow old for that project.

That is my 2 cents.

-- 
Petr Blaho, pblaho at redhat.com
Software Engineer