On 07/14/2016 03:39 PM, Jeff Darcy wrote:
The feedback I got is, "it is not motivating to review patches that are
already merged by maintainer."
I can totally understand that. I've been pretty active reviewing lately,
and it's an *awful* demotivating grind. On the other hand, it's also
pretty demotivating to see one's own hard work "rot" as the lack of
reviews forces rebase after rebase. Haven't we all seen that? I'm
sure the magnitude of that effect varies across teams and across parts
of the code, but I'm equally sure that it affects all of us to some
degree.
Yes, we need to avoid this kind of rot. We have 500+ open patches across
all branches today in the review pipeline. Maybe we could clean
up/abandon some of these patches that are not relevant anymore? Once we
have that I think it would be useful to have an ageing based policy to
auto abandon patches. That might help us be more proactive in managing
our review queues.
IMO reviewing code is fun and takes some time for one to get better at.
I have personally imbibed good coding practices, understood something
better by reading and reviewing code. Several others [1] [2] also
emphasize the importance of code reviews to both the developer and the
project. If there is good enough interest on code reviews and how to get
better at that, some of our more prolific & experienced code reviewers
can possibly share thoughts over a hangout session?
Do you suggest they should change that
behaviour in that case?
Maybe. The fact is that all of our maintainers have plenty of other
responsibilities, and not all of them prioritize the same way. I know I
wouldn't be reviewing so many patches myself otherwise. If reviews are
being missed under the current rules, maybe we do need new rules.
let us give equal recognition for:
patches sent
patches reviewed - this one is missing.
helping users on gluster-users
helping users on #gluster/#gluster-dev
Feel free to add anything more I might have missed out. May be new
ideas/design/big-refactor?
Also doc, infrastructure work, blog/meetup/conference outreach, etc.
let people do what they like more among these and let us also recognize them
for all their contributions. Let us celebrate their work in each monthly
news letter.
Some of these aspects are easy to measure and can be automated. It is
fairly trivial to generate review statistics using gerrit's gsql
interface. I even have a script/query lying around somewhere for that
and can dig it up if somebody is interested in improving that to
automate the process of generating review statistics.
-Vijay
[1]
http://goodmath.scientopia.org/2011/07/06/things-everyone-should-do-code-review/
[2] http://users.encs.concordia.ca/~pcr/paper/Rigby2014TOSEM.pdf
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://www.gluster.org/mailman/listinfo/gluster-devel
