[Gluster-devel] Reducing merge conflicts

[Pranith Kumar Karampuri]

On Thu, Jul 14, 2016 at 11:29 PM, Joe Julian <joe at julianfamily.org> wrote:

> On 07/07/2016 08:58 PM, Pranith Kumar Karampuri wrote:
>
>
>
> On Fri, Jul 8, 2016 at 8:40 AM, Jeff Darcy <jdarcy at redhat.com> wrote:
>
>> > What gets measured gets managed.
>>
>> Exactly.  Reviewing is part of everyone's job, but reviews aren't tracked
>> in any way that matters.  Contrast that with the *enormous* pressure most
>> of us are under to get our own patches in, and it's pretty predictable
>> what will happen.  We need to change that calculation.
>>
>>
>> > What I have seen at least is that it is easy to find
>> > people who sent patches, how many patches someone sent in a month etc.
>> There
>> > is no easy way to get these numbers for reviews. 'Reviewed-by' tag in
>> commit
>> > only includes the people who did +1/+2 on the final revision of the
>> patch,
>> > which is bad.
>>
>> That's a very good point.  I think people people who comment also get
>> Reviewed-by: lines, but it doesn't matter because there's still a whole
>> world of things completely outside of Gerrit.  Reviews done by email won't
>> get counted, nor will consultations in the hallway or on IRC.  I have some
>> ideas who's most active in those ways.  Some (such as yourself) show up in
>> the Reviewed-by: statistics.  Others do not.  In terms of making sure
>> people get all the credit they deserve, those things need to be counted
>> too.  However, in terms of *getting the review queue unstuck* I'm not so
>> sure.  What matters for that is the reviews that Gerrit uses to determine
>> merge eligibility, so I think encouraging that specific kind of review
>> still moves us in a positive direction.
>>
>
> In my experience at least it was only adding 'reviewied-by' for the people
> who gave +1/+2 on the final version of the patch
>
> I agree about encouraging specific kind of review. At the same time we
> need to make reviewing, helping users in the community as important as
> sending patches in the eyes of everyone. It is very important to know these
> statistics to move in the right direction. My main problem with this is,
> everyone knows that reviews are important, then why are they not happening?
> Is it really laziness? Are we sure if there are people in the team who are
> not sharing the burden because of which it is becoming too much for 1 or 2
> people to handle the total load? All these things become very easy to
> reason about if we have this data. Then I am sure we can easily find how
> best to solve this issue. Same goes for spurious failures. These are not
> problems that are not faced by others in the world either. I remember
> watching a video where someone shared (I think it was in google) that they
> started putting giant TVs in the hall-way in all the offices and the people
> who don't attend to spurious-build-failure problems would show up on the
> screen for everyone in the world to see. Apparently the guy with the
> biggest picture(the one who was not attending to any build failures at all
> I guess) came to these folks and asked how should he get his picture
> removed from the screen, and it was solved in a day or two. We don't have
> to go to those lengths, but we do need data to nudge people in the right
> direction.
>
>
>
> Perhaps it's imposter syndrome. I know that even when I do leave comments
> on a patch, I don't add a +-1 because I don't think that my vote counts. I
> know I'm not part of the core developers so maybe I'm right, I don't know.
> Maybe some sort of published guidelines or mentorship could help?
>

Well it does count. I agree, some sort of published guidelines definitely
help. I absolutely hate what '-1' means though, it says 'I would prefer you
didn't submit this'. Somebody who doesn't know what he/she is doing still
goes ahead and sends his/her first patch and we say 'I would prefer you
didn't submit this'. It is like the tool is working against more
contributions. It could also say 'Thanks for your contribution, I feel we
can improve the patch further together' on -1 too you know.


>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://www.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Pranith
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.gluster.org/pipermail/gluster-devel/attachments/20160714/9479d188/attachment-0001.html>