On 07/07/2016 08:58 PM, Pranith Kumar Karampuri wrote:
On Fri, Jul 8, 2016 at 8:40 AM, Jeff Darcy <jda...@redhat.com
<mailto:jda...@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?
_______________________________________________
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
